From szymonn841 at gmail.com Mon Jan 2 11:11:20 2023 From: szymonn841 at gmail.com (Szymon Nowak) Date: Mon, 2 Jan 2023 12:11:20 +0100 Subject: Fwd: Wireguard Windows version two bugs In-Reply-To: References: Message-ID: I found two Wireguard problems under Windows and am looking for help First problem When you generate a key, its first character is ?\? or ?+? then the peer configuration does not work properly and you cannot connect to such configured client Exampe C:\Program Files\WireGuard>wg genpsk +RFmc+cEztZ/XcNquWvUJdNqlVfYWB3fM7bVCDaUOV4= [Peer] PublicKey = vruCee8G/DSwxotMHfhYQu8hcDEyi6uX4XEjT4FDxDc= PresharedKey = +RFmc+cEztZ/XcNquWvUJdNqlVfYWB3fM7bVCDaUOV4= All the peers below stop working Second problem The Wireguard network IP address registers itself in DNS all the time and ignores the setting that it should not register the connection in DNS. This is a big problem on a Windows domain controller, because then clients from the LAN side can't connect because the server is constantly reporting from Wireguard's IP. I set RegisterThisConnectionsAddress to false powershell.exe -command "Get-NetAdapter peer_server | Set-DnsClient -RegisterThisConnectionsAddress $false" I set the metric high so that interfacet is not the main connection powershell.exe -command "Set-NetIPInterface -InterfaceAlias peer_server -InterfaceMetric 5000" peer.conf (on Domian controler ) [Interface] Address = 10.20.0.1/24 ListenPort = 51820 PrivateKey = WKUBw36Y8f04Ke6dgaXVUJPWYXcF5E2IIDUvQ+omX2Q= PostUp = powershell.exe -command "Get-NetAdapter peer_server | Set-DnsClient -RegisterThisConnectionsAddress $false ; Set-NetIPInterface -InterfaceAlias peer_server -InterfaceMetric 5000" Despite these settings, Wireguard still registers its address with the DNS server -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 45958 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 7988 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 12175 bytes Desc: not available URL: From therealgraysky at proton.me Sun Jan 1 20:11:17 2023 From: therealgraysky at proton.me (John) Date: Sun, 01 Jan 2023 20:11:17 +0000 Subject: WiFi network flaky/WireGuard connections inconsistent Message-ID: I am experiencing hit-or-miss connectivity through wireguard when connected to a specific, unsecured, public WiFi from iOS devices. Meaning, I first connect to the public WiFi at which point, wireless works fine, websites load, etc. but when I subsequently initiate a wireguard connection, most of the time, the traffic flows stops due to a connectivity issue. If I fiddle with toggling the WG connection off then on several times, it eventually works. Through searching, some suggestions about lowering the MTU value to improve stability are mentioned. I tried lowering the MTU size on the interface to 1440 and then again to 1280 but neither made a difference. Wondering if more experienced people here have some suggestions. Here is the log from the iOS client when I attempt to connect: 2022-11-05 15:22:59.205912: [NET] App version: 1.0.15 (26) 2022-11-05 15:22:59.206042: [NET] Starting tunnel from the OS directly, rather than the app 2022-11-05 15:22:59.434059: [NET] DNS64: mapped xxx.xxx.xxx.xxx to itself. 2022-11-05 15:22:59.435425: [NET] Attaching to interface 2022-11-05 15:22:59.436179: [NET] UAPI: Updating private key 2022-11-05 15:22:59.436173: [NET] Routine: handshake worker 3 - started 2022-11-05 15:22:59.436234: [NET] Routine: decryption worker 2 - started 2022-11-05 15:22:59.436244: [NET] Routine: encryption worker 2 - started 2022-11-05 15:22:59.436489: [NET] Routine: decryption worker 3 - started 2022-11-05 15:22:59.436532: [NET] Routine: encryption worker 3 - started 2022-11-05 15:22:59.436605: [NET] Routine: handshake worker 2 - started 2022-11-05 15:22:59.436659: [NET] Routine: decryption worker 5 - started 2022-11-05 15:22:59.436793: [NET] Routine: encryption worker 1 - started 2022-11-05 15:22:59.436856: [NET] Routine: encryption worker 4 - started 2022-11-05 15:22:59.436864: [NET] UAPI: Removing all peers 2022-11-05 15:22:59.436903: [NET] Routine: decryption worker 1 - started 2022-11-05 15:22:59.436924: [NET] Routine: decryption worker 6 - started 2022-11-05 15:22:59.436940: [NET] Routine: handshake worker 6 - started 2022-11-05 15:22:59.436969: [NET] Routine: TUN reader - started 2022-11-05 15:22:59.437424: [NET] Routine: handshake worker 1 - started 2022-11-05 15:22:59.437493: [NET] Routine: decryption worker 4 - started 2022-11-05 15:22:59.437554: [NET] Routine: encryption worker 5 - started 2022-11-05 15:22:59.437553: [NET] peer(fTiT?qSc) - UAPI: Created 2022-11-05 15:22:59.437572: [NET] Routine: handshake worker 4 - started 2022-11-05 15:22:59.437610: [NET] Routine: handshake worker 5 - started 2022-11-05 15:22:59.437654: [NET] Routine: encryption worker 6 - started 2022-11-05 15:22:59.437674: [NET] peer(fTiT?qSc) - UAPI: Updating preshared key 2022-11-05 15:22:59.437755: [NET] Routine: event worker - started 2022-11-05 15:22:59.437901: [NET] peer(fTiT?qSc) - UAPI: Updating endpoint 2022-11-05 15:22:59.438089: [NET] peer(fTiT?qSc) - UAPI: Updating persistent keepalive interval 2022-11-05 15:22:59.438175: [NET] peer(fTiT?qSc) - UAPI: Removing all allowedips 2022-11-05 15:22:59.438303: [NET] peer(fTiT?qSc) - UAPI: Adding allowedip 2022-11-05 15:22:59.438818: [NET] UDP bind has been updated 2022-11-05 15:22:59.438848: [NET] Routine: receive incoming v4 - started 2022-11-05 15:22:59.438881: [NET] Routine: receive incoming v6 - started 2022-11-05 15:22:59.438909: [NET] peer(fTiT?qSc) - Starting 2022-11-05 15:22:59.439099: [NET] Interface state was Down, requested Up, now Up 2022-11-05 15:22:59.439187: [NET] Device started 2022-11-05 15:22:59.439263: [NET] peer(fTiT?qSc) - Routine: sequential receiver - started 2022-11-05 15:22:59.439307: [NET] peer(fTiT?qSc) - Routine: sequential sender - started 2022-11-05 15:22:59.439450: [NET] Tunnel interface is utun3 2022-11-05 15:22:59.440162: [NET] Network change detected with satisfied route and interface order [en0, pdp_ip0] 2022-11-05 15:22:59.440584: [NET] DNS64: mapped xxx.xxx.xxx.xxx to itself. 2022-11-05 15:22:59.440704: [NET] peer(fTiT?qSc) - UAPI: Updating endpoint 2022-11-05 15:22:59.440914: [NET] Routine: receive incoming v4 - stopped 2022-11-05 15:22:59.440962: [NET] Routine: receive incoming v6 - stopped 2022-11-05 15:22:59.441407: [NET] UDP bind has been updated 2022-11-05 15:22:59.441437: [NET] Routine: receive incoming v4 - started 2022-11-05 15:22:59.441469: [NET] Routine: receive incoming v6 - started 2022-11-05 15:22:59.949393: [NET] Network change detected with satisfied route and interface order [en0, utun3, pdp_ip0] 2022-11-05 15:22:59.950074: [NET] DNS64: mapped xxx.xxx.xxx.xxx to itself. 2022-11-05 15:22:59.950390: [NET] peer(fTiT?qSc) - UAPI: Updating endpoint 2022-11-05 15:22:59.950768: [NET] Routine: receive incoming v4 - stopped 2022-11-05 15:22:59.950954: [NET] Routine: receive incoming v6 - stopped 2022-11-05 15:22:59.951485: [NET] UDP bind has been updated 2022-11-05 15:22:59.951505: [NET] Routine: receive incoming v4 - started 2022-11-05 15:22:59.951581: [NET] Routine: receive incoming v6 - started 2022-11-05 15:22:59.969322: [NET] peer(fTiT?qSc) - Sending handshake initiation 2022-11-05 15:23:00.063463: [NET] peer(fTiT?qSc) - Received handshake response 2022-11-05 15:23:15.226385: [NET] peer(fTiT?qSc) - Retrying handshake because we stopped hearing back after 15 seconds 2022-11-05 15:23:15.226767: [NET] peer(fTiT?qSc) - Sending handshake initiation 2022-11-05 15:23:19.863684: [NET] Stopping tunnel 2022-11-05 15:23:19.864322: [NET] Device closing 2022-11-05 15:23:19.864617: [NET] Routine: TUN reader - stopped 2022-11-05 15:23:19.864730: [NET] Routine: event worker - stopped 2022-11-05 15:23:19.864842: [NET] Routine: receive incoming v4 - stopped 2022-11-05 15:23:19.864939: [NET] Routine: receive incoming v6 - stopped 2022-11-05 15:23:19.865193: [NET] peer(fTiT?qSc) - Stopping 2022-11-05 15:23:19.865364: [NET] peer(fTiT?qSc) - Routine: sequential sender - stopped 2022-11-05 15:23:19.865368: [NET] peer(fTiT?qSc) - Routine: sequential receiver - stopped 2022-11-05 15:23:19.865511: [NET] Device closed 2022-11-05 15:23:19.865507: [NET] Routine: decryption worker 2 - stopped 2022-11-05 15:23:19.865557: [NET] Routine: handshake worker 2 - stopped 2022-11-05 15:23:19.865603: [NET] Routine: decryption worker 1 - stopped 2022-11-05 15:23:19.865622: [NET] Routine: handshake worker 4 - stopped 2022-11-05 15:23:19.865627: [NET] Routine: decryption worker 5 - stopped 2022-11-05 15:23:19.865678: [NET] Routine: handshake worker 3 - stopped 2022-11-05 15:23:19.865686: [NET] Routine: decryption worker 3 - stopped 2022-11-05 15:23:19.865748: [NET] Routine: handshake worker 5 - stopped 2022-11-05 15:23:19.865807: [NET] Routine: handshake worker 1 - stopped 2022-11-05 15:23:19.865803: [NET] Routine: decryption worker 4 - stopped 2022-11-05 15:23:19.865814: [NET] Routine: decryption worker 6 - stopped 2022-11-05 15:23:19.865826: [NET] Routine: handshake worker 6 - stopped 2022-11-05 15:23:19.866057: [NET] Routine: encryption worker 5 - stopped 2022-11-05 15:23:19.866072: [NET] Routine: encryption worker 4 - stopped 2022-11-05 15:23:19.866079: [NET] Routine: encryption worker 2 - stopped 2022-11-05 15:23:19.866107: [NET] Routine: encryption worker 3 - stopped 2022-11-05 15:23:19.866135: [NET] Routine: encryption worker 6 - stopped 2022-11-05 15:23:19.866141: [NET] Routine: encryption worker 1 - stopped From jeremy at skidrow.la Wed Jan 4 06:44:21 2023 From: jeremy at skidrow.la (Jeremy Hansen) Date: Tue, 03 Jan 2023 22:44:21 -0800 Subject: Prevent all traffic from going through the WG tunnel Message-ID: <8798af73660eb86c6fd661be90af8b73@skidrow.la> I have a remote network that I've tied in to my WG server. I'm noticing that all traffic from this remote network that goes outbound to the internet is getting routed through my wireguard server. Client config: [Interface] PrivateKey = XXXX Address = 10.10.10.10/32 ListenPort = 51821 [Peer] PublicKey = XXXX Endpoint = 11.11.11.11:51821 <- IP of the WG server. AllowedIPs = 0.0.0.0/0, ::/0 PersistentKeepAlive=25 Server config: [Interface] PrivateKey = XXXX Address = 10.10.10.1/32 ListenPort = 51821 PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eno1 -j MASQUERADE PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eno1 -j MASQUERADE # IP forwarding PreUp = sysctl -w net.ipv4.ip_forward=1 [Peer] PublicKey = XXXX AllowedIPs = 10.10.10.10/32, 192.168.128.0/17 <- Client's internal network. My goal is that regular outbound traffic just goes out the client node's outside routable interface and traffic between the internal networks goes through wireguard. For example, I'm seeing email being sent through the MTA I have configured on the "client" is showing up as originating from the outbound IP of the "server". Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x1BF1B863.asc Type: application/pgp-keys Size: 3959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From szymonn841 at gmail.com Wed Jan 4 16:41:59 2023 From: szymonn841 at gmail.com (Szymon Nowak) Date: Wed, 4 Jan 2023 17:41:59 +0100 Subject: Prevent all traffic from going through the WG tunnel In-Reply-To: <8798af73660eb86c6fd661be90af8b73@skidrow.la> References: <8798af73660eb86c6fd661be90af8b73@skidrow.la> Message-ID: Correct settings AllowedIPs = 10.10.10.10/32, 192.168.128.0/17, ::/1, 8000::/1 On Wed, Jan 4, 2023 at 2:48 PM Jeremy Hansen wrote: > > I have a remote network that I've tied in to my WG server. I'm noticing > that all traffic from this remote network that goes outbound to the > internet is getting routed through my wireguard server. > > Client config: > [Interface] > PrivateKey = XXXX > Address = 10.10.10.10/32 > ListenPort = 51821 > > [Peer] > PublicKey = XXXX > Endpoint = 11.11.11.11:51821 <- IP of the WG server. > AllowedIPs = 0.0.0.0/0, ::/0 > PersistentKeepAlive=25 > > > Server config: > [Interface] > PrivateKey = XXXX > Address = 10.10.10.1/32 > ListenPort = 51821 > > PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i > -j ACCEPT; iptables -t nat -A POSTROUTING -o eno1 -j MASQUERADE > PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o > %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eno1 -j MASQUERADE > > # IP forwarding > PreUp = sysctl -w net.ipv4.ip_forward=1 > > [Peer] > PublicKey = XXXX > AllowedIPs = 10.10.10.10/32, 192.168.128.0/17 <- Client's internal > network. > > > My goal is that regular outbound traffic just goes out the client node's > outside routable interface and traffic between the internal networks > goes through wireguard. > > For example, I'm seeing email being sent through the MTA I have > configured on the "client" is showing up as originating from the > outbound IP of the "server". > > Thanks! From omkhar at gmail.com Wed Jan 4 23:41:04 2023 From: omkhar at gmail.com (Omkhar Arasaratnam) Date: Wed, 4 Jan 2023 18:41:04 -0500 Subject: Prevent all traffic from going through the WG tunnel In-Reply-To: <8798af73660eb86c6fd661be90af8b73@skidrow.la> References: <8798af73660eb86c6fd661be90af8b73@skidrow.la> Message-ID: Are your NAT rules necessary? They seem to be forcing *everything* through --oa --oa On Wed, Jan 4, 2023 at 8:50 AM Jeremy Hansen wrote: > > I have a remote network that I've tied in to my WG server. I'm noticing > that all traffic from this remote network that goes outbound to the > internet is getting routed through my wireguard server. > > Client config: > [Interface] > PrivateKey = XXXX > Address = 10.10.10.10/32 > ListenPort = 51821 > > [Peer] > PublicKey = XXXX > Endpoint = 11.11.11.11:51821 <- IP of the WG server. > AllowedIPs = 0.0.0.0/0, ::/0 > PersistentKeepAlive=25 > > > Server config: > [Interface] > PrivateKey = XXXX > Address = 10.10.10.1/32 > ListenPort = 51821 > > PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i > -j ACCEPT; iptables -t nat -A POSTROUTING -o eno1 -j MASQUERADE > PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o > %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eno1 -j MASQUERADE > > # IP forwarding > PreUp = sysctl -w net.ipv4.ip_forward=1 > > [Peer] > PublicKey = XXXX > AllowedIPs = 10.10.10.10/32, 192.168.128.0/17 <- Client's internal > network. > > > My goal is that regular outbound traffic just goes out the client node's > outside routable interface and traffic between the internal networks > goes through wireguard. > > For example, I'm seeing email being sent through the MTA I have > configured on the "client" is showing up as originating from the > outbound IP of the "server". > > Thanks! From jeremy at skidrow.la Wed Jan 4 17:01:18 2023 From: jeremy at skidrow.la (Jeremy Hansen) Date: Wed, 04 Jan 2023 09:01:18 -0800 Subject: Prevent all traffic from going through the WG tunnel In-Reply-To: References: <8798af73660eb86c6fd661be90af8b73@skidrow.la> Message-ID: Thank you for all who answered. This is working as expected now and I have a better understanding of how the AllowedIPs config works as well. -jeremy On 2023-01-04 06:47, Contact at nagel-mail.com wrote: > Hello, > As I understand your question, you are trying to accomplish, that only > your WireGuard network ( extracted from your config some 10.0.0.0/8 > network. The 192.168.128.0/17 would be a home network?) > Will be routed from your client to your WireGuard server. The rest > should just leave your client network card and routed from your local > network. For that you simply have to set: AllowedIPs = 10.10.10.1/32 > Or the whole 10.x/x Network you are using. > Hope I understood your question correctly. > > Mit freundlichen Gr??en / best regards > > J. Nagel > Fachinformatiker Systemintegration > > Contact at Nagel-Mail.com > >> Am 04.01.2023 um 14:47 schrieb Jeremy Hansen : >> >> ?I have a remote network that I've tied in to my WG server. I'm >> noticing that all traffic from this remote network that goes outbound >> to the internet is getting routed through my wireguard server. >> >> Client config: >> [Interface] >> PrivateKey = XXXX >> Address = 10.10.10.10/32 >> ListenPort = 51821 >> >> [Peer] >> PublicKey = XXXX >> Endpoint = 11.11.11.11:51821 <- IP of the WG server. >> AllowedIPs = 0.0.0.0/0, ::/0 >> PersistentKeepAlive=25 >> >> >> Server config: >> [Interface] >> PrivateKey = XXXX >> Address = 10.10.10.1/32 >> ListenPort = 51821 >> >> PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o >> %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eno1 -j MASQUERADE >> PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o >> %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eno1 -j MASQUERADE >> >> # IP forwarding >> PreUp = sysctl -w net.ipv4.ip_forward=1 >> >> [Peer] >> PublicKey = XXXX >> AllowedIPs = 10.10.10.10/32, 192.168.128.0/17 <- Client's internal >> network. >> >> >> My goal is that regular outbound traffic just goes out the client >> node's outside routable interface and traffic between the internal >> networks goes through wireguard. >> >> For example, I'm seeing email being sent through the MTA I have >> configured on the "client" is showing up as originating from the >> outbound IP of the "server". >> >> Thanks! >> <0x1BF1B863.asc> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x1BF1B863.asc Type: application/pgp-keys Size: 3959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From mailinglist at reox.at Tue Jan 10 09:44:43 2023 From: mailinglist at reox.at (reox) Date: Tue, 10 Jan 2023 10:44:43 +0100 Subject: Connection hangs over CGNAT (Starlink) In-Reply-To: References: Message-ID: Interesting, because I was going to post a similar question here - but would not have thought about multi-network. For me, this happens on my Android phone, where I use WG to route DNS traffic to my own server. In some wifi networks, I get this issue that after some time (sometimes only minutes, sometimes hours), that for example K9mail is unable to fetch mails because it presumably runs into a DNS timeout (it cannot be a connection timeout to the mail server, because that is not routed via WG) Toggling Wifi, switching to mobile network only, or toggling wireguard solves the issue. I had this problem, however, also rarely in other wifis. Before that, I thought that the wifi network itself was the culprit, but as it happens also on other occasions, thus I thought it might be a combination of specific wifi setup and my server setup. However, I have no idea how I could debug this, especially as DNS requests using termux and dig work flawlessly, even though at the same time k9mail hangs. Using KeepAlive did not work so far. I wanted to debug this further by running tcpdump on the server, but unfortunately, I have right now no wifi where I can trigger this bug reliably. In my own wifi, it happens every now and then - typically only once a month or less... Best, Sebastian On 17.12.2022 23:15, Szymon Nowak wrote: > I've noticed the same thing on a WIndows client, it happens when you > provide internet from two sources, e.g. Wifi and mobile network or > Wifi and LAN in case of computer, When one of these sources has a > problem and internet is not available on it. Then Wireguard stops > working even though it doesn't break the tunnel. Completely > disconnecting the faulty connection and reconnecting the tunleu solves > this problem. I don't know why they don't work even though the tunnel > is connected > > On Sat, Dec 17, 2022 at 11:05 PM Nikolay Martynov wrote: >> >> Hi! >> >> I'm experiencing strange behaviour with wireguard: from time to time >> connection 'freezes'. >> Most often I'm observing this on an Android phone when connected from >> my home over Starlink. >> Server: latest Openwrt, Client: latest Android app. >> The connection establishes and works fine for some time. After some >> time the client still shows connection is established, but no incoming >> data is coming. >> On a server side 'latest handshake' goes into hours/days. >> The freeze happens randomly, for no apparent reason and I think only >> over starlink. I do not think I have ever observed this problem on >> cell networks. >> >> Reconnection solves the problem immediately. >> I did some tcpdumping when the problem was present and found the following: >> * Server side sees incoming traffic from the client and sends responses. >> * On my own router connected to Starlink (i.e. interface between my >> router and Starlink router) I see data going from the client to the >> server - but no packets coming back. >> >> So my 'hypothesis' is that somehow Starlink's CGNAT 'forgets' one side >> of the connection - and so data continues to go in one direction, but >> it doesn't come back. The thing with the wireguard is that it looks >> like it doesn't change the outgoing port when it attempts to do >> another handshake. This means that it continues using the same 'half >> broken' connection forever. >> >> I think the same happens to me at least once on a Linux client - but >> the difference with the phone is that the phone is always on and >> therefore the duration of the connection is much longer. >> >> I tried experimenting with keepalive messages - but it looks like they >> make no difference. Once connection freezes I see keepalived arriving >> onto the server, server sending reply - but that reply never arrives >> to the client. >> >> It looks like the solution to this problem would be for the client to >> use a different outgoing port when sending a handshake but I was not >> able to find an option for that. >> >> Is this something that is possible to do? >> Thanks! >> >> >> -- >> Martynov Nikolay. >> Email: mar.kolya at gmail.com From nikolay at oldum.net Tue Jan 10 10:55:10 2023 From: nikolay at oldum.net (Nikolay Kichukov) Date: Tue, 10 Jan 2023 12:55:10 +0200 Subject: Connection hangs over CGNAT (Starlink) In-Reply-To: References: <2c5180c0a406fb9a68f367213940d06b2d4340ec.camel@withtel.com.au> Message-ID: <49a4dbc328213540a1406683b4dd37cf2e45910e.camel@oldum.net> Hi folks, I am getting similar experience (though it looks like different underlying problem) on iOS 12 device running latest wireguard application using cellular (LTE) network for the VPN tunnel. Very randomly, it may be from a couple of days up to at most 4 days with the VPN being active the server peer stops receiving the keepalive packets because the tunnel has become inactive in wireguard client. It then requires manual interaction to enable it which then connects instantly. tcpdump on the server peer does not indicate any incoming traffic when it happens, so it is most likely a iOS client component crash. Cheers, -N On Fri, 2022-12-30 at 20:08 -0500, Nikolay Martynov wrote: > Hi! > > FWIW, reducing MTU doesn't seem to help. Also it looks like I almost > never experience this on a cell network and experience this sometimes > multiple times in an hour on startlink. > At any rate the problem can easily be simulated by just using > iptables. If for whatever reason packets are cut on the return path > for an established connection a new connection (with new source port) > is not reestablished resulting in connection effectively hanging > forever. I do not want to sound too presumptuous, but this seems like > a clear bug to me. > > On Sun, Dec 18, 2022 at 10:41 PM Dean Davis > wrote: > > > > hi > > > > > > same issue > > > > > > I do kind of a automated ping test and if fails on the server side > > to > > many times bring down interface and then back up in a bash script > > > > with > > > > nmcli connection down wg0 && nmcli connection up wg0 > > > > > > to me it looks to be connection state issue difference between new > > and > > established/related? ( can not confirm ) > > > > > > ugly but works for me > > > > > > > > regards > > dean > > > > > > On Thu, 2022-12-15 at 21:12 -0500, Nikolay Martynov wrote: > > > Hi! > > > > > > I'm experiencing strange behaviour with wireguard: from time to > > > time > > > connection 'freezes'. > > > Most often I'm observing this on an Android phone when connected > > > from > > > my home over Starlink. > > > Server: latest Openwrt, Client: latest Android app. > > > The connection establishes and works fine for some time. After > > > some > > > time the client still shows connection is established, but no > > > incoming > > > data is coming. > > > On a server side 'latest handshake' goes into hours/days. > > > The freeze happens randomly, for no apparent reason and I think > > > only > > > over starlink. I do not think I have ever observed this problem on > > > cell networks. > > > > > > Reconnection solves the problem immediately. > > > I did some tcpdumping when the problem was present and found the > > > following: > > > * Server side sees incoming traffic from the client and sends > > > responses. > > > * On my own router connected to Starlink (i.e. interface between > > > my > > > router and Starlink router) I see data going from the client to > > > the > > > server - but no packets coming back. > > > > > > So my 'hypothesis' is that somehow Starlink's CGNAT 'forgets' one > > > side > > > of the connection - and so data continues to go in one direction, > > > but > > > it doesn't come back. The thing with the wireguard is that it > > > looks > > > like it doesn't change the outgoing port when it attempts to do > > > another handshake. This means that it continues using the same > > > 'half > > > broken' connection forever. > > > > > > I think the same happens to me at least once on a Linux client - > > > but > > > the difference with the phone is that the phone is always on and > > > therefore the duration of the connection is much longer. > > > > > > I tried experimenting with keepalive messages - but it looks like > > > they > > > make no difference. Once connection freezes I see keepalived > > > arriving > > > onto the server, server sending reply - but that reply never > > > arrives > > > to the client. > > > > > > It looks like the solution to this problem would be for the client > > > to > > > use a different outgoing port when sending a handshake but I was > > > not > > > able to find an option for that. > > > > > > Is this something that is possible to do? > > > Thanks! > > > > > > > > > > From venkata at instasafe.com Wed Jan 11 11:57:27 2023 From: venkata at instasafe.com (Venkatakrishna S) Date: Wed, 11 Jan 2023 17:27:27 +0530 Subject: Wireguard Handshake failures Message-ID: I came across a weird problem when I connect and disconnect continuously. The handshakes are failing and the wireguard(server) is generating and destroying key pairs continuously for the client. I have added the wireguard logs ,client and server configuration below. Checked the iptable input rules for the client , those are correct. But the wireguard traffic is blocked. Tried with persistent-keepalive enabled and disabled. The same conf below works if I do not connect and disconnect continuously within a short span of time. It starts working after I stop the wireguard on my client and remove the peer on the server. Need help as I'm unable to figure out the root cause. Thanks in advance! Server conf : # interface_server start Created by wrapper @ 2022-12-28 17:02:22.645524175 +0000 UTC [Interface] Address = 10.0.0.48/26 ListenPort = 443 PrivateKey = PostUp = sysctl -w net.ipv4.ip_forward=1; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; SaveConfig = false # interface_server end Client conf : PrivateKey = Address = 10.0.0.41/32 DNS = 8.8.8.8, 8.8.4.4 [Peer] PublicKey = AllowedIPs = , , , 8.8.8.8/32, 8.8.4.4/32 Endpoint = endpointip:443 Server Wireguard logs : [Wed Jan 11 11:42:21 2023] wireguard: wg0: Sending handshake response to peer 247 (ip:port) [Wed Jan 11 11:42:21 2023] wireguard: wg0: Keypair 12666 destroyed for peer 247 [Wed Jan 11 11:42:21 2023] wireguard: wg0: Keypair 12667 created for peer 247 [Wed Jan 11 11:42:26 2023] wireguard: wg0: Receiving handshake initiation from peer 247 (ip:port) [Wed Jan 11 11:42:26 2023] wireguard: wg0: Sending handshake response to peer 247 (ip:port) [Wed Jan 11 11:42:26 2023] wireguard: wg0: Keypair 12667 destroyed for peer 247 [Wed Jan 11 11:42:26 2023] wireguard: wg0: Keypair 12668 created for peer 247 [Wed Jan 11 11:42:31 2023] wireguard: wg0: Receiving handshake initiation from peer 247 (ip:port) [Wed Jan 11 11:42:31 2023] wireguard: wg0: Sending handshake response to peer 247 (ip:port) [Wed Jan 11 11:42:31 2023] wireguard: wg0: Keypair 12668 destroyed for peer 247 [Wed Jan 11 11:42:31 2023] wireguard: wg0: Keypair 12669 created for peer 247 [Wed Jan 11 11:42:36 2023] wireguard: wg0: Receiving handshake initiation from peer 247 (ip:port) [Wed Jan 11 11:42:36 2023] wireguard: wg0: Sending handshake response to peer 247 (ip:port) [Wed Jan 11 11:42:36 2023] wireguard: wg0: Keypair 12669 destroyed for peer 247 [Wed Jan 11 11:42:36 2023] wireguard: wg0: Keypair 12670 created for peer 247 [Wed Jan 11 11:42:41 2023] wireguard: wg0: Receiving handshake initiation from peer 247 (ip:port) [Wed Jan 11 11:42:41 2023] wireguard: wg0: Sending handshake response to peer 247 (ip:port) [Wed Jan 11 11:42:41 2023] wireguard: wg0: Keypair 12670 destroyed for peer 247 [Wed Jan 11 11:42:41 2023] wireguard: wg0: Keypair 12671 created for peer 247 [Wed Jan 11 11:42:46 2023] wireguard: wg0: Receiving handshake initiation from peer 247 (ip:port) [Wed Jan 11 11:42:46 2023] wireguard: wg0: Sending handshake response to peer 247 (ip:port) [Wed Jan 11 11:42:46 2023] wireguard: wg0: Keypair 12671 destroyed for peer 247 [Wed Jan 11 11:42:46 2023] wireguard: wg0: Keypair 12672 created for peer 247 [Wed Jan 11 11:42:51 2023] wireguard: wg0: Receiving handshake initiation from peer 247 (ip:port) [Wed Jan 11 11:42:51 2023] wireguard: wg0: Sending handshake response to peer 247 (ip:port) [Wed Jan 11 11:42:51 2023] wireguard: wg0: Keypair 12672 destroyed for peer 247 [Wed Jan 11 11:42:51 2023] wireguard: wg0: Keypair 12673 created for peer 247 Client Logs : 2023-01-11 17:10:28.493: [TUN] [ZTNATunnelService] Sending handshake initiation to peer 7 (endpoint:port) 2023-01-11 17:10:33.601: [TUN] [ZTNATunnelService] Handshake for peer 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) 2023-01-11 17:10:33.601: [TUN] [ZTNATunnelService] Sending handshake initiation to peer 7 (endpoint:port) 2023-01-11 17:10:38.616: [TUN] [ZTNATunnelService] Handshake for peer 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) 2023-01-11 17:10:38.616: [TUN] [ZTNATunnelService] Sending handshake initiation to peer 7 (endpoint:port) 2023-01-11 17:10:43.637: [TUN] [ZTNATunnelService] Handshake for peer 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) 2023-01-11 17:10:43.637: [TUN] [ZTNATunnelService] Sending handshake initiation to peer 7 (endpoint:port) 2023-01-11 17:10:48.699: [TUN] [ZTNATunnelService] Handshake for peer 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) 2023-01-11 17:10:48.699: [TUN] [ZTNATunnelService] Sending handshake initiation to peer 7 (endpoint:port) 2023-01-11 17:10:53.781: [TUN] [ZTNATunnelService] Handshake for peer 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) 2023-01-11 17:10:53.781: [TUN] [ZTNATunnelService] Sending handshake initiation to peer 7 (endpoint:port) 2023-01-11 17:10:58.835: [TUN] [ZTNATunnelService] Handshake for peer 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) 2023-01-11 17:10:58.835: [TUN] [ZTNATunnelService] Sending handshake initiation to peer 7 (endpoint:port) 2023-01-11 17:11:03.922: [TUN] [ZTNATunnelService] Handshake for peer 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) 2023-01-11 17:11:03.922: [TUN] [ZTNATunnelService] Sending handshake initiation to peer 7 (endpoint:port) 2023-01-11 17:11:08.968: [TUN] [ZTNATunnelService] Handshake for peer 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) 2023-01-11 17:11:08.968: [TUN] [ZTNATunnelService] Sending handshake initiation to peer 7 (endpoint:port) 2023-01-11 17:11:14.079: [TUN] [ZTNATunnelService] Handshake for peer 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) 2023-01-11 17:11:14.079: [TUN] [ZTNATunnelService] Sending handshake initiation to peer 7 (endpoint:port) 2023-01-11 17:11:19.183: [TUN] [ZTNATunnelService] Handshake for peer 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) 2023-01-11 17:11:19.183: [TUN] [ZTNATunnelService] Sending handshake initiation to peer 7 (endpoint:port) 2023-01-11 17:11:24.196: [TUN] [ZTNATunnelService] Handshake for peer 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) 2023-01-11 17:11:24.196: [TUN] [ZTNATunnelService] Sending handshake initiation to peer 7 (endpoint:port) 2023-01-11 17:11:29.345: [TUN] [ZTNATunnelService] Handshake for peer 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) 2023-01-11 17:11:29.345: [TUN] [ZTNATunnelService] Sending handshake initiation to peer 7 (endpoint:port) 2023-01-11 17:11:34.360: [TUN] [ZTNATunnelService] Sending handshake initiation to peer 7 (endpoint:port) 2023-01-11 17:11:39.376: [TUN] [ZTNATunnelService] Handshake for peer 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) 2023-01-11 17:11:39.376: [TUN] [ZTNATunnelService] Sending handshake initiation to peer 7 (endpoint:port) 2023-01-11 17:11:44.537: [TUN] [ZTNATunnelService] Handshake for peer 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) 2023-01-11 17:11:44.537: [TUN] [ZTNATunnelService] Sending handshake initiation to peer 7 (endpoint:port) From wireguard-mail at chil.at Mon Jan 16 23:45:48 2023 From: wireguard-mail at chil.at (Christoph Loesch) Date: Tue, 17 Jan 2023 00:45:48 +0100 Subject: User on mailinglist that collects addresses to send spam? Message-ID: <5d0d60df-ee8c-87ab-379b-31ed33675668@chil.at> Hi, sorry for this unrelated mail. I use a separate mail-address for every site/contact who wants my mail-address. Just checked my spam-folder and what do I see? a mail from janisa at onertronics.com to my wireguard mail-address which I use only for this mailinglist. So I guess janisa at onertronics.com is collecting mail-addresses here and then sending unwanted spam-mails. If this user is on this list, I would recommend to remove this address. proof: (on request I can also provide full mail headers) Subject: ??? AW: quote for TI part Date: ??? Wed, 11 Jan 2023 19:26:42 +0900 From: ??? Janisa Answer to: ??? janisa at onertronics.com To: ??? CUST Hi Purchaser? Happy New Year! I hope you had a great Christmas and some enjoyable down time. Hope cooperate with you and explore new opportunities and achieve great success in the next 2023! Are you searching for these two parts too? Pls check our offer? THVD1429DR TI 2022+ 3.284usd CDCLVP1204RGTR? TI 2019+ 0.986usd ... etc ... Kind regards, Chris From jaron-wg at kent-dobias.com Tue Jan 17 09:35:54 2023 From: jaron-wg at kent-dobias.com (Jaron Kent-Dobias) Date: Tue, 17 Jan 2023 10:35:54 +0100 Subject: User on mailinglist that collects addresses to send spam? In-Reply-To: <5d0d60df-ee8c-87ab-379b-31ed33675668@chil.at> References: <5d0d60df-ee8c-87ab-379b-31ed33675668@chil.at> Message-ID: Hello, On Tuesday, 17 January 2023 at 00:45 (+0100), Christoph Loesch wrote: >I use a separate mail-address for every site/contact who wants my >mail-address. Just checked my spam-folder and what do I see? a mail >from janisa at onertronics.com to my wireguard mail-address which I use >only for this mailinglist. So I guess janisa at onertronics.com is >collecting mail-addresses here and then sending unwanted spam-mails. It's nothing so complicated: the wireguard list is publicly archived online, addresses included (with minor obfuscation). An example: https://lists.zx2c4.com/pipermail/wireguard/2019-July/004276.html Jaron From wireguard-mail at chil.at Tue Jan 17 18:42:43 2023 From: wireguard-mail at chil.at (Christoph Loesch) Date: Tue, 17 Jan 2023 19:42:43 +0100 Subject: User on mailinglist that collects addresses to send spam? In-Reply-To: References: <5d0d60df-ee8c-87ab-379b-31ed33675668@chil.at> Message-ID: Hi, thank you for the for explanation. Interesting, some months ago I wanted to lookup something in the archive and couldn't access it, so I assumed since then that the archive is not publicly available. Was maybe some hickup or temporary issue... Well, that explains it then.. Thanks and kind regards! Am 17.01.2023 um 10:35 schrieb Jaron Kent-Dobias: > Hello, > > On Tuesday, 17 January 2023 at 00:45 (+0100), Christoph Loesch wrote: >> I use a separate mail-address for every site/contact who wants my mail-address. Just checked my spam-folder and what do I see? a mail from janisa at onertronics.com to my wireguard mail-address which I use only for this mailinglist. So I guess janisa at onertronics.com is collecting mail-addresses here and then sending unwanted spam-mails. > > It's nothing so complicated: the wireguard list is publicly archived online, addresses included (with minor obfuscation). > > An example: https://lists.zx2c4.com/pipermail/wireguard/2019-July/004276.html > > Jaron From bjarne-priv at holmedal.net Fri Jan 13 08:55:42 2023 From: bjarne-priv at holmedal.net (Bjarne Nilsson) Date: Fri, 13 Jan 2023 09:55:42 +0100 Subject: Wireguard Handshake failures In-Reply-To: References: Message-ID: <4AD2C855-5228-425A-8EC6-B4E76D9FF95D@holmedal.net> Hello The server needs a peer section for the client, listing the clients public key and the addresses the cliets is alowed to use ( on its interface). Hope this helps > On 12 Jan 2023, at 01:40, Venkatakrishna S wrote: > > ?I came across a weird problem when I connect and disconnect > continuously. The handshakes are failing and the wireguard(server) is > generating and destroying key pairs continuously for the client. I > have added the wireguard logs ,client and server configuration below. > Checked the iptable input rules for the client , those are correct. > But the wireguard traffic is blocked. Tried with persistent-keepalive > enabled and disabled. The same conf below works if I do not connect > and disconnect continuously within a short span of time. It starts > working after I stop the wireguard on my client and remove the peer on > the server. Need help as I'm unable to figure out the root cause. > Thanks in advance! > > Server conf : > # interface_server start Created by wrapper @ 2022-12-28 > 17:02:22.645524175 +0000 UTC > [Interface] > Address = 10.0.0.48/26 > ListenPort = 443 > PrivateKey = > PostUp = sysctl -w net.ipv4.ip_forward=1; iptables -t nat -A > POSTROUTING -o eth0 -j MASQUERADE; > PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; > SaveConfig = false > # interface_server end > > > Client conf : > > PrivateKey = > Address = 10.0.0.41/32 > DNS = 8.8.8.8, 8.8.4.4 > [Peer] > PublicKey = > AllowedIPs = , , , 8.8.8.8/32, 8.8.4.4/32 > Endpoint = endpointip:443 > > > Server Wireguard logs : > > [Wed Jan 11 11:42:21 2023] wireguard: wg0: Sending handshake response > to peer 247 (ip:port) > [Wed Jan 11 11:42:21 2023] wireguard: wg0: Keypair 12666 destroyed for peer 247 > [Wed Jan 11 11:42:21 2023] wireguard: wg0: Keypair 12667 created for peer 247 > [Wed Jan 11 11:42:26 2023] wireguard: wg0: Receiving handshake > initiation from peer 247 (ip:port) > [Wed Jan 11 11:42:26 2023] wireguard: wg0: Sending handshake response > to peer 247 (ip:port) > [Wed Jan 11 11:42:26 2023] wireguard: wg0: Keypair 12667 destroyed for peer 247 > [Wed Jan 11 11:42:26 2023] wireguard: wg0: Keypair 12668 created for peer 247 > [Wed Jan 11 11:42:31 2023] wireguard: wg0: Receiving handshake > initiation from peer 247 (ip:port) > [Wed Jan 11 11:42:31 2023] wireguard: wg0: Sending handshake response > to peer 247 (ip:port) > [Wed Jan 11 11:42:31 2023] wireguard: wg0: Keypair 12668 destroyed for peer 247 > [Wed Jan 11 11:42:31 2023] wireguard: wg0: Keypair 12669 created for peer 247 > [Wed Jan 11 11:42:36 2023] wireguard: wg0: Receiving handshake > initiation from peer 247 (ip:port) > [Wed Jan 11 11:42:36 2023] wireguard: wg0: Sending handshake response > to peer 247 (ip:port) > [Wed Jan 11 11:42:36 2023] wireguard: wg0: Keypair 12669 destroyed for peer 247 > [Wed Jan 11 11:42:36 2023] wireguard: wg0: Keypair 12670 created for peer 247 > [Wed Jan 11 11:42:41 2023] wireguard: wg0: Receiving handshake > initiation from peer 247 (ip:port) > [Wed Jan 11 11:42:41 2023] wireguard: wg0: Sending handshake response > to peer 247 (ip:port) > [Wed Jan 11 11:42:41 2023] wireguard: wg0: Keypair 12670 destroyed for peer 247 > [Wed Jan 11 11:42:41 2023] wireguard: wg0: Keypair 12671 created for peer 247 > [Wed Jan 11 11:42:46 2023] wireguard: wg0: Receiving handshake > initiation from peer 247 (ip:port) > [Wed Jan 11 11:42:46 2023] wireguard: wg0: Sending handshake response > to peer 247 (ip:port) > [Wed Jan 11 11:42:46 2023] wireguard: wg0: Keypair 12671 destroyed for peer 247 > [Wed Jan 11 11:42:46 2023] wireguard: wg0: Keypair 12672 created for peer 247 > [Wed Jan 11 11:42:51 2023] wireguard: wg0: Receiving handshake > initiation from peer 247 (ip:port) > [Wed Jan 11 11:42:51 2023] wireguard: wg0: Sending handshake response > to peer 247 (ip:port) > [Wed Jan 11 11:42:51 2023] wireguard: wg0: Keypair 12672 destroyed for peer 247 > [Wed Jan 11 11:42:51 2023] wireguard: wg0: Keypair 12673 created for peer 247 > > > Client Logs : > > 2023-01-11 17:10:28.493: [TUN] [ZTNATunnelService] Sending handshake > initiation to peer 7 (endpoint:port) > 2023-01-11 17:10:33.601: [TUN] [ZTNATunnelService] Handshake for peer > 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) > 2023-01-11 17:10:33.601: [TUN] [ZTNATunnelService] Sending handshake > initiation to peer 7 (endpoint:port) > 2023-01-11 17:10:38.616: [TUN] [ZTNATunnelService] Handshake for peer > 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) > 2023-01-11 17:10:38.616: [TUN] [ZTNATunnelService] Sending handshake > initiation to peer 7 (endpoint:port) > 2023-01-11 17:10:43.637: [TUN] [ZTNATunnelService] Handshake for peer > 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) > 2023-01-11 17:10:43.637: [TUN] [ZTNATunnelService] Sending handshake > initiation to peer 7 (endpoint:port) > 2023-01-11 17:10:48.699: [TUN] [ZTNATunnelService] Handshake for peer > 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) > 2023-01-11 17:10:48.699: [TUN] [ZTNATunnelService] Sending handshake > initiation to peer 7 (endpoint:port) > 2023-01-11 17:10:53.781: [TUN] [ZTNATunnelService] Handshake for peer > 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) > 2023-01-11 17:10:53.781: [TUN] [ZTNATunnelService] Sending handshake > initiation to peer 7 (endpoint:port) > 2023-01-11 17:10:58.835: [TUN] [ZTNATunnelService] Handshake for peer > 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) > 2023-01-11 17:10:58.835: [TUN] [ZTNATunnelService] Sending handshake > initiation to peer 7 (endpoint:port) > 2023-01-11 17:11:03.922: [TUN] [ZTNATunnelService] Handshake for peer > 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) > 2023-01-11 17:11:03.922: [TUN] [ZTNATunnelService] Sending handshake > initiation to peer 7 (endpoint:port) > 2023-01-11 17:11:08.968: [TUN] [ZTNATunnelService] Handshake for peer > 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) > 2023-01-11 17:11:08.968: [TUN] [ZTNATunnelService] Sending handshake > initiation to peer 7 (endpoint:port) > 2023-01-11 17:11:14.079: [TUN] [ZTNATunnelService] Handshake for peer > 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) > 2023-01-11 17:11:14.079: [TUN] [ZTNATunnelService] Sending handshake > initiation to peer 7 (endpoint:port) > 2023-01-11 17:11:19.183: [TUN] [ZTNATunnelService] Handshake for peer > 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) > 2023-01-11 17:11:19.183: [TUN] [ZTNATunnelService] Sending handshake > initiation to peer 7 (endpoint:port) > 2023-01-11 17:11:24.196: [TUN] [ZTNATunnelService] Handshake for peer > 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) > 2023-01-11 17:11:24.196: [TUN] [ZTNATunnelService] Sending handshake > initiation to peer 7 (endpoint:port) > 2023-01-11 17:11:29.345: [TUN] [ZTNATunnelService] Handshake for peer > 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) > 2023-01-11 17:11:29.345: [TUN] [ZTNATunnelService] Sending handshake > initiation to peer 7 (endpoint:port) > 2023-01-11 17:11:34.360: [TUN] [ZTNATunnelService] Sending handshake > initiation to peer 7 (endpoint:port) > 2023-01-11 17:11:39.376: [TUN] [ZTNATunnelService] Handshake for peer > 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) > 2023-01-11 17:11:39.376: [TUN] [ZTNATunnelService] Sending handshake > initiation to peer 7 (endpoint:port) > 2023-01-11 17:11:44.537: [TUN] [ZTNATunnelService] Handshake for peer > 7 (endpoint:port) did not complete after 5 seconds, retrying (try 2) > 2023-01-11 17:11:44.537: [TUN] [ZTNATunnelService] Sending handshake > initiation to peer 7 (endpoint:port) From andyxheli at gmail.com Fri Jan 13 16:26:58 2023 From: andyxheli at gmail.com (Andy Xheli) Date: Fri, 13 Jan 2023 10:26:58 -0600 Subject: Android TV Wireguard issue Message-ID: Hi All, First I want to thank everyone for this amazing software. The issue that I am having is that i can't add vpn tunnel on my Xiaomi TV stick 4K. This device does not have a USB port and when i click on the + icon on the app im getting an "You don't have an app that can do this" I think it would be nice to have an option to either add it manually for the devices that don't have a USB stick have an option to import via SMB or webdav let me know what you all think From therealgraysky at proton.me Thu Jan 26 08:26:21 2023 From: therealgraysky at proton.me (John) Date: Thu, 26 Jan 2023 08:26:21 +0000 Subject: WiFi network flaky/WireGuard connections inconsistent In-Reply-To: References: Message-ID: <7Ph5G8bkN3KO0RArmDnOxOCTf6CEm3AZdsdvl2vRAJ_yM37RJkJQ_5ySh2EXEs52Ru8AYYwVMOAmiVtqBb332JzvgLD87cWcmAzzZL8kRA0=@proton.me> An update - if I first connect WG while the iPhone is on 5G, and then connect to the WiFi without stopping WG first, it seems to work as expected. Tested and confirmed several times. Will continue monitoring. - Ondemand activation fails - Connecting to the WiFi first and manually selecting a profile fails - Only true with this specific WiFi, ondemand activation works everywhere else ------- Original Message ------- On Sunday, January 1st, 2023 at 3:11 PM, John wrote: > I am experiencing hit-or-miss connectivity through wireguard when connected to a specific, unsecured, public WiFi from iOS devices. Meaning, I first connect to the public WiFi at which point, wireless works fine, websites load, etc. but when I subsequently initiate a wireguard connection, most of the time, the traffic flows stops due to a connectivity issue. If I fiddle with toggling the WG connection off then on several times, it eventually works. > > Through searching, some suggestions about lowering the MTU value to improve stability are mentioned. I tried lowering the MTU size on the interface to 1440 and then again to 1280 but neither made a difference. Wondering if more experienced people here have some suggestions. > > Here is the log from the iOS client when I attempt to connect: > > 2022-11-05 15:22:59.205912: [NET] App version: 1.0.15 (26) > 2022-11-05 15:22:59.206042: [NET] Starting tunnel from the OS directly, rather than the app > 2022-11-05 15:22:59.434059: [NET] DNS64: mapped xxx.xxx.xxx.xxx to itself. > 2022-11-05 15:22:59.435425: [NET] Attaching to interface > 2022-11-05 15:22:59.436179: [NET] UAPI: Updating private key > 2022-11-05 15:22:59.436173: [NET] Routine: handshake worker 3 - started > 2022-11-05 15:22:59.436234: [NET] Routine: decryption worker 2 - started > 2022-11-05 15:22:59.436244: [NET] Routine: encryption worker 2 - started > 2022-11-05 15:22:59.436489: [NET] Routine: decryption worker 3 - started > 2022-11-05 15:22:59.436532: [NET] Routine: encryption worker 3 - started > 2022-11-05 15:22:59.436605: [NET] Routine: handshake worker 2 - started > 2022-11-05 15:22:59.436659: [NET] Routine: decryption worker 5 - started > 2022-11-05 15:22:59.436793: [NET] Routine: encryption worker 1 - started > 2022-11-05 15:22:59.436856: [NET] Routine: encryption worker 4 - started > 2022-11-05 15:22:59.436864: [NET] UAPI: Removing all peers > 2022-11-05 15:22:59.436903: [NET] Routine: decryption worker 1 - started > 2022-11-05 15:22:59.436924: [NET] Routine: decryption worker 6 - started > 2022-11-05 15:22:59.436940: [NET] Routine: handshake worker 6 - started > 2022-11-05 15:22:59.436969: [NET] Routine: TUN reader - started > 2022-11-05 15:22:59.437424: [NET] Routine: handshake worker 1 - started > 2022-11-05 15:22:59.437493: [NET] Routine: decryption worker 4 - started > 2022-11-05 15:22:59.437554: [NET] Routine: encryption worker 5 - started > 2022-11-05 15:22:59.437553: [NET] peer(fTiT?qSc) - UAPI: Created > 2022-11-05 15:22:59.437572: [NET] Routine: handshake worker 4 - started > 2022-11-05 15:22:59.437610: [NET] Routine: handshake worker 5 - started > 2022-11-05 15:22:59.437654: [NET] Routine: encryption worker 6 - started > 2022-11-05 15:22:59.437674: [NET] peer(fTiT?qSc) - UAPI: Updating preshared key > 2022-11-05 15:22:59.437755: [NET] Routine: event worker - started > 2022-11-05 15:22:59.437901: [NET] peer(fTiT?qSc) - UAPI: Updating endpoint > 2022-11-05 15:22:59.438089: [NET] peer(fTiT?qSc) - UAPI: Updating persistent keepalive interval > 2022-11-05 15:22:59.438175: [NET] peer(fTiT?qSc) - UAPI: Removing all allowedips > 2022-11-05 15:22:59.438303: [NET] peer(fTiT?qSc) - UAPI: Adding allowedip > 2022-11-05 15:22:59.438818: [NET] UDP bind has been updated > 2022-11-05 15:22:59.438848: [NET] Routine: receive incoming v4 - started > 2022-11-05 15:22:59.438881: [NET] Routine: receive incoming v6 - started > 2022-11-05 15:22:59.438909: [NET] peer(fTiT?qSc) - Starting > 2022-11-05 15:22:59.439099: [NET] Interface state was Down, requested Up, now Up > 2022-11-05 15:22:59.439187: [NET] Device started > 2022-11-05 15:22:59.439263: [NET] peer(fTiT?qSc) - Routine: sequential receiver - started > 2022-11-05 15:22:59.439307: [NET] peer(fTiT?qSc) - Routine: sequential sender - started > 2022-11-05 15:22:59.439450: [NET] Tunnel interface is utun3 > 2022-11-05 15:22:59.440162: [NET] Network change detected with satisfied route and interface order [en0, pdp_ip0] > 2022-11-05 15:22:59.440584: [NET] DNS64: mapped xxx.xxx.xxx.xxx to itself. > 2022-11-05 15:22:59.440704: [NET] peer(fTiT?qSc) - UAPI: Updating endpoint > 2022-11-05 15:22:59.440914: [NET] Routine: receive incoming v4 - stopped > 2022-11-05 15:22:59.440962: [NET] Routine: receive incoming v6 - stopped > 2022-11-05 15:22:59.441407: [NET] UDP bind has been updated > 2022-11-05 15:22:59.441437: [NET] Routine: receive incoming v4 - started > 2022-11-05 15:22:59.441469: [NET] Routine: receive incoming v6 - started > 2022-11-05 15:22:59.949393: [NET] Network change detected with satisfied route and interface order [en0, utun3, pdp_ip0] > 2022-11-05 15:22:59.950074: [NET] DNS64: mapped xxx.xxx.xxx.xxx to itself. > 2022-11-05 15:22:59.950390: [NET] peer(fTiT?qSc) - UAPI: Updating endpoint > 2022-11-05 15:22:59.950768: [NET] Routine: receive incoming v4 - stopped > 2022-11-05 15:22:59.950954: [NET] Routine: receive incoming v6 - stopped > 2022-11-05 15:22:59.951485: [NET] UDP bind has been updated > 2022-11-05 15:22:59.951505: [NET] Routine: receive incoming v4 - started > 2022-11-05 15:22:59.951581: [NET] Routine: receive incoming v6 - started > 2022-11-05 15:22:59.969322: [NET] peer(fTiT?qSc) - Sending handshake initiation > 2022-11-05 15:23:00.063463: [NET] peer(fTiT?qSc) - Received handshake response > 2022-11-05 15:23:15.226385: [NET] peer(fTiT?qSc) - Retrying handshake because we stopped hearing back after 15 seconds > 2022-11-05 15:23:15.226767: [NET] peer(fTiT?qSc) - Sending handshake initiation > 2022-11-05 15:23:19.863684: [NET] Stopping tunnel > 2022-11-05 15:23:19.864322: [NET] Device closing > 2022-11-05 15:23:19.864617: [NET] Routine: TUN reader - stopped > 2022-11-05 15:23:19.864730: [NET] Routine: event worker - stopped > 2022-11-05 15:23:19.864842: [NET] Routine: receive incoming v4 - stopped > 2022-11-05 15:23:19.864939: [NET] Routine: receive incoming v6 - stopped > 2022-11-05 15:23:19.865193: [NET] peer(fTiT?qSc) - Stopping > 2022-11-05 15:23:19.865364: [NET] peer(fTiT?qSc) - Routine: sequential sender - stopped > 2022-11-05 15:23:19.865368: [NET] peer(fTiT?qSc) - Routine: sequential receiver - stopped > 2022-11-05 15:23:19.865511: [NET] Device closed > 2022-11-05 15:23:19.865507: [NET] Routine: decryption worker 2 - stopped > 2022-11-05 15:23:19.865557: [NET] Routine: handshake worker 2 - stopped > 2022-11-05 15:23:19.865603: [NET] Routine: decryption worker 1 - stopped > 2022-11-05 15:23:19.865622: [NET] Routine: handshake worker 4 - stopped > 2022-11-05 15:23:19.865627: [NET] Routine: decryption worker 5 - stopped > 2022-11-05 15:23:19.865678: [NET] Routine: handshake worker 3 - stopped > 2022-11-05 15:23:19.865686: [NET] Routine: decryption worker 3 - stopped > 2022-11-05 15:23:19.865748: [NET] Routine: handshake worker 5 - stopped > 2022-11-05 15:23:19.865807: [NET] Routine: handshake worker 1 - stopped > 2022-11-05 15:23:19.865803: [NET] Routine: decryption worker 4 - stopped > 2022-11-05 15:23:19.865814: [NET] Routine: decryption worker 6 - stopped > 2022-11-05 15:23:19.865826: [NET] Routine: handshake worker 6 - stopped > 2022-11-05 15:23:19.866057: [NET] Routine: encryption worker 5 - stopped > 2022-11-05 15:23:19.866072: [NET] Routine: encryption worker 4 - stopped > 2022-11-05 15:23:19.866079: [NET] Routine: encryption worker 2 - stopped > 2022-11-05 15:23:19.866107: [NET] Routine: encryption worker 3 - stopped > 2022-11-05 15:23:19.866135: [NET] Routine: encryption worker 6 - stopped > 2022-11-05 15:23:19.866141: [NET] Routine: encryption worker 1 - stopped From wireguard-mail at chil.at Fri Jan 27 23:34:53 2023 From: wireguard-mail at chil.at (Christoph Loesch) Date: Sat, 28 Jan 2023 00:34:53 +0100 Subject: User on mailinglist that collects addresses to send spam? In-Reply-To: References: <5d0d60df-ee8c-87ab-379b-31ed33675668@chil.at> Message-ID: <373d9237-1b23-93cd-fa4e-b5fc14e6007b@chil.at> Hi, wouldn't it be a consideration worth to hide or at least obfuscate mail addresses a bit more in mailman on this list here? Mailman is able to obfuscate this better, see for example on lists.funkfeuer.at Since I wrote the first time here about the "offer" I got, I'm getting more and more "spam" in the last weeks on the address I registered here on this list. How do you work with this situation? Update/add rules in Mailfilter until the next mail comes through? Cat and mouse game? ;) Kind regards, Am 17.01.2023 um 19:42 schrieb Christoph Loesch: > Hi, > > thank you for the for explanation. > > Interesting, some months ago I wanted to lookup something in the archive and couldn't access it, so I assumed since then that the archive is not publicly available. > Was maybe some hickup or temporary issue... > > Well, that explains it then.. > > Thanks and kind regards! > > Am 17.01.2023 um 10:35 schrieb Jaron Kent-Dobias: >> Hello, >> >> On Tuesday, 17 January 2023 at 00:45 (+0100), Christoph Loesch wrote: >>> I use a separate mail-address for every site/contact who wants my mail-address. Just checked my spam-folder and what do I see? a mail from janisa at onertronics.com to my wireguard mail-address which I use only for this mailinglist. So I guess janisa at onertronics.com is collecting mail-addresses here and then sending unwanted spam-mails. >> >> It's nothing so complicated: the wireguard list is publicly archived online, addresses included (with minor obfuscation). >> >> An example: https://lists.zx2c4.com/pipermail/wireguard/2019-July/004276.html >> >> Jaron From nazar at mokrynskyi.com Sat Jan 21 13:22:38 2023 From: nazar at mokrynskyi.com (Nazar Mokrynskyi) Date: Sat, 21 Jan 2023 13:22:38 -0000 Subject: Allow client-side encrypted backups for Android app Message-ID: <5e029a99-a860-0ae0-be72-df53cf82d0ce@mokrynskyi.com> Basically this: https://github.com/seedvault-app/seedvault/wiki/FAQ#why-do-some-apps-not-allow-to-get-backed-up I'm moving to non-rooted ROM for the first time in many years (GrapheneOS) and it is a major pain to configure all the apps manually when apps deliberately disable backups in their apps. According to following example provided it is trivial to do: https://github.com/grote/Transportr/commit/4dc38f429f75909a088d8bd8a5b3b5ddd8030f71 -- Sincerely, Nazar Mokrynskyi github.com/nazar-pc From a.heider at gmail.com Wed Jan 25 09:28:37 2023 From: a.heider at gmail.com (Andre Heider) Date: Wed, 25 Jan 2023 10:28:37 +0100 Subject: android and endpoint dyndns Message-ID: Hi all, I'm using wireguard on android, and it works just fine. The wg endpoint also has it's own dns server, which I too configured on the wg droid app, so I can reach my network boxes with their internal domain names. I also enabled "Always-on VPN" and "Block connections without VPN" on the phone's system settings, so everything goes through the wg interface. When it's not up nothing gets in or out - just as desired. Unfortunately I have to live with a changing ip on the server/endpoint. Which is why I use a dyndns hostname as wg endpoint. Now, if I set "Private DNS" on the droid's system settings to a specific *public* server ("Private DNS provider hostname"), it even works if the ip of my wg server changes! Meaning the wg vpn setup automagically picks up the new ip. (How, btw? Is that an android feature or implemented on the wg app?). But using a public server there obviously breaks reaching my internal boxes using their domain names, since those are only provided by my own dns server. And for that, I have to set "Private DNS" to "Automatic". But that in return breaks the wg setup if my endpoint's ip changes, I have to manually dis/reenable the wg interface then. The workflow/around then becomes: - set "Private DNS" to "Automatic" - disable wg interface - enable wg interface - set "Private DNS" to "Private DNS provider hostname" Which gets really annoying as you can imagine. Is there a solution to this? I guess if the wg app would use a specific dns server to just resolve the endpoint's hostname it should work? Is that possible? Thanks, Andre From andyxheli at gmail.com Wed Jan 25 16:13:36 2023 From: andyxheli at gmail.com (Andy Xheli) Date: Wed, 25 Jan 2023 10:13:36 -0600 Subject: VPN Client don't not disconnect while server is offline Message-ID: Hi All, So I noticed that when I bring down the WireGuard server all the clients still show as connected\active. I noticed it because I brought the server down and I was not able to get out to the internet. I'm doing a split tunnel. I only route my internal network via wireguard and I have set it to use the dns server on my internal network. Looks like it is still trying to use the DNS server via vpn client even if the server is off. I think there should be a better way to handle the connections if the server is offline. The client should not show connected\active or try not to use dns via wiregaurd if the server is offline. What do you all think? From philipp at tiesel.net Sat Jan 28 13:20:06 2023 From: philipp at tiesel.net (Philipp S. Tiesel) Date: Sat, 28 Jan 2023 14:20:06 +0100 Subject: Wireguard packets over IPv6 are not fragmented to path MTU Message-ID: Hi, I have an issue with Wireguard and IPv6 fragmentation where the kernel implementation keeps constantly emitting UDP packets which are too large for the path-MTU despite I see a correct path-MTU in the route cache. Setup details: - Tunnel endpoint A has an interface MTU of 9000 - Path between A and B does not block ICMPv6 - Path MTU is 1500 - First hop on the way from A to B hats an MTU of 9000 and correctly emits ICMPv6 Packet Too Big - Tunnel endpoint B has an interface MTU of 1500 As I have some customer traffic through the tunnel that requires an MTU of 1500, I would like to have the tunnel endpoints to correctly fragment packets. This works as long as the interface MTU is equal to the path MTU, but fails otherwise. If I switch from the Linux-kernel to the Go implementation, fragmentation also works as expected. Does anyone have hint where to start digging why the Linux implementation does not correctly fragment the UDP frames of the Wireguard tunnel if the path-MTU is smaller than the interface-MTU? Software version on endpoint A: - Debian Bookworm - Debian Kernel 6.1.0-1-cloud-amd64 - wireguard-tools v1.0.20210914 AVE! Philipp S. Tiesel -- Philipp S. Tiesel https://philipp.tiesel.net/ From dseliv at gmail.com Sun Jan 29 08:46:18 2023 From: dseliv at gmail.com (Dmitry Selivanov) Date: Sun, 29 Jan 2023 11:46:18 +0300 Subject: [PATCH] wg: Fix show all endpoints output Message-ID: <11c3d877-2d92-8593-0a9f-e2c918a791c3@gmail.com> Currently "wg show all endpoints" prints interface name only once while other "show all" commands print it on each line as man says. --- src/show.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/show.c b/src/show.c index 3fd3d9e..13777cf 100644 --- a/src/show.c +++ b/src/show.c @@ -312,9 +312,9 @@ static bool ugly_print(struct wgdevice *device, const char *param, bool with_int else printf("off\n"); } else if (!strcmp(param, "endpoints")) { - if (with_interface) - printf("%s\t", device->name); for_each_wgpeer(device, peer) { + if (with_interface) + printf("%s\t", device->name); printf("%s\t", key(peer->public_key)); if (peer->endpoint.addr.sa_family == AF_INET || peer->endpoint.addr.sa_family == AF_INET6) printf("%s\n", endpoint(&peer->endpoint.addr)); -- 2.30.2 From jameswynn23 at proton.me Mon Jan 30 12:26:51 2023 From: jameswynn23 at proton.me (James Wynn) Date: Mon, 30 Jan 2023 12:26:51 +0000 Subject: Throughput significantly lower than expected, possible regression? Message-ID: <6bLjfHXI_ooAaDHnWuIx4oVWGCoSbAfYtUxpL4bakYfOSb0nQnfD3viB1b_xFhtpVmpF_OQbFTJza15Ea65FJMwAQ0Avq4raIwVBDFl8L-w=@proton.me> Hi. I noticed a massive performance regression for WireGuard on Ubuntu 20.04, Ubuntu 22.04 and Fedora 37. I reported in Ubuntu and Fedora users mailing list and was advised to post here. It's possible I did something wrong(?), but I have?fully reproducible steps to demonstrate this issue on a vanilla DigitalOcean?droplet, minimal WireGuard configuration and no firewall rules. I've also seen this issue on other hosting providers. Testing between two droplets (over VPC) with `iperf3 -c XXX -P 5`: - DigitalOcean's VPC = ~2Gbps - WireGuard Ubuntu 18.04 = ~1.3Gbps - WireGuard Ubuntu 20.04 = ~400Mbps - WireGuard Ubuntu 22.04 = ~400Mbps - WireGuard Fedora 37 = ~400Mbps htop reported only 20-30% load on the vCPU core so it isn't CPU-bound. After doing these tests, I did them all again on a different day to rule out temporary network congestion. Steps to reproduce below. Repeat with each OS version. 0. Create a DigitalOcean account. 1. Create two $6 droplets (eg, LON1 region) with Regular CPU & 1GB RAM each, called test01 & test02. 2. `apt-get update && DEBIAN_FRONTEND=noninteractive apt-get dist-upgrade -y && reboot` 3. `apt-get install -y wireguard iperf3` 4. On test01, create `/etc/wireguard/test.conf` with these contents. Replace `YYY` with the IP address of the eth1 interface (VPC) on test02. -------------------- [Interface] PrivateKey = wOEa8/RS2v065wgYGQn5k7FqOXuZJ9aC/6NDW569c3g= Address = 192.168.200.10/24 ListenPort = 51820 SaveConfig = false [Peer] PublicKey = wdXOzBptLD/QMZjhG475GErrz95Vpj4S7JPEwzcDMV8= PresharedKey = j5Oeyhu/qDag2LunpVlFqKycp/9CH+Izjza5aq2cYss= Endpoint = YYY:51820 AllowedIPs = 192.168.200.20/32 -------------------- 5. On test02, create `/etc/wireguard/test.conf` with these contents. Replace `XXX` with the IP address of the eth1 interface (VPC) on test01. -------------------- [Interface] PrivateKey = kCJ/4rVDTy86HxP9N5wUmgMF1Esqjc051jQPGhrQIGw= Address = 192.168.200.20/24 ListenPort = 51820 SaveConfig = false [Peer] PublicKey = s/GtXkHOtPsqcNDy0BSRoMuxXYb4hK18dsQdkZk20yQ= PresharedKey = j5Oeyhu/qDag2LunpVlFqKycp/9CH+Izjza5aq2cYss= Endpoint = XXX:51820 AllowedIPs = 192.168.200.10/32 -------------------- 6. On both droplets, run `systemctl start wg-quick at test` 7. On test01, run `iperf3 -s -B XXX`. 8. On test02, run `iperf3 -c XXX -P 5 -t 30` and observe ~2Gbps. 9. On test01, run `iperf3 -s -B 192.168.200.10` 10. On test02, run `iperf3 -c 192.168.200.10 -P 5 -t 30` and observe ~400Mbps. In steps 7 and 8, replace XXX with the IP address of the eth1 interface on test01. From David.Leib at ericom.com Tue Jan 31 11:43:02 2023 From: David.Leib at ericom.com (David Leib) Date: Tue, 31 Jan 2023 11:43:02 +0000 Subject: [PATCH] handle a network adapter ending in a space character Message-ID: Due to a bug in a driver, a network adapter had a space character at the end of the name. This patch should allow the script to correctly read the name of the adapter. --- src/wg-quick/darwin.bash | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/wg-quick/darwin.bash b/src/wg-quick/darwin.bash index 8e46818..b6bb5dc 100755 --- a/src/wg-quick/darwin.bash +++ b/src/wg-quick/darwin.bash @@ -220,7 +220,7 @@ declare -A SERVICE_DNS_SEARCH collect_new_service_dns() { local service get_response local -A found_services - { read -r _ && while read -r service; do + { read -r _ && while IFS= read -r service; do [[ $service == "*"* ]] && service="${service:1}" found_services["$service"]=1 [[ -n ${SERVICE_DNS["$service"]} ]] && continue -- 2.32.0.windows.1 From berkant.ipek at gmail.com Tue Jan 31 18:20:28 2023 From: berkant.ipek at gmail.com (=?UTF-8?Q?Berkant_=C4=B0pek?=) Date: Tue, 31 Jan 2023 21:20:28 +0300 Subject: Encapsulation support in wireguard-go Message-ID: Hi, Does wireguard-go provide any facility in order to encapsulate and decapsulate WireGuard packets as they leave for and arrive from the remote peer? Or, am I just better off to use kernel implementation with a TUN device to handle en- and decapsulation and relaying? Cheers.