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 IP addresses.

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

Good morning, Daniel Gröber writes: > [...] > I have a multihomed router [...] following up the thread from February, we migrated away from wireguard to openvpn on systems that have are multi homed. The main reason for that is the following type of connection to a high probability fails to

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 my openwrt

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

Hey Daniel, thanks a lot for diving in ... Daniel Gröber writes: > Let's look at the code (heavily culled): > > struct flowi4 fl = { > .saddr = endpoint->src4.s_addr, > }; > if (cache) > rt = dst_cache_get_ip4(cache, ); What I am wondering is,

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

tlhackque writes: >> [...] >> 4.1 . UDP >> Source Address Selection >> >> ***To avoid these problems, servers when responding to queries >> using UDP _must _cause the reply to be sent with the source address >> field in the IP header

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, which in

Re: Source IP incorrect on multi homed systems

Hey Sebastian, Sebastian Hyrwall writes: > It is kinda. It's been mentioned multiple times over the years but no one > seems to want to fix it. Atleast you should be able to specify bind/src ip in > the > config. I gave up WG because of it. Wasn't accepted by my projects security > policy

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

Hello Mikma, Mikma writes: > Have you tried setting the preferred src address of the route(s) to the > addresses you desire? > > From "man ip": > >> src ADDRESS the source address to prefer when sending to the destinations >> covered by the route prefix. unfortunately this does not solve

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

Arasaratnam writes: > This looks like an asymmetric routing issue from what you’re describing, not > a wireguard issue. > > You may want to look into policy based routing to address it. > > On Sat, Feb 18, 2023 at 15:54 Nico Schottelius > wrote: > > Dear group, > &g

Source IP incorrect on multi homed systems

Dear group, I was wondering how wireguard [Linux kernel] or wireguard-go [FreeBSD] are supposed to decide which IP address to use for replying? I have seen both on FreeBSD and Linux that wireguard seems to use the IP address of the outgoing interface, i.e. the one with the route returning to

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

David Fifield writes: > I am forwarding some information about WireGuard blocking and > anti-blocking that was posted to a censorship circumvention forum. In regards to this topic I was wondering if it makes sense to have a more generic obfuscation proxy that can carry tcp/udp payload? Maybe

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)

Good morning, another day news from the container land. When running wireguard in kubernetes, deleting the existing pod and replacing it with a new one, I see the following behaviour: - The assigned IPv4 address stops being reachable (good so far) - The assigned IPv4 address is then shortly

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

Hello again, while debugging wireguard in Kubernetes, we noticed that adding a default route for IPv4 is not possible/allowed, wg-quick fails with: sysctl: error setting key 'net.ipv4.conf.all.src_valid_mark': Read-only file system Which can be traced back to: [[ $proto ==

Interface not deleted in kubernetes

Hello, I am not sure if I am off-topic here, but I am not sure where to best raise this issue. The situation is: if I start a Pod in Kubernetes that uses the ungleich-wireguard:0.0.5 [0] container, which is basically using this script [1] I am able to get the following output:

Re: WireGuard with obfuscation support

StarBrilliant writes: > On Mon, Sep 27, 2021, at 10:21, Bruno Wolff III wrote: >> If your ISP is blocking your Wireguard traffic call them up and complain. > > All ISPs in China is blocking Wireguard traffic. If you call any of > them up, you will end up in jail. There was a case where one

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

Hey, el3xyz writes: > [...] > To make detection more difficult two things are being done > * handshake initiation, response and cookie messages are padded with random > sized garbage > * Up to 192 bytes of each message is encrypted with obfuscation key derived > from peer public key

Wireguard as a Kubernetes Service

Hello dear WG mailing list, I am interested in running wireguard servers (as in endpoints) inside a kubernetes cluster. I have two different approaches and was wondering what makes more sense: 1) Wireguard in kernel on every participating node Assuming that the kernel module is loaded on the

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

Hey Jason, Jason A. Donenfeld writes: > Hey folks, > > There seems to be a bit of confusion about *which* stage of > fragmentation would be affected by the proposal, so I drew some > diagrams to help illustrate what I'm talking about. Please take a > look: > >

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

Hello, so given that fragmentation is disallowed the PMTU discovery always needs to work and the wireguard MTU needs to be correctly adjusted. Speaking of a DC situation, I think this might be tricky. Imagine the following situation: - endhost A has an MTU of 9k. PMTU 9k. wg 8920. - the path

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

Good morning, 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 -- Users often ask for sharing their connection with multiple devices. The obvious

Re: How to verify a wireguard public key?

Matthias Urlichs writes: > On 25.12.20 00:42, Adam Stiles wrote: >> "How do I validate Curve25519 public keys?" > > You send a handshake packet to the owner of the corresponding private > key and observe whether it accepted it. > > The question is, why do you think you need a

Re: How to verify a wireguard public key?

s a bit redundant, but the > reference above is a good one. > > Best, > > Adam > > > On Thu, Dec 24, 2020 at 3:21 PM Nico Schottelius > wrote: >> >> >> Good morning, >> >> I am currently extending uncloud [0] to support wireguard tunnels

How to verify a wireguard public key?

Good morning, I am currently extending uncloud [0] to support wireguard tunnels and keys. At the moment it is not entirely clear how to verify that a certain string is a valid wireguard key. I first tried checking that it is valid base64, but not all base64 strings are valid wireguard keys.

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 Mantas

Trying to fix the address family problem

est, Nico #!/bin/sh # 2020-01-19 # Nico Schottelius # Periodically fix the wireguard endpoint endpoint=vpn-2a0ae5c1.ungleich.ch tunnel=wgungleich config=/etc/wireguard/${tunnel}.conf endpoint=$(grep -i ^endpoint ${config} | cut -d= -f2) host=$(echo $end

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

t; > Regards, > Ivan > > On Thu, Nov 07, 2019 at 05:38:42PM +0100, Nico Schottelius wrote: >> >> Hello, >> >> I am experimenting with nft / netfilter redirects to support wireguard >> packets on *any* udp port. I tried using the following configuration for >

Netfilter redirect does not work with wireguard

Hello, I am experimenting with nft / netfilter redirects to support wireguard packets on *any* udp port. I tried using the following configuration for nftables: [17:34:14] vpn-2a0ae5c1:~# cat /etc/nftables.conf #!/usr/sbin/nft -f flush ruleset table ip nat { chain prerouting {

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 rule add ...

Kernel panic on 5.3.1-arch1-1-ARCH

Hello, loading the kernel module and starting wg-quick causes a kernel panic on Arch Linux w/ the above mentioned kernel. I have uploaded a camera based screen shot to https://www.nico.schottelius.org/temp/IMG_20191005_221751.jpg I tried both the wireguard-arch and wireguard-dkms approach,

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 kerberos. > > This looks

Re: Adding 2FA to WireGuard

Hey Rémi, that is very welcome news. We might actually also be interested in this. Are you by any change using pyotp for your server? We have written ungleich-otp [0] that extends the otp approach with realms similar to kerberos. In regard to faking the address: given that there are no other

IPv6 VPN: Routing issue with macos client

Hello, when using IPv6 only VPNs on macos, IPv4 traffic outside of the local network stops working. I am using the latest macos client as found in the app store. I have seen similar issues with the Android client before, where DNS resolution will fail with IPv6 only VPNs, because the regular

Status of Bird<->wireguard integration

Hello again, I was wondering what the status is of the integration of wireguard into bird and whether there is any help needed? I am wondering, because integrating wireguard into bird would easily allow to create wireguard server clusters that would announce only the connected clients via BGP:

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+

Good evening, I was wondering if an MT7688 SoC that features a 580 MHz MIPS CPU is feasible for running wireguard? With either 64 or 128 MB RAM. To be specific, we are considering to get a a batch of Omega2/Omega2 [0][1] and deploy IPv6 nodes on it that get their IPs via wireguard. If anyone

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 preferred > over IPv6 in

Re: Request to change IPv4 preference - mobile apps

sses over real > v6 addresses too - and using NAT64 instead of native v6 is really broken > behaviour. > > > Cheers, > > > -Will > > On Mon, 6 May 2019 at 21:57, Nico Schottelius > wrote: > >> >> Hey Will, >> >> I think the "pro

Android / IPv6 Tunnel / Application connection problems

Hello, when trying to route ::/0 (only; no IPv4) on Android 9 using latest wireguard app on mobile network I experience the following behaviour: * chrome works * nextcloud works * hangouts works * mattermost works * whatsapp works * instagram works * roundcube works * analytics gets stuck