Re: AllowedIPs = ::/0 routes IPv4 - on Android?

Hello Marek, since when does ::/0 refer to IPv4 addresses? To my knowledge, ::/0 is the IPv6 all route and does not include any IPv4. Best regards, Nico Marek Küthe writes: > [[PGP Signed Part:Undecided]] > Hello Valentijn, > > ::/0 does not describe no IPv4 address, but all

Re: Wg source address is too sticky for multihomed systems aka multiple endpoints redux

s or routing policy present on the multi homed server. I'm a big fan of simplicity, but without an equivalent of openvpn's "local" statement, wireguard is deemed to be unusable in many network scenarios. Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

Re: Src addr code review (Was: Source IP incorrect on multi homed systems)

Hello 曹煜, on github it seems your patch was applied / the issue was closed - is that the correct current status? Best regards, Nico 曹煜 writes: > Hi all, > I've hacked that source code myself months ago, and it works well on > my use case (I have 4 dual stack pppoe wan set on m

Re: Src addr code review (Was: Source IP incorrect on multi homed systems)

); What I am wondering is, how did it get into the cache in the first place? > [...] > > @Nico could it perhaps simply be that you're hitting one of these zero'ing > cases and that's why it's using regular kernel src addr selection instead > of the cached endpoint src4 address? That coul

Re: Source IP incorrect on multi homed systems

Hey Roman, Roman Mamedov writes: > On Sun, 19 Feb 2023 21:18:34 +0100 > Nico Schottelius wrote: > >> If I am not mistaken that would mean in practice: >> >>if orignal_pkg.ip_dst == one_of_my_ips then >> return_pkg.ip.src = orignal_pkg.

Re: Source IP incorrect on multi homed systems

ach (aside from my very simplified algorithm). Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

Re: Source IP incorrect on multi homed systems

Hey Janne, Janne Johansson writes: > *) https://en.wiktionary.org/wiki/Chesterton%27s_fence I am happy to have learned a new principle today, thanks for that. And to be sure that everyone is on the same page: Wireguard should reply by default with the source address that used to be

Re: Source IP incorrect on multi homed systems

Hello Christoph, Christoph Loesch writes: > @Nico: did you try to delete the affected route and add it again with the > correct source IP ? No, I did not because the routes are really dynamic on the affected systems and I would need to overwrite the BGP routes with a better metric,

Re: Source IP incorrect on multi homed systems

alls, because the returning packet does not match the state session database. Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

Re: Source IP incorrect on multi homed systems

interface, this is never going to work, as lo cannot send packets to the outside world. Nico Schottelius writes: > Let me rephrase the problem statement: > > - ping and http calls to the multi homed machine work correctly: > I can ping 147.78.195.254 and the reply contains the

Re: Source IP incorrect on multi homed systems

ng part that sets the source IP, so I am wondering if this bug is due to wireguard not handling it at all? Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

Re: Source IP incorrect on multi homed systems

BGP connected to three > locations. > > There is no NAT setup and because I also add the wireguard link > addresses to the BGP sessions. > > Cheers > > > > On 19/2/2023 6:44 am, Nico Schottelius wrote: >> Dear group, >> >> I was wondering how wireguar

Re: Source IP incorrect on multi homed systems

Hello Omkhar, I tend to disagree. The problem is not the routing, but the selected source address, which is independent of routing. To be more specific: as there is BGP routing on all all interfaces, 147.78.195.254 is an accepted IP address on any interface. Best regards, Nico Omkhar

Source IP incorrect on multi homed systems

Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

Re: WireGuard protocol blocking in China, swgp-go (userspace obfuscation proxy)

maybe it could even "learn" the proper obfuscation by detecting blocks on easier to detect obfuscation and then switching to a stronger, but less efficient obfuscation. Wondering what your thoughts are on this. Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

Re: Outgoing ping required in container environment (even with PersistentKeepalive)

- Even if my assumption was right, I'd expect a new handshake at some point to happen, but even minutes after restarting the container, the IPv4 address is not reachable. Best regards, Nico Nico Schottelius writes: > Good morning, > > another day news from the container land. When r

Outgoing ping required in container environment (even with PersistentKeepalive)

received, 0% packet loss round-trip min/avg/max = 6.664/7.887/9.110 ms The connection stays correctly established. If anyone has a pointer on what might be going on, any help is appreciated. Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

Why is the src_valid_mark needed and not allowed (in kubernetes)?

und using 0.0.0.0/1, 128.0.0.0/1 works / what is the drawback of this? Best regards and a good evening from container land, Nico -- Sustainable and modern Infrastructures by ungleich.ch

Interface not deleted in kubernetes

ut implies that this is not the case. Any pointers in this direction are very welcome. Best regards, Nico [0] https://hub.docker.com/layers/ungleich-wireguard/ungleich/ungleich-wireguard/0.0.5/images/sha256-cf50085115df1f686509288375349ce61cc4ef06a06c940cf7cbd9041a6d9ef6?context=e

Re: WireGuard with obfuscation support

l to implement, is there any easy way to grab the outgoing wireguard packets without the need of creating n artifical local UDP endpoints? Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

Re: WireGuard with obfuscation support

Bruno, thanks for raising 2 very important points: Bruno Wolff III writes: > On Mon, Sep 27, 2021 at 09:53:08 +0900, > Nico Schottelius wrote: >> >>I'd appreciate if wireguard upstream would take this in, maybe even >>supporting multiple / dynamic listen ports. &

Re: WireGuard with obfuscation support

ireguard at all. I'd appreciate if wireguard upstream would take this in, maybe even supporting multiple / dynamic listen ports. Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

Wireguard as a Kubernetes Service

endpoints into a k8s cluster? Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

Re: potentially disallowing IP fragmentation on wg packets, and handling routing loops better

needed. What would be the appropriate ICMP message for an IPv4 packet that does not include the DF bit? So far, I'm not fully convinced the approach is a smart way, especially not when it comes to handling network debugging and given that we do already have a TTL that should be a loop prevention as well. Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch

Re: potentially disallowing IP fragmentation on wg packets, and handling routing loops better

fine, I am more concerned about mesh networks, in which wg is quite popular already. Cheers, Nico -- Sustainable and modern Infrastructures by ungleich.ch

Re: Multiple Keys per Peer

Roman Mamedov writes: > On Sun, 02 May 2021 13:02:28 +0200 > Nico Schottelius wrote: > >> when running a lot of VPN connections using wireguard, there are some >> questions we see quite often from users, two of which I'd like to >> discuss here: &

Multiple Keys per Peer

is? If there are other suggestions to allow users to decide themselves how to split a range, let's say a /48 IPv6 network, without setting up their own redistribution node, I'd also be interested in hearing that. Best regards, Nico p.s.: I have seen some old messages in the archive about this topic, b

Re: How to verify a wireguard public key?

do you think you need a different/additional way > of verifying the public key? That answer is easy: if you add an incorrect key to your wgX.conf, wg setconf will complain and not apply it. And if you are providing automated VPNs... well, then this is something you do want to prevent. Cheers, Nico

Re: How to verify a wireguard public key?

raise serializers.ValidationError(msg) return value Thanks again and enjoy the quite time over Christmas! Best regards, Nico [0] https://code.ungleich.ch/uncloud/uncloud/-/blob/master/uncloud_net/seriali

How to verify a wireguard public key?

4? Tests with a number of public keys seems to indicate that. Best regards, Nico [0] https://code.ungleich.ch/uncloud/uncloud -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

Re: [PATCH] wg-quick: Linux and FreeBSD: Add support to search domain in wg-quick

I second Mantas in this regard - don't bloat wg-quick, but a DNS search path is pretty standard to be submitted by "a network". We are not talking dhcp boot options, even though NTP servers would probably also make sense, if you see wireguard as providing a network. Best, Nico

Trying to fix the address family problem

g multiple endpoints (even if it is the same host at the other end) in the future? - is there a better way to check reachability without turning wireguard completely off? I have attached the sketch of the script I was writing below in case it helps anyone. B

Re: PostDown 0.0.20191127

Follow up question from my side Jason: what do you think about replacing "$2" in the script with a shifted "$@" and allowing multiple devices to be specified? i.e. wg-quick up wgungleich wgplace4 wgplace11 is something I would like to do in one call and it would potentially be easy to just

Re: Netfilter redirect does not work with wireguard

, Nico p.s.: I was also thinking about needing SNAT, but I don't see any replies generated at the moment. Ivan Labáth writes: > Hello, > > have you checked the source port of replies, or whether > there are any replies? > > # tcpdump -nn > > Tcpdump should show pre-N

Netfilter redirect does not work with wireguard

priority 0; } } However as you can see in the comments, this does not work with wireguard, however it does work with SSH. I can see that wireguard is kernel space, and ssh user space, but does that cause the netfilter part to be skipped or am I doing some silly mistake here? Best regards, Nico

Re: Kernel panic on 5.3.1-arch1-1-ARCH

0.0.20190913-1 As everything work[tm], would it be an option to rename it to a warning instead? Best, Nico Nico Schottelius writes: > Hey Jason, > > thanks for the quick reply - I' ll upgrade as soon as a new package is > released and give a status update afterwards. Thanks for tracki

Re: Kernel panic on 5.3.1-arch1-1-ARCH

Hey Jason, thanks for the quick reply - I' ll upgrade as soon as a new package is released and give a status update afterwards. Thanks for tracking it down! Best, Nico Jason A. Donenfeld writes: > This isn't WireGuard, actually. It's a line in wg-quick's bash that > says `ip ru

Kernel panic on 5.3.1-arch1-1-ARCH

, both led to the same result. Does this help anyone to debug the issue? Best regards, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman

Re: Adding 2FA to WireGuard

Hey Rémi, Rémi Lapeyre writes: > Hi Nico, yes pyotp is the implementation I use on the server, but anything > Compatible withrfc6238 should work. That sounds about right! >> We have written ungleich-otp [0] that extends the otp approach with >> realms similar to kerber

Re: Adding 2FA to WireGuard

routes / servers in your network that can send traffic *from* that particular IP range, your assumption should hold. Best, Nico [0] https://code.ungleich.ch/ungleich-public/ungleich-otp Rémi Lapeyre writes: > Hi everybody! We are using WireeGuard on Mac and Linux which works gr

IPv6 VPN: Routing issue with macos client

IPv4 nameservers are not being used or reachable anymore - there the "fix" was to add IPv6 nameservers to the wireguard configuration. Is there any way to only send IPv6 traffic through wireguard with macos? Best, Nico # Wireguard on: --- 185.203.112.17 ping statistics --- 2 packets t

Status of Bird<->wireguard integration

, but also allowing to easily implement load balancing. Best regards, Nico -- Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo

Support of multiple endpoints to support IPv6/IPv4 protocol change

Hello, TL;DR How difficult is it to add support for multiple endpoints in wireguard? My problem is that sometimes we need to connect to the VPN server via IPv4, sometimes via IPv6 and the other protocol won't work anymore. Long story: We are a cloud provider offering free IPv6 VPNs with VMs,

Wireguard compatible with Omega2 / Omega2+

has experience with such lowe power device, any input would be appreciated. Best, Nico [0] https://onion.io/store/omega2p/ [1] https://onion.io/store/omega2/ -- Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch

Re: Request to change IPv4 preference - mobile apps

Hey Will, I think the "proper" way to handle this is by using the happy eyeballs algorithm: resolve and A, connect to both, use whatever answers first. Best, Nico Will Tisdale writes: > Hello, > > I sent a message to the list about weirdness with IPv4 being pr

Re: Request to change IPv4 preference - mobile apps

<- [v4] <- Τhen the client continues to use either of both protocols, let's say ipv6 was faster in answering: client -> [v6] -> server client <- [v6] <- server ... I don't think this any realistic problem, we are talking about a few bytes per session / r

Android / IPv6 Tunnel / Application connection problems

native IPv6 on WiFi. If required, I can provide access to the same VPN for testing. Best, Nico p.s.: The configuration file I used on the phone is [Interface] PrivateKey = ListenPort = 51280 Address = 2a0a:e5c1:110::/48 [Peer] PublicKey = hi60lGP+xEUQ+kVnqA7PlJAO1SVqTS1W36g0LhFP0xQ= End

Fail to compile - redefinition of may_use_simd

16/commit/adcea6f1a489cb7048f799c3b2bca86d97448324 Please avoid this. Thanks, nico ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard