easy, so just a possible tip to consider.
Regards,
Ivan Labáth
On Tue, Aug 29, 2023 at 12:13:12AM +0200, Daniel Gröber wrote:
> Hi Juliusz,
>
> On Mon, Aug 28, 2023 at 07:40:51PM +0200, Juliusz Chroboczek wrote:
> > I've read the whole discussion, and I'm still not clea
Normally, you would use routing (L3) instead of bridging (L2).
Conceptually, the connectivity should work about the same,
as long as you configure your routes and enable forwarding.
Routes need to be configured on the host, not container-only,
but if assign a subnet to a bridge, devices can use add
Hello,
you can't, as wireguard does not currently implement multicast nor broadcast.
You can add unicast IPs and duplicate packets if you feel like it,
or add another layer or two, which is what most people posting here do.
Regards,
Ivan
On Fri, Feb 19, 2021 at 08:58:53AM +0100, nicolas prochaz
Hello,
I can't say for sure, but I would guess your issue is the result
of transient network states/outages coupled with wireguard
automatic roaming and wildcard listening.
Wireguard listens on all addresses and performs automatic roaming,
neither of which can be disabled without external help (e
Hello,
are you sure changing of source port is the issue?
Seems like something that would be reported a long
time ago.
Wireguard handshake fails, if your timestamps aren't
monotonically increasing - maybe this is the issue?
For confirmation - does connection fail on wg restart without
a device p
>
> On Wed, 29 Jul 2020 at 20:58, Rich Brown wrote:
> >
> > These are helpful comments.
> >
> > > On Jul 29, 2020, at 6:18 PM, Ivan Labáth
> > > wrote:
> > >
> > > On Tue, Jul 28, 2020 at 05:33:43PM -0400, Rich Brown wrote:
> &
On Tue, Jul 28, 2020 at 05:33:43PM -0400, Rich Brown wrote:
> AllowedIPs is the set of addresses that your WireGuard peer will send across
> the tunnel to its peer.
The definition is close, but not precise. Assuming things haven't
changed much:
AllowedIPs specifies the set of addresses that y
On Wed, Feb 26, 2020 at 05:05:26PM +0100, tubi webmail wrote:
> So NO rules regarding masquerading seems to be in use.
I would suggest you check your iptables nat table
# iptables --list -vn -t nat
alternatively check the output of
# iptables-save
Also, these days you might be using nftables:
#
Hello,
have you checked the source port of replies, or whether
there are any replies?
# tcpdump -nn
Tcpdump should show pre-NAT addresses on incoming packets
and AFAIK post-NAT on outgoing packets, i.e. what goes on
the wire.
You might need to apply SNAT on outgoing packets, which
might happen
On Thu, Oct 17, 2019 at 07:03:40PM +, Hendrik Friedel wrote:
> >>
> >> >As a workaround you could
> >> > - unconditionally periodically update the endpoint
> >> This would break existing transfers without reason.
> >
> >As I said, you could try periodically updating the endpoint, and only
On Sat, Sep 07, 2019 at 10:04:44AM +, Hendrik Friedel wrote:
> Hello,
>
> >> that seems not to be the intended behaviour:
> >> If I understand correctly, the current behaviour is:
> >>
> >> At tunnel start the IP is resolved
> >> This IP is used for ever, namingly for re-connects.
> >This
- unconditionally periodically update the endpoint
- monitor last handshake time, when large update endpoint or restart
tunnel
- add keepalive to server - it might reduce your downtime
Regards,
Ivan Labáth
___
WireGuard mailing list
W
Hello,
I notice you are using dynamic ips for server.
On the client, is the server peer ip correct?
Regards,
Ivan
On Sun, Aug 25, 2019 at 06:44:53PM +, Hendrik Friedel wrote:
> Hello,
>
> thanks for your reply.
> It is linux (Kernel 5.x) in both cases.
>
> Regards,
> Hendrik
>
> -- Or
Hello,
please note two separate steps with regards to wireguard routing.
1) kernel routing table (and iptables, policy routing, xfrm etc)
2) wg peer IPs (routing table)
The first step (1) chooses which interface to use for a given packet.
If the chosen interface is a wireguard device, then step
Hi Jason,
while the idea of Deterministic Cryptographically Authenticated
Network Signatures is commendable, what is the *purpose* of the
network signature in Windows?
On Fri, Jun 28, 2019 at 10:15:39PM +0200, Jason A. Donenfeld wrote:
> On Fri, Jun 28, 2019 at 6:33 PM zrm wrote:
> > The drawbac
Hi,
walk_remove_by_peer does seem inefficient. Judging by the stack, I guess
it walks the tree looking for addresses from a specific peer. That would
be roughly O(A log A) operations for A addresses, in total O(N A log A)
if removing all of them.
A simple fix would be to know what you want to rem
On Thu, Jun 06, 2019 at 12:09:45PM +0200, Toke Høiland-Jørgensen wrote:
> Paul Zillmann writes:
..
> > The problem is that the allowed-ips configuration has multiple purposes:
> > routing table and firewall/packet filter. This introduces these
> > problems. It would be helpfull to get a compile
Hi,
as has been noted on a thread by Tomas Herceg on 2018-06-22,
a workaround is to internally listen on a different port,
and use NAT so it appears as the desired port on the outside.
If you really wanted to, with some iptables magic (e.g. u32 match),
you could match and split wireguard traffic
Hi,
On Sat, Feb 23, 2019 at 05:00:57AM +0100, Axel Neumann wrote:
> ..
> Regarding
> > Initiation of a wireguard
> > tunnel for those devices would be: read last counter to variable X,
> > increment last counter, store incremented counter to flash, tell
> > wireguard to use X as basetime.
>
> Do
Hi all,
I would like to propose an idea, that if peer were keyed by an
identifier (e.g. string) insted of pubkey. E.g. from
[Peer PubKeyWithBunchOfCharacters]
Identifier = Gorge
[Peer AnotherPubkeyWithBuchOfCharacters]
Identifier = Jane
..
we changed it to
[Peer George]
Pubkey = BuchOf
On Wed, Jan 16, 2019 at 06:40:05PM -0600, Samuel Holland wrote:
> H can immediately send handshakes to all peers when it is brought up (and will
> do so today if they have persistent keepalives set). But you need more than HA
> being able to initiate traffic to B. B could have roamed to a new IP wh
Hi,
Wireguard isn't completely stateless. It has connections and state,
even though it is comparably small and transient.
Wireguard roaming supports changing IPs. An authenticated
packet updates the ip and all works well. Changing hosts requires
a rekey (to re-establish transient keys), and that
so you can see
the number of matched packets (caveats apply in NAT).
Regards,
Ivan Labáth
On Mon, Sep 17, 2018 at 07:10:05AM -0400, Raffaele Spazzoli wrote:
> Ivan,
>
> sorry for the formatting, it seemed right on my email editor (gmail).
> I cannot do SNAT at the source because the p
On Sun, Sep 16, 2018 at 07:08:58PM -0400, Raffaele Spazzoli wrote:
> sh-4.2# iptables -t nat -n -L Chain PREROUTING (policy ACCEPT) target prot
> opt source destination Chain INPUT (policy ACCEPT) target prot opt source
> destination SNAT udp -- 10.128.2.10 0.0.0.0/0 udp dpt: to:
> 192.168.99.1
Hi,
On Sun, Sep 16, 2018 at 08:21:02AM -0400, Raffaele Spazzoli wrote:
> ... then the IP that a node uses for its outbound
> connection is not the same that its peer need to use for its inbound
> connections.
Who uses what for whose connection? You lost me here.
Looks like a broken network to me
eplay
..
- spoofing
..
3) What does B learn about A? (e.g. if B is a service provider)
- all listed in (1)
- pubkey? should be random
..
Regards,
Ivan Labáth
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
wouldn't require such dependencies.
How about allowing counter wrapping, if it has been at least
2 * REKEY_TIMEOUT from last handshake? Perhaps reusing the cookie
protocol for a 2-RTT handshake?
Losing access to a device, because its clock has gone wonky is not plea
Hi,
as said, I don't concieve a reasonable way of using the same key.
Wireguard routes and needs to identify and know its clients.
That said, I don't see a reason why the clients couldn't have similar
private keys.
e.g.
Server:
Private = PrivateKey
[Peer1]
Pubkey = secret_to_public(notreallys
On Thu, Jan 18, 2018 at 12:56:55PM +0100, Kalin KOZHUHAROV wrote:
>
> Since this is not a common scenario, IMHO, and there are only a
> handful TOS worth doing something, a workaround would be to bunch a
> few wg tunnels (even bridge them at both ends?), use fwmark and mangle
> the TOS with iptabl
Hi,
I don't know much about arm modules, but is seems
like a generic module-kernel mismatch.
Are you using kernel configuration and sources
for the running kernel?
Regards,
Ivan
On Mon, Nov 20, 2017 at 10:34:09PM +0300, Роман Гаврилов wrote:
> Hello!
>
> I have new bug on armhf.
>
>
Hi,
I didn't think it would be such a small change :)
You mention changing routes. It is indeed a valid
use for move instead of remove + add, as it should
not drop packets, but I do not think it is a compelling
reason. Executing remove + add shouldn't take more than
a few milliseconds and network
route add/delete style
would be appropriate.
Regards,
Ivan
On Wed, May 17, 2017 at 03:47:51PM +0200, Jason A. Donenfeld wrote:
> Hi Ivan,
>
> On Tue, May 16, 2017 at 5:42 PM, Ivan Labáth
> wrote:
> > does changing one peer affect settings of another
> > peer if they h
Hello,
does changing one peer affect settings of another
peer if they have common allowed_ips?
Regards,
Ivan Labáth
On Tue, May 16, 2017 at 02:36:00PM +0200, Jason A. Donenfeld wrote:
> Hey guys,
>
> Currently wg(8) talks to the kernel by passing structs through an
> ioctl. Due
On Tue, Aug 30, 2016 at 10:44:39AM -0500, Bruno Wolff III wrote:
> On Tue, Aug 30, 2016 at 07:44:54 +0100,
> Ivan Labáth wrote:
> >
> >I think repeating subnets in different peers is most probably
> >an error and in such circumstances the most useful action would
> &
# ip route add 172.16.0.0/12 via 127.0.0.2
RTNETLINK answers: File exists
Regards,
Ivan Labáth
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/wireguard
35 matches
Mail list logo
