Re: Connection hangs over CGNAT (Starlink)
Have you tried reducing the MTU of the WG tunnel? I have a similar use case with a WG tunnel over a T-Mobile Home Internet (TMHI) CGNAT network. After some testing determining the reduced MTU of the TMHI network, I set the WG endpoints' MTU to be 1340. The WG tunnel has been rock solid. Lonnie > On Dec 15, 2022, at 8:12 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.ko...@gmail.com >
Re: WireGuard with obfuscation support
> On Sep 27, 2021, at 8:01 AM, Konstantin Ryabitsev > wrote: > > On Mon, Sep 27, 2021 at 05:21:57AM -0500, Bruno Wolff III wrote: >>> With obfuscation there would be UDP packets of random junk, and it would be >>> a >>> much harder job to come up with a rule to drop those without affecting >>> anything else. >> >> If your ISP is blocking your Wireguard traffic call them up and complain. > > There have been times when I found myself briefly at a location that didn't > allow wireguard traffic, like an airport or a public library. Complaining > wouldn't have been a useful course of action to take, since I needed a > solution at that particular time and place. Public hotspots may just be blocking UDP/51820, not DPI. Some time ago Jason posted an iptables REDIRECT workaround at your WG "server" endpoint [1] I have found typically either 443 or 4500 will work if 51820 is blocked. Lonnie [1] https://lists.zx2c4.com/pipermail/wireguard/2018-November/003503.html
Re: Suggestion for WireGuard
> On Aug 30, 2021, at 8:19 AM, Kassem Omega wrote: > > snip... > > The use case: allowing all traffic to go through WireGuard except > specific ranges. > > Right now to do this I must use this long list of ranges to achieve this: > > AllowedIPs = 0.0.0.0/5, 8.0.0.0/7, 11.0.0.0/8, 12.0.0.0/6, 16.0.0.0/4, > 32.0.0.0/3, 64.0.0.0/2, 128.0.0.0/3, 160.0.0.0/5, 168.0.0.0/6, > 172.0.0.0/12, 172.16.0.0/24, 172.32.0.0/11, 172.64.0.0/10, > 172.128.0.0/9, 173.0.0.0/8, 174.0.0.0/7, 176.0.0.0/4, 192.0.0.0/9, > 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, > 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, > 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 8.8.8.8/32 > > However, if the DisallowedIPs option is available, I'd simply use: > > DisallowedIPs = 192.168.0.0/16, 10.0.0.0/8 For the IPv4-only case, there is a handy C based tool: iprange [1] For your example: Allow: 0.0.0.0/0 Disallow: 192.168.0.0/16, 10.0.0.0/8 $ cat allow.ipset 0.0.0.0/0 $ cat disallow.ipset 192.168.0.0/16 10.0.0.0/8 $ iprange allow.ipset --exclude-next disallow.ipset 0.0.0.0/5 8.0.0.0/7 11.0.0.0/8 12.0.0.0/6 16.0.0.0/4 32.0.0.0/3 64.0.0.0/2 128.0.0.0/2 192.0.0.0/9 192.128.0.0/11 192.160.0.0/13 192.169.0.0/16 192.170.0.0/15 192.172.0.0/14 192.176.0.0/12 192.192.0.0/10 193.0.0.0/8 194.0.0.0/7 196.0.0.0/6 200.0.0.0/5 208.0.0.0/4 224.0.0.0/3 The output is optimized and sorted. Lonnie [1] https://github.com/firehol/iprange
Re: wg syncconf (and setconf) error when one or more endpoints is unresolvable
> On Jun 15, 2021, at 5:52 AM, Jason A. Donenfeld wrote: > > This is intended behavior. DNS resolution happens at config parsing time. Christian, While I appreciate Jason's strict DNS requirement, for the last 2.5 years our project has implemented a trivial patch [1] to ignore endpoint DNS failure. On a DNS failure, essentially ignoring the (optional) Endpoint= dns-hostname peer entry. This has worked well for our use case. WireGuard always starts. Lonnie [1] Ignore endpoint DNS failure https://github.com/astlinux-project/astlinux/blob/master/package/wireguard-tools/wireguard-tools-0001-ignore-endpoint-dns-failure.patch
Re: T-Mobile 4G/5G CGNAT vs WireGuard tunnel jitter
> On Apr 10, 2021, at 11:12 AM, Lonnie Abelbeck > wrote: > >> On Apr 10, 2021, at 10:59 AM, Roman Mamedov wrote: >> >> On Sat, 10 Apr 2021 10:27:23 -0500 >> Lonnie Abelbeck wrote: >> >>> I have been testing the T-Mobile Home Internet (4G/5G fixed wireless) >>> service to a Linode VM via WireGuard. >>> >>> The TMHI service uses CGNAT plus an additional NAT in their modem/gateway >>> with a MTU of 1420, so WireGuard is configured with a 1340 MTU. >> >> Do they provide IPv6? I see mentions that yes, but with incoming connections >> blocked. Might still work for WG. > > Hi Roman, > > TMHI uses IPv6 for their CGNAT, but AFAIK their current firmware does not > support IPv6 on the ethernet ports (I disable their WiFi). > > But if (when) they support IPv6, establishing the WireGuard tunnel over IPv6 > would be great, and back to a 1420 MTU for WireGuard. A quick update, TMHI does support IPv6 via DHCPv6, but sadly has the same MTU (1420) as IPv4 has, and IPv6 is firewalled inbound (as Roman said). I now have the WireGuard transport endpoints using IPv6 over TMHI, but the jitter with low bitrate traffic still occurs as with the IPv4 transport endpoint setup. Other than that, it works quite well. Lonnie
Re: T-Mobile 4G/5G CGNAT vs WireGuard tunnel jitter
> On Apr 10, 2021, at 10:59 AM, Roman Mamedov wrote: > > On Sat, 10 Apr 2021 10:27:23 -0500 > Lonnie Abelbeck wrote: > >> I have been testing the T-Mobile Home Internet (4G/5G fixed wireless) >> service to a Linode VM via WireGuard. >> >> The TMHI service uses CGNAT plus an additional NAT in their modem/gateway >> with a MTU of 1420, so WireGuard is configured with a 1340 MTU. > > Do they provide IPv6? I see mentions that yes, but with incoming connections > blocked. Might still work for WG. Hi Roman, TMHI uses IPv6 for their CGNAT, but AFAIK their current firmware does not support IPv6 on the ethernet ports (I disable their WiFi). But if (when) they support IPv6, establishing the WireGuard tunnel over IPv6 would be great, and back to a 1420 MTU for WireGuard. Lonnie
Re: T-Mobile 4G/5G CGNAT vs WireGuard tunnel jitter
Hi Mo, I have the latest hardware (gray cylinder) -- Typically 3 of 5 bars 4G Band: B2 5G Band: n71 -- Note the huge jitter only occurs inbound, which is difficult to measure without using WireGuard. The same UDP iperf3 tests outbound (gw-lan->linode) range from 3 to 8 ms jitter, regardless of bitrate. -- Speed ( less than 2 seconds) 10/15 Mbps (down/up) slowly ramps up to ... Speed ( after 20 seconds) up to 200/35 Mbps (down/up) -- Lonnie > On Apr 10, 2021, at 10:43 AM, Mo Balaa wrote: > > Thanks for sharing, I have also been running WG tunnels over T-Mobile home > internet and haven’t seen any of the jitter you are reporting. > > Did you try the same tests (outbound) without running them via WG? > Which modem do you have? How many signal bars are you getting? Also, what > does an non-tunneled speed test report? > > Cheers > > >> On Apr 10, 2021, at 10:31, Lonnie Abelbeck wrote: >> >> Greetings, >> >> I have been testing the T-Mobile Home Internet (4G/5G fixed wireless) >> service to a Linode VM via WireGuard. >> >> The TMHI service uses CGNAT plus an additional NAT in their modem/gateway >> with a MTU of 1420, so WireGuard is configured with a 1340 MTU. >> >> Everything works, but I thought I would share some jitter results that >> readers here might find interesting. >> >> [gw-lan WGIP:10.4.1.1] -- [TMHI modem/gateway] -- 4G/5G/CGNAT -- [linode >> WGIP:10.4.1.10] >> >> gw-lan ~ # mtr -wn -c 30 -s 1340 10.4.1.10 >> ... >> HOST: gw-lan Loss% Snt Last Avg Best Wrst StDev >> 1.|-- 10.4.1.10 0.0%30 88.7 88.9 77.2 99.2 5.4 >> >> Looks to be as expected, in the direction of the CGNAT, now the other >> direction, against the grain of the CGNAT ... >> >> linode ~ # mtr -wn -c 30 -s 1340 10.4.1.1 >> ... >> HOST: linode Loss% Snt Last Avg Best Wrst StDev >> 1.|-- 10.4.1.1 0.0%30 206.1 243.5 73.8 393.9 97.9 >> >> Huge jitter, and is very reproducible. But no packet loss. >> >> Further investigation shows for low traffic rates (linode->gw-lan) the >> jitter over WireGuard is huge, here are some UDP iperf3 tests showing how >> the jitter goes down as the traffic rate is increased. >> >> linode ~ # iperf3 -c 10.4.1.1 -u -b 5k -t 30 >> ... >> [ ID] Interval Transfer Bitrate JitterLost/Total >> Datagrams >> [ 5] 0.00-30.25 sec 18.9 KBytes 5.11 Kbits/sec 68.428 ms 0/15 (0%) >> receiver >> >> linode ~ # iperf3 -c 10.4.1.1 -u -b 10k -t 30 >> ... >> [ ID] Interval Transfer Bitrate JitterLost/Total >> Datagrams >> [ 5] 0.00-30.30 sec 37.7 KBytes 10.2 Kbits/sec 82.411 ms 0/30 (0%) >> receiver >> >> linode ~ # iperf3 -c 10.4.1.1 -u -b 50k -t 30 >> ... >> [ ID] Interval Transfer Bitrate JitterLost/Total >> Datagrams >> [ 5] 0.00-30.14 sec 184 KBytes 49.9 Kbits/sec 7.532 ms 0/146 (0%) >> receiver >> >> linode ~ # iperf3 -c 10.4.1.1 -u -b 100k -t 30 >> ... >> [ ID] Interval Transfer Bitrate JitterLost/Total >> Datagrams >> [ 5] 0.00-30.10 sec 367 KBytes 100 Kbits/sec 4.182 ms 0/292 (0%) >> receiver >> >> linode ~ # iperf3 -c 10.4.1.1 -u -b 500k -t 30 >> ... >> [ ID] Interval Transfer Bitrate JitterLost/Total >> Datagrams >> [ 5] 0.00-30.11 sec 1.79 MBytes 498 Kbits/sec 1.308 ms 0/1456 (0%) >> receiver >> >> >> So using VoIP a higher bitrate CODEC is actually better w.r.t jitter. >> >> Hope others find this interesting. >> >> Lonnie >> > >
T-Mobile 4G/5G CGNAT vs WireGuard tunnel jitter
Greetings, I have been testing the T-Mobile Home Internet (4G/5G fixed wireless) service to a Linode VM via WireGuard. The TMHI service uses CGNAT plus an additional NAT in their modem/gateway with a MTU of 1420, so WireGuard is configured with a 1340 MTU. Everything works, but I thought I would share some jitter results that readers here might find interesting. [gw-lan WGIP:10.4.1.1] -- [TMHI modem/gateway] -- 4G/5G/CGNAT -- [linode WGIP:10.4.1.10] gw-lan ~ # mtr -wn -c 30 -s 1340 10.4.1.10 ... HOST: gw-lan Loss% Snt Last Avg Best Wrst StDev 1.|-- 10.4.1.10 0.0%30 88.7 88.9 77.2 99.2 5.4 Looks to be as expected, in the direction of the CGNAT, now the other direction, against the grain of the CGNAT ... linode ~ # mtr -wn -c 30 -s 1340 10.4.1.1 ... HOST: linode Loss% Snt Last Avg Best Wrst StDev 1.|-- 10.4.1.1 0.0%30 206.1 243.5 73.8 393.9 97.9 Huge jitter, and is very reproducible. But no packet loss. Further investigation shows for low traffic rates (linode->gw-lan) the jitter over WireGuard is huge, here are some UDP iperf3 tests showing how the jitter goes down as the traffic rate is increased. linode ~ # iperf3 -c 10.4.1.1 -u -b 5k -t 30 ... [ ID] Interval Transfer Bitrate JitterLost/Total Datagrams [ 5] 0.00-30.25 sec 18.9 KBytes 5.11 Kbits/sec 68.428 ms 0/15 (0%) receiver linode ~ # iperf3 -c 10.4.1.1 -u -b 10k -t 30 ... [ ID] Interval Transfer Bitrate JitterLost/Total Datagrams [ 5] 0.00-30.30 sec 37.7 KBytes 10.2 Kbits/sec 82.411 ms 0/30 (0%) receiver linode ~ # iperf3 -c 10.4.1.1 -u -b 50k -t 30 ... [ ID] Interval Transfer Bitrate JitterLost/Total Datagrams [ 5] 0.00-30.14 sec 184 KBytes 49.9 Kbits/sec 7.532 ms 0/146 (0%) receiver linode ~ # iperf3 -c 10.4.1.1 -u -b 100k -t 30 ... [ ID] Interval Transfer Bitrate JitterLost/Total Datagrams [ 5] 0.00-30.10 sec 367 KBytes 100 Kbits/sec 4.182 ms 0/292 (0%) receiver linode ~ # iperf3 -c 10.4.1.1 -u -b 500k -t 30 ... [ ID] Interval Transfer Bitrate JitterLost/Total Datagrams [ 5] 0.00-30.11 sec 1.79 MBytes 498 Kbits/sec 1.308 ms 0/1456 (0%) receiver So using VoIP a higher bitrate CODEC is actually better w.r.t jitter. Hope others find this interesting. Lonnie
Re: Enhance the "AllowedIPs"
> On Mar 15, 2021, at 2:57 AM, Feng Li wrote: > > As we know, the AllowedIPs will set the route table. However, if we > want to set the CIDR, but except for some CIDR range, it's not so easy > and out of the box. For example, if I want to route my all traffic, > except the 192.168.0.0/16. I have to calculate the two CIDR > difference: > > AllowedIPs = > 0.0.0.0/1 + 128.0.0.0/1 - 192.168.0.0/16 > = > 0.0.0.0/5,8.0.0.0/7,11.0.0.0/8,12.0.0.0/6,16.0.0.0/4,32.0.0.0/3,64.0.0.0/2,128.0.0.0/2,192.0.0.0/9,192.128.0.0/11,192.160.0.0/13,192.169.0.0/16,192.170.0.0/15,192.172.0.0/14,192.176.0.0/12,192.192.0.0/10,193.0.0.0/8,194.0.0.0/7,196.0.0.0/6,200.0.0.0/5,208.0.0.0/4,224.0.0.0/3,10.99.0.0/24 For giggles, I though this might be a clever solution: -- [Peer] PublicKey = Endpoint = remote-vpn:51820 AllowedIPs = 0.0.0.0/0, ::/0 [Peer] PublicKey = Endpoint = 127.0.0.1:51820 AllowedIPs = 192.168.0.0/16 -- I tested, but wg silently ignores peers to itself. Lonnie
Re: DNS resolution retries and EAI_NONAME
> On Nov 3, 2020, at 2:57 AM, Zack Elan wrote: > > Short version: if I set WG_ENDPOINT_RESOLUTION_RETRIES=infinity, I would like > wg(8) to actually retry infinitely, rather than exiting the first time it > gets what it assumes to be a permanent failure. > > Long version: > > When WG_ENDPOINT_RESOLUTION_RETRIES is set, wg will retry endpoint resolution > failures...but it special-cases 2 or 3 error response codes [0] - EAI_NONAME, > EAI_FAIL and (if defined) EAI_NODATA because it considers them "permanent" > failures that are not worth retrying. > > I have several Wireguard tunnels that are set to start at boot on a NixOS box > I host. NixOS sets this variable to infinite for me [1]. Despite this, when I > reboot that host, I consistently have the tunnels fail on startup. They're > failing with a error that wg(8) considers permanent: Hi Zack, Our project reversed the logic to make a DNS failure to be a non-fatal 'wg' error. [2] This trivial patch has worked well for our usage. Lonnie [2] https://raw.githubusercontent.com/astlinux-project/astlinux/master/package/wireguard-tools/wireguard-tools-0001-ignore-endpoint-dns-failure.patch
Re: Confused about AllowedIPs meaning?
> On Jul 26, 2020, at 5:57 AM, Gunnar Niels wrote: > > The simplicity of the wireguard config is one of the best features about it, > but the only thing I'm unclear about here is: exactly what is the "AllowedIPs" > field configuring? I'm not sure how to configure these fields for my use-case. Possibly this link will help you: Cryptokey Routing https://www.wireguard.com/#cryptokey-routing "At the heart of WireGuard is a concept called Cryptokey Routing, which works by associating public keys with a list of tunnel IP addresses that are allowed inside the tunnel. ..."
Re: remove peer endpoint
> On Dec 27, 2019, at 9:51 AM, Devin Smith wrote: > > Is it possible to remove the endpoint of a peer via the `wg set` command? All > of the other peer attributes (preshared-key, persistent-keepalive, > allowed-ips) are removable in this fashion (and documented in the man page). > I've tried `wg set peer endpoint 0` ... Yes, this works: -- wg set peer remove -- If you forget, "wg set --help" will remind you. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"
> On Dec 6, 2019, at 9:18 AM, Jason A. Donenfeld wrote: > > Hi Vasili, > > On Thu, Dec 5, 2019 at 10:28 PM Vasili Pupkin wrote: >> I've just figured out that the same effect can also be achieved with >> iptables: >> iptables -t filter -I INPUT -m addrtype --limit-iface-in ! --dst-type >> LOCAL -j DROP > > Neat trick, but it still requires this to run on all incoming packets > from all interfaces, right? In other words, it enables a strong host > model for the whole system instead of just with regards to addresses > "owned" by the WireGuard interface. Adding support for the latter > would get us back to the original rule we're using right now, right? For what its worth, if some sort of basic firewall with conntrack is enabled, Step 1 of the attack is blocked with a "ctstate INVALID" rule. Per testing in the lab, using attack "nping --tcp --flags SA ..." For Example, VALID_CHK in the (external facing) INPUT and FORWARD chains: -- -A VALID_CHK -m conntrack --ctstate INVALID -j DROP -- for both iptables and ip6tables filter tables. Is it common some sort of basic firewall with conntrack is not enabled ? Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: idle traffic considerations
> On Nov 29, 2019, at 3:18 PM, zrm wrote: > > On 10/17/19 06:29, Knuth wrote: >> Hey, >> we are planning to deploy certain devices with an embedded sim cards in >> different countries across the globe, for maintenance we need to be able to >> connect to the devices with ssh. >> Since the sim cards only provide us with a private IPv4 behind NAT (because >> apparently IPv6 is still hard...) we need to reverse the connection process >> to our control system, >> at the moment we consider doing this with wireguard (we are aware of the >> "pre" release status), since we had good experiences with it on other >> similar setups. >> To calculate some rough estimated costs for the mobile connection traffic >> volume, i'd love to know if there is a way to calculate the amount of >> traffic caused by an idle wireguard connection kept alive since we would be >> charged per MByte transferred. >> Or do we simply have to setup a few test subjects and monitor it over a >> longer time, which in itself could be error prone. >> Thanks for your time >> Knuth > > Ballpark estimate, round a keepalive packet to about a hundred bytes. You're > also going to get a re-keys, call those two hundred bytes. If you have a > keepalive every 30 seconds and a re-key every 120 seconds, that's around 18KB > per hour per peer in each direction. I had a similar use case as Knuth described, zrm's estimate is right on target. Using a Netgear LB1121 as a 4G/LTE Endpoint, native IPv4-only behind NAT to a static IPv4 public server. ## 4G/LTE Endpoint PersistentKeepalive = 25 ## Static Endpoint PersistentKeepalive = 0 When idle the WireGuard VPN consumes less than 0.5 MB/day of data. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH] Don't delete peers if not needed on `setconf`
> On Nov 27, 2019, at 4:22 AM, Jason A. Donenfeld wrote: > > Interesting implementation strategy. There's a pure-userspace version > of that too, here: > > https://git.zx2c4.com/WireGuard/commit/?h=jd/syncconf Our project has been using "syncconf" ever since Jason crafted it, works perfectly, solves the same issue as Grzegorz reported. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: wg-quick systemd service doesn't work after boot
> On Oct 6, 2019, at 11:54 AM, Adrián Mihálko wrote: > > I have 3 wg interface on my server, but I am unable to enable wg0 with > wg-quick at boot: > > @ubuntu:~$ sudo systemctl enable wg-quick@wg0 > @ubuntu:~$ > ... > Oct 06 13:22:53 ubuntu wg-quick[1737]: [#] iptables -A FORWARD -i wg0 -j > ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING > -o e > Oct 06 13:22:53 ubuntu wg-quick[1737]: Another app is currently holding the > xtables lock. Perhaps you want to use the -w option? Hi Adrián, As a test, how about adding -w to the iptables call: -- iptables -w -A FORWARD -i wg0 ... -- and see it that fixes it. With -w, iptables will wait until the lock is released. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: RFC: wg syncpeers wg0 wireguard.conf
> On Jun 14, 2019, at 1:09 PM, Jason A. Donenfeld wrote: > > I'm leaning toward Steven's suggestion of nixing addconf and making > setconf behave like syncconf. But wouldn't the current 'setconf' (overwrite existing) always be faster than a combo 'setconf/syncconf' (sync with existing) ? I have this nagging feeling that both 'setconf' and 'syncconf' should exist, if not for efficiencies but for unforeseen reasons related to the different functionalities: Start 'setconf' and Reload 'syncconf'. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: RFC: wg syncpeers wg0 wireguard.conf
> On Jun 11, 2019, at 12:28 PM, Jason A. Donenfeld wrote: > > I gave it a stab in this branch: > https://git.zx2c4.com/WireGuard/commit/?h=jd/syncconf Try it out and > let me know if it does what you had in mind? More testing, "syncconf" is working great. A real world example, connecting over WG to a remote instance, using a web interface for remote WG management: 1) "Restart WireGuard VPN" takes 35 seconds (using "setconf"), 17 seconds for the WG peer to reestablish and the rest of the time is most likely the TCP backoff timers for the HTTPS web interface session, totaling 35 seconds. 2) "Reload WireGuard VPN" takes << 1 second (using "syncconf"), no noticeable impact at all, even when editing the AllowedIPs of the peer tunnel used for access. Our project will be using Jason's elegant "syncconf" (above URL) as a patch, up until an official solution is committed. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: RFC: wg syncpeers wg0 wireguard.conf
> On Jun 11, 2019, at 12:28 PM, Jason A. Donenfeld wrote: > > I gave it a stab in this branch: > https://git.zx2c4.com/WireGuard/commit/?h=jd/syncconf Try it out and > let me know if it does what you had in mind? Hi Jason, This is *exactly* what I had in mind ! Impressive how little code it took you to add "syncconf", very elegant. I spent over an hour testing this, trying to break it ... worked perfectly. Active peers don't miss a beat and retain their counters. > One of the things that always goes wrong with "sync" algorithms in > software -- and the commit above at the moment is no exception -- is > that they're kind of racey. In order to synchronize, we have to read > the current state, compare it, and then set our new state. But in > between, the state could have changed out from underneath us. One > strategy for this is to just do nothing and put some notice in the man > page. Another strategy is to read back the result at the end, compare > it, and loop like this until we reach the stable state. This then > requires implementing some equality function. If "wg" does not offer "syncconf", users will be hacking together their own sync solution and it will no doubt be more racey than your tight code. Just a simple mention in the man page stating something like: Warning: unexpected results may occur with simultaneous background configuration changes during 'wg syncconf' Possibly also add a hint on the command help... "(assume no background configuration changes)" -- syncconf: Synchronizes a configuration file to a WireGuard interface (assume no background configuration changes) -- > The other thing I was wondering is: aside from performance and races > as described above, why not just make this the functionality of > `setconf`? Then there's be no need to introduce a new subcommand. In > otherwords, the idea would be to make `setconf` not destroy existing > peers if we're going to be re-adding them again. I vote to keep "setconf" as is, with the addition of the "syncconf" subcommand. This keeps "setconf" faster, and unchanged, typically used for initial configuration. Then "syncconf" would typically be used for followup live updates. Thanks again Jason! Please merge syncconf -> master Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
RFC: wg syncpeers wg0 wireguard.conf
Hi List, Request For Comments: I would find it useful if "wg" would support a "syncpeers" subcommand. -- Usage: wg syncpeers -- Available subcommands: syncpeers: Synchronizes a configuration file of peers to a WireGuard interface -- Given: - A user creates a wireguard.conf file. - Uses "wg setconf wg0 wireguard.conf" to apply the configuration. Request: - Later, a user edits a wireguard.conf file: adds peers, deletes peers, and/or edits peers. - Use "wg syncpeers wg0 wireguard.conf" to synchronize the configuration file of peers with the current state. - Synchronize changes with minimal impact, determine peer differences and leave unchanged settings alone. - Basically internally using "wg set wg0 ..." to make the minimum changes. - If the [Peer] Endpoint is a DNS hostname, the Endpoint will be resolved and IP updated. Note: Interestingly, "wg setconf wg0 wireguard.conf" *almost* performs as requested except for a 17 second interruption of the tunnel *if* PersistentKeepalive is 0. Even if PersistentKeepalive is 3600, a "wg setconf wg0 wireguard.conf" will not effect an active tunnel except for resetting traffic counters. I understand a script could be created to perform this as well, but adding it to "wg" lowers the hurdle for many users. If the 17 second interruption of active tunnels while using "wg setconf wg0 wireguard.conf" could be eliminated, this request may be moot. Comments please. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Wireguard Bug?
> On May 12, 2019, at 8:44 AM, Ryan Whelan wrote: > > I am building a system which coordinates the meshing of wireguard devices. > Currently, all the devices are running on an embedded platform (AMD Geode > LX500) and works as expected. However, when introducing a 64bit KVM host for > testing, all the 32bit hosts running on the Geode platform, report the > following warning and drop offline temporarily. The CPU usage on KVM host > spikes and all the CPU time is spent on the kernel threads servicing the WG > interfaces. > > I'm using kernel 4.19.41 and have seen the issue with both the last WG > snapshot as well building from master. Hi Ryan, Did you mean "AMD Geode LX800 @500 MHz" ? (ex. ALIX/net5501) If so, I have a couple of those using kernel 3.16.64 (i586) mixed with 3.16.64 (x86_64), and WG works well between them, no issues like you reported. iperf3 over WG runs at 23.8 Mbits/sec. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: WireGuard Digest, Vol 38, Issue 5
> On May 6, 2019, at 10:42 PM, Thomas Dickomeit > wrote: > > Hello Wireguard, > > Im using on myMacPro 2013 Wireguard since more then a half year, via > MacPorts, my WireguardServer is my Router with OpenWRT on it, made me a > Shellscript.sh that fires wireguard up or down so u can launch it without > opening the Terminal simply over my ShellScript.sh inder MacOS Finder …its > working wonderfull under OSX Sierra, > > Now my question, I just say, in the AppStore, that there is a Wirguard client > now AVAIABLE, Thanks for that!!! I Love Wireguard! > > sadly, the AppleStore doesnt allow me to dl it, as I am still under OSX > Sierra, is there a link I can dl it from another source then the AppleStore? Thomas, The macOS AppStore version of WireGuard uses calls only supported in macOS 10.14+ . Jason has stated his willingness to accept quality backports of those calls to support 10.13, 10.12, but I'm not aware of any activity on that front. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: iOS WG Battery Life
Kalin, As a single data point test, I borrowed my wife's iPod Touch -- iPod Touch (6th gen., A8 processor) iOS WireGuard v1.0.3 iOS 12.1.4 -- * Charged to 100% * Enable WiFi only (Bluetooth disabled, no LTE) and WireGuard enabled * No PersistentKeepalive enabled at either WG endpoint * Swiped-close all running apps * Let sit idle * After 6 hours, battery reads 99% charged Monitoring WG traffic at the "server" end, over 6 hours the delta traffic is: -- 0.26 MiB received, 0.30 MiB sent -- It appears iOS generates packets about every 20 minutes or so. Lonnie > On Mar 2, 2019, at 1:54 PM, kolargol wrote: > > >> Possibly, is PersistentKeepalive defined at the "server" endpoint for your >> iOS peer ? >> >> I would expect a measurable additional battery usage if either peer endpoint >> had PersistentKeepalive defined (non-zero). > > Both server and peer have PersistentKeepalive disabled, there is no fancy > apps runnign in backgroud - and i am using exac same WiFi and VPN endpoint > (for OpenVPN and WG comparision). > WiFI connection is stable and have strong signal, same with LTE. > The battery grap shows sharp down in the night as something continuesly > draing battery (here wg) > How can i debug it ? ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: iOS WG (1.0.3) - ARM64 SIMD ChaCha20
> On Feb 20, 2019, at 3:01 PM, Sebastian Gottschall > wrote: > > > Am 20.02.2019 um 16:03 schrieb Lonnie Abelbeck: >> Thanks to Jason and the team, a new iOS WG 1.0.3 appeared as an update: >> >> 1.0.3 / Feb 19, 2019 >> -- >> Performance should be higher and battery usage lower, thanks to a new ARM64 >> SIMD implementation of ChaCha20 >> -- >> For reference, the upstream golang crypto commit is here [1] with >> performance numbers. >> >> So, the question come to mind, do my iOS devices have ARM64 SIMD support, >> quick answer is if the device is less than 6 years old it should have ARM64 >> SIMD support. Added in the A5/A6 CPU's from what I can tell. > > A5 and A6 is 32 bit. A7 was the first 64 bit cpu (introduced with Iphone 5s) > > Sebastian Thanks Sebastian for the info, It appears if the device can run iOS 12 (required by iOS WG) then it also has ARM64 SIMD support. Lonnie >> Apple-designed processors >> https://en.wikipedia.org/wiki/Apple-designed_processors >> >> [1] chacha20: add SIMD implementation on arm64 >> https://go.googlesource.com/crypto/+/74369b46fc6756741c016591724fd1cb8e26845f ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
iOS WG (1.0.3) - ARM64 SIMD ChaCha20
Thanks to Jason and the team, a new iOS WG 1.0.3 appeared as an update: 1.0.3 / Feb 19, 2019 -- Performance should be higher and battery usage lower, thanks to a new ARM64 SIMD implementation of ChaCha20 -- For reference, the upstream golang crypto commit is here [1] with performance numbers. So, the question come to mind, do my iOS devices have ARM64 SIMD support, quick answer is if the device is less than 6 years old it should have ARM64 SIMD support. Added in the A5/A6 CPU's from what I can tell. Apple-designed processors https://en.wikipedia.org/wiki/Apple-designed_processors Please correct my research if I over-simplified where the new ARM64 SIMD implementation of ChaCha20 is available for iOS WireGuard. Lonnie [1] chacha20: add SIMD implementation on arm64 https://go.googlesource.com/crypto/+/74369b46fc6756741c016591724fd1cb8e26845f ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: DNS name resolution should not be done during configuration parsing.
> On Feb 19, 2019, at 1:22 AM, Matthias Urlichs wrote: > > We don't even need call-outs. We already have a netlink interface which > a userspace client can use to monitor WG. Teach that client to > re-resolve the name and to update the peer. > -- > -- Matthias Urlichs Agreed. For example Jason's "reresolve-dns.sh" script. [1] The missing piece is to keep "wg setconf" (et al.) from failing given a DNS failure on any peer. Per this trivial patch. https://raw.githubusercontent.com/astlinux-project/astlinux/master/package/wireguard/wireguard-0001-ignore-endpoint-dns-failure.patch Peers without DNS endpoints (or successful DNS) would be allowed to start promptly as expected, and any failed DNS endpoints would be filled in later via a userspace WG monitor (ex. reresolve-dns.sh). Lonnie [1] https://git.zx2c4.com/WireGuard/tree/contrib/examples/reresolve-dns ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: dynamic reload of configuration file
Raffaele, typing "wg help" should answer many of your questions: -- # wg help Usage: wg [] Available subcommands: show: Shows the current configuration and device information showconf: Shows the current configuration of a given WireGuard interface, for use with `setconf' set: Change the current configuration, add peers, remove peers, or change peers setconf: Applies a configuration file to a WireGuard interface addconf: Appends a configuration file to a WireGuard interface genkey: Generates a new private key and writes it to stdout genpsk: Generates a new preshared key and writes it to stdout pubkey: Reads a private key from stdin and writes a public key to stdout You may pass `--help' to any of these subcommands to view usage. -- -- # wg set --help Usage: wg set [listen-port ] [fwmark ] [private-key ] [peer [remove] [preshared-key ] [endpoint :] [persistent-keepalive ] [allowed-ips /[,/]...] ]... -- Lonnie > On Feb 18, 2019, at 7:51 AM, Raffaele Spazzoli wrote: > > Samuel, > > I read that section of the docs. it doesn't explain the behavior of those > commands on an already "warm" wireguard device (i.e. while the device is in > up state). > > M. Dietrich, > > the add conf may work when adding a node, but I also need something when > removing a node of the mesh. > > two questions: > 1. If initialize a wireguard device with a configuration file and then update > the file will the configuration be updated? > 2. if I run the set-conf command on an already initialized wiredguard device, > will the configuration be updated without losing the current (and still > existing after the new configuration) connections? > > Thanks, > Raffaele > > Raffaele Spazzoli > Senior Architect - OpenShift, Containers and PaaS Practice > Tel: +1 216-258-7717 > > > > > On Sun, Feb 17, 2019 at 12:38 PM M. Dietrich wrote: > Quotation from Raffaele Spazzoli at Februar 17, 2019 16:21: > > I'm using wireguard to build a VPN mesh. The nodes of the mesh are dynamic > > and can come and go at any time. Is there a way to reconfigure a wireguard > > device without restarting it or losing the current connections? > > yes. > > > If yes, how can it be done? > > other way around: configure wireguard with the `wg` command > and that is persisted to the configuration file. > > on restart the file is read and your config applied. > > M. Dietrich > ___ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
wg setconf: ignore Endpoint= DNS failure
Hi Jason and list,
I would like to discuss changing WG's current handling of an Endpoint= DNS
failure with "wg setconf ...".
Currently)
"Configuration parsing error", the configuration is aborted, keeping WG from
starting.
Proposed)
Ignore the DNS error, do not change the "endpoint", and continue parsing the
configuration so WG can be started.
The current stderr DNS error message will continue to be generated.
Optionally, some users may want to call "reresolve-dns.sh" [1] or similar at a
later time(s) to update the DNS derived "endpoint".
I have tested this trivial patch to accomplish the proposed change:
Note: The config.c parse_endpoint() function provides additional sanity
checking, only the DNS failure would allow parsing to continue.
--- wireguard-0.0.20190123/src/tools/config.c.orig 2019-01-30
09:02:53.685777217 -0600
+++ wireguard-0.0.20190123/src/tools/config.c 2019-01-30 09:03:44.253387871
-0600
@@ -241,7 +241,7 @@
timeout >= 9000) {
free(mutable);
fprintf(stderr, "%s: `%s'\n", ret == EAI_SYSTEM ?
strerror(errno) : gai_strerror(ret), value);
- return false;
+ return true;
}
fprintf(stderr, "%s: `%s'. Trying again in %.2f seconds...\n",
ret == EAI_SYSTEM ? strerror(errno) : gai_strerror(ret), value, timeout /
100.0);
usleep(timeout);
This change effects:
--
wg setconf ...
wg addconf ...
wg set ... endpoint : ...
--
I propose this will make WireGuard configuration more robust, minimizing the
effect of an Endpoint= DNS failure.
Lonnie
[1]
https://git.zx2c4.com/WireGuard/tree/contrib/examples/reresolve-dns/reresolve-dns.sh
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: wg-quick: Read private key from file?
> On Dec 27, 2018, at 10:51 AM, Rene 'Renne' Bartsch, B.Sc. Informatics > wrote: > > Hi, > > does wg-quick allow to read the private key from a file instead of a > .conf-file? > > Regards, > > Renne You could create a wg-quick-wrapper script that aggregates files from where-ever you like before it calls wg-quick and then cleans-up tmp files. Or just re-write wg-quick to suit your needs. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: sysctl of Alpine standard 3.8.1 doesn't support option -r.
> On Dec 3, 2018, at 1:28 AM, Du Felix wrote: > > I use alpine standard 3.8.1, which has kernel 4.14.82-0-vanilla. > When I start wireguard as client peer with wg-quick up client, It says: > > [#] ip link add client type wireguard > [#] wg setconf client /dev/fd/63 > [#] ip address add 10.0.0.4/24 dev client > [#] ip link set mtu 1420 dev client > [#] ip link set client up > [#] resolvconf -a client -m 0 -x > [#] wg set client fwmark 51820 > [#] ip -4 route add 0.0.0.0/0 dev client table 51820 > [#] ip -4 rule add not fwmark 51820 table 51820 > [#] ip -4 rule add table main suppress_prefixlength 0 > sysctl: unrecognized option: r > BusyBox v1.29.3 (2018-11-21 11:45:56 UTC) multi-call binary. > > Usage: sysctl -p [-enq] [FILE...] / [-enqaw] [KEY[=VALUE]]... > > Show/set kernel parameters > > -pSet values from FILEs (default /etc/sysctl.conf) > -eDon't warn about unknown keys > -nDon't show key names > -q Quiet > -aShow all values > -wSet values In your "wg-quick" script, try changing the line: -- from -- done < <(sysctl -a -r '^net\.ipv4.conf\.[^ .=]+\.rp_filter$') -- to -- done < <(sysctl -a 2>/dev/null | sed -n -r 's#^(net\.ipv4.conf\.[^ .=]+\.rp_filter).*$#\1#p') -- Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Seeking suggestions for a WG port to use with restrictive public wifi networks
> On Nov 19, 2018, at 2:33 PM, John wrote: > > Should I stick with the "standard" udp service ports for my > trial-and-error based approach? Wikipedia has an article that lists > many of these (List_of_TCP_and_UDP_port_numbers). Any suggestions are > welcomed. Possibly: UDP/500 (IPSec IKE) or UDP/4500 (IPSec NAT-T) Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: receive: use gro call instead of plain call
> On Jul 13, 2018, at 1:27 PM, Jason A. Donenfeld wrote: > > Hey Lonnie, > > Wow, thanks for benching that (and watching the git repo for the > experiment-of-the-day). This performance increase certainly exceeds my > expectations; I'm quite pleased it's working so well. Another huge improvement ... pbx3: Intel(R) Celeron(R) CPU N2930 @ 1.83GHz Ethernet controller: Intel Corporation I211 pbx: Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz Ethernet controller: Intel Corporation I211 pbx ~ # iperf3 -s pbx3 ~ # iperf3 -c 10.4.0.10 -P2 -R -- 0.0.20180625 -- [SUM] 0.00-10.03 sec 940 MBytes 786 Mbits/sec 251 sender [SUM] 0.00-10.00 sec 933 MBytes 782 Mbits/sec receiver -- 0.0.20180708 -- [SUM] 0.00-10.05 sec 730 MBytes 609 Mbits/sec 186 sender [SUM] 0.00-10.01 sec 726 MBytes 608 Mbits/sec receiver -- 0.0.20180708 w/napi_gro_receive patch -- [SUM] 0.00-10.04 sec 973 MBytes 813 Mbits/sec 289 sender [SUM] 0.00-10.00 sec 969 MBytes 813 Mbits/sec receiver -- Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: receive: use gro call instead of plain call
> On Jul 13, 2018, at 11:15 AM, Roman Mamedov wrote: > > On Fri, 13 Jul 2018 08:49:45 -0500 > Lonnie Abelbeck wrote: > >> For certain lower-end x86 boxes I test, I noticed WG 0.0.20180708 w/NAPI >> actually slowed down receive performance. >> >> Jason recently added "receive: use gro call instead of plain call" [1] >> commit, which made a big performance improvement. > > Yes I'm also seeing about 20% higher performance with this patch (from 1.3-1.4 > to 1.6 Gbit on same-host VMs). This is awesome! Hi Roman, thanks for the followup ... > ...and... if I switch TCP Congestion Control from bbr to illinois on sender, I > now get 2.0 Gbit. WTF. :) > Lonnie, which one do you use on your hosts? We are using Linux 3.16.57 and CONFIG_TCP_CONG_ADVANCED=n, so standard stuff ... pbx ~ # sysctl net.ipv4.tcp_available_congestion_control net.ipv4.tcp_available_congestion_control = cubic reno pbx ~ # sysctl net.ipv4.tcp_congestion_control net.ipv4.tcp_congestion_control = cubic Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
receive: use gro call instead of plain call
For certain lower-end x86 boxes I test, I noticed WG 0.0.20180708 w/NAPI actually slowed down receive performance. Jason recently added "receive: use gro call instead of plain call" [1] commit, which made a big performance improvement. Here is a test on a PC Engines APU2 ... pbx4: AMD GX-412TC SOC (1 GHz, 4-core) Ethernet controller: Intel Corporation I210 pbx: Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz Ethernet controller: Intel Corporation I211 # uname -a Linux pbx4 3.16.57-astlinux #1 SMP PREEMPT Mon Jul 9 17:25:31 CDT 2018 x86_64 GNU/Linux pbx ~ # iperf3 -s pbx4 ~ # iperf3 -c 10.4.0.10 -P2 -R -- 0.0.20180625 -- [SUM] 0.00-10.04 sec 466 MBytes 390 Mbits/sec 162 sender [SUM] 0.00-10.00 sec 463 MBytes 389 Mbits/sec receiver -- 0.0.20180708 -- [SUM] 0.00-10.04 sec 301 MBytes 252 Mbits/sec 30 sender [SUM] 0.00-10.00 sec 300 MBytes 251 Mbits/sec receiver -- 0.0.20180708 w/napi_gro_receive patch -- [SUM] 0.00-10.04 sec 596 MBytes 498 Mbits/sec 92 sender [SUM] 0.00-10.00 sec 594 MBytes 498 Mbits/sec receiver -- Kudos Jason ! Lonnie [1] https://git.zx2c4.com/WireGuard/commit/?id=95951af7249912a4356b9a03cf3addc7e3f8f724 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: PostUp/PreUp/PostDown/PreDown Dangerous?
> On Jun 21, 2018, at 8:41 PM, Jason A. Donenfeld wrote: > > Hey list, > > wg(8) is the main WireGuard configuration tool. It takes a fairly > strict set of inputs, and is supposed to perform acceptable input > validation on them. > > https://git.zx2c4.com/WireGuard/about/src/tools/man/wg.8 > > wg-quick(8), on the other and, is a dinky bash script, that is useful > for making some common limited use cases a bit easier. > > https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8 > > wg-quick(8) has the very handy feature of allowing > PostUp/PostDown/PreUp/PreDown directives, to execute some helpers, > such as iptables or whatever else you want in a custom setup. These > have proven very useful to folks. And because these allow arbitrary > execution anyway, wg-quick(8) doesn't try very hard to do proper input > validation either. > > I just saw this nice post pointing out a problem in OpenVPN: > https://medium.com/tenable-techblog/reverse-shell-from-an-openvpn-configuration-file-73fd8b1d38da > > The same thing applies to wg-quick(8) with > PostUp/PostDown/PreUp/PreDown. How about not supporting direct execution of commands in the config [Interface] section but rather support an optional path to where a fixed command (ex. wireguard.script) is found... -- ActionScriptDir = /usr/local/bin -- Then instead of executing the PostUp/PostDown/PreUp/PreDown data, the wg-quick script would call: -- /usr/local/bin/wireguard.script PRE_UP|PRE_DOWN|POST_UP|POST_DOWN "$INTERFACE" -- 1) When called, the first argument would be one of: PRE_UP|PRE_DOWN|POST_UP|POST_DOWN 2) When called, the second argument would be the wireguard interface. 3) If ActionScriptDir is not defined, then wireguard.script is not called. This requires an extra step to be taken to create a wireguard.script file with execute permissions and possibly require specific ownership. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [ANNOUNCE] WireGuard Snapshot `0.0.20180620` Available
> On Jun 20, 2018, at 7:22 PM, Lonnie Abelbeck > wrote: > > >> On Jun 20, 2018, at 6:47 PM, Jason A. Donenfeld wrote: >> >> Hey Lonnie, >> >> Thanks for helping to debug this. >> >> On Thu, Jun 21, 2018 at 12:37 AM Lonnie Abelbeck >> wrote: >>> Hunk #1 only does the trick, though performance is ever so slightly slower >>> than before overall. >> >> It's good to hear that hunks #2 and #3 don't have much an effect, >> though it does still seem to have _some_ effect. >> >> Looks like hunk 1 is rather worrisome though. Can you try out >> https://א.cc/eaxxpxbB and let me know if it has any effect? > > That patch, as is, is very bad > -- > [SUM] 0.00-30.00 sec 1.26 GBytes 360 Mbits/sec 98 sender > [SUM] 0.00-30.03 sec 1.25 GBytes 358 Mbits/sec receiver > > I then edited the patch to add back in local_bh_disable() / > local_bh_enable(), much better > -- > [SUM] 0.00-30.00 sec 2.62 GBytes 751 Mbits/sec 1389 sender > [SUM] 0.00-30.00 sec 2.61 GBytes 748 Mbits/sec receiver > > essentially back to 0.0.20180531 performance, hunk #1 from previous patch and > hunk #1 from the latest patch. Hey Jason, I'm not sure if this helps, but the 0.0.20180620 performance loss is most noticeable on the box performing "iperf3 -s". Also, here are a couple .png CPU utilizations of the "iperf3 -s" box via htop during the iperf3 test ... Test: 0.0.20180620 Test: 0.0.20180620 + hunk #1 from previous patch and hunk #1 from the latest patch Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [ANNOUNCE] WireGuard Snapshot `0.0.20180620` Available
> On Jun 20, 2018, at 6:47 PM, Jason A. Donenfeld wrote: > > Hey Lonnie, > > Thanks for helping to debug this. > > On Thu, Jun 21, 2018 at 12:37 AM Lonnie Abelbeck > wrote: >> Hunk #1 only does the trick, though performance is ever so slightly slower >> than before overall. > > It's good to hear that hunks #2 and #3 don't have much an effect, > though it does still seem to have _some_ effect. > > Looks like hunk 1 is rather worrisome though. Can you try out > https://א.cc/eaxxpxbB and let me know if it has any effect? That patch, as is, is very bad -- [SUM] 0.00-30.00 sec 1.26 GBytes 360 Mbits/sec 98 sender [SUM] 0.00-30.03 sec 1.25 GBytes 358 Mbits/sec receiver I then edited the patch to add back in local_bh_disable() / local_bh_enable(), much better -- [SUM] 0.00-30.00 sec 2.62 GBytes 751 Mbits/sec 1389 sender [SUM] 0.00-30.00 sec 2.61 GBytes 748 Mbits/sec receiver essentially back to 0.0.20180531 performance, hunk #1 from previous patch and hunk #1 from the latest patch. > Are you sure > the benchmark conditions were the same in other respects? Yes, quite sure, but there is some variation of the iperf3 results on each run ... I perform a few runs and then pick a median sample. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [ANNOUNCE] WireGuard Snapshot `0.0.20180620` Available
> On Jun 20, 2018, at 4:24 PM, Jason A. Donenfeld wrote: > > Hey Lonnie, > > Thanks for letting me know. Can you tell me if this patch -- > https://א.cc/GJpT3gVY -- brings the performance back up? And if that > works, can you then try each of those three fragments separate to see > which one has an actual effect (or perhaps all do). > > Jason Hunk #1 only does the trick, though performance is ever so slightly slower than before overall. Is this issue because our project uses CONFIG_PREEMPT=y ? Data below. Lonnie -- 0.0.20180531 reference -- [SUM] 0.00-30.00 sec 2.65 GBytes 758 Mbits/sec 571 sender [SUM] 0.00-30.02 sec 2.64 GBytes 756 Mbits/sec receiver -- full patch -- hunk #1, #2 and #3 [SUM] 0.00-30.00 sec 2.53 GBytes 724 Mbits/sec 921 sender [SUM] 0.00-30.01 sec 2.52 GBytes 722 Mbits/sec receiver -- hunk #1 only -- [SUM] 0.00-30.00 sec 2.57 GBytes 735 Mbits/sec 807 sender [SUM] 0.00-30.01 sec 2.56 GBytes 733 Mbits/sec receiver -- hunk #2 only -- [SUM] 0.00-30.00 sec 1.52 GBytes 434 Mbits/sec 91 sender [SUM] 0.00-30.02 sec 1.51 GBytes 433 Mbits/sec receiver -- hunk #3 only -- [SUM] 0.00-30.00 sec 1.51 GBytes 432 Mbits/sec 330 sender [SUM] 0.00-30.03 sec 1.50 GBytes 430 Mbits/sec receiver ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [ANNOUNCE] WireGuard Snapshot `0.0.20180620` Available
> On Jun 20, 2018, at 2:19 PM, Jason A. Donenfeld wrote: > > A new snapshot, `0.0.20180620`, has been tagged in the git repository. I find 0.0.20180620 much slower than previous version 0.0.20180531 All things being equal, only WireGuard version changes. Both boxes: # uname -a Linux pbx 3.16.54-astlinux #1 SMP PREEMPT Mon Jun 11 09:17:57 CDT 2018 x86_64 GNU/Linux Test: 0.0.20180531 -- Qotom Q190G4N-S07 NIC x4 # iperf3 -s Jetway NF9HG-2930 NIC x4 # iperf3 -c 10.4.0.10 -t30 -P2 [SUM] 0.00-30.00 sec 2.65 GBytes 758 Mbits/sec 571 sender [SUM] 0.00-30.02 sec 2.64 GBytes 756 Mbits/sec receiver -- Test: 0.0.20180620 -- Qotom Q190G4N-S07 NIC x4 # iperf3 -s Jetway NF9HG-2930 NIC x4 # iperf3 -c 10.4.0.10 -t30 -P2 [SUM] 0.00-30.00 sec 1.50 GBytes 430 Mbits/sec 96 sender [SUM] 0.00-30.02 sec 1.50 GBytes 428 Mbits/sec receiver -- Interesting note, using -P1 the difference is not as pronounced, but still slower. Any ideas ? Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
WireGuard within a WireGuard VPN
Hi, I have successfully implemented a WAN failover using a Netgear LB1121 4G/LTE Modem over a WireGuard tunnel to a VM instance (static IPv4) in the cloud. Since most 4G/LTE providers only support outbound-only (NAT'ed), IPv4-only, dynamic IPv4 address networks, by using WireGuard to a static IPv4 endpoint a bidirectional dual-stack IPv4/IPv6 network is created. Works very well. Question ... When failover occurs a 0.0.0.0/1 + 128.0.0.0/1 route is added to the wg0 interface via the cloud VM WireGuard address. There is a secondary WireGuard peer (dynamic remote endpoint) other than the failover 4G/LTE peer, which on failover tries to re-establish over the WireGuard failover peer, which fails. Possible solutions: 1) On failover add a route for the secondary endpoint (extracted using 'wg') and route to the ethernet interface the 4G/LTE Modem is connected. Fingers crossed the dynamic remote endpoint does not change during the failover. 2) Possibly reduce the MTU of the secondary WireGuard peer to allow it to work within the WireGuard failover peer. If so, what MTU would be required for WG to tunnel within another WG ? Possibly would require separate wg0 and wg1 interfaces for matching MTU's ? Appreciate any comments. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH 1/1] wg(8): rephrase wording on AllowedIPs
On Feb 18, 2018, at 6:02 AM, Daniel Lublin wrote: > +AllowedIPs \(em a comma-separated list of IP (v4 or v6) addresses with CIDR > +masks, declaring the sources of incoming traffic that are allowed through the > +peer, and as well defining which destinations of outgoing traffic that will > be > +directed through the peer. The catch-all \fI0.0.0.0/0\fP may be specified for > +matching all IPv4 addresses, and \fI::/0\fP may be specified for matching all > +IPv6 addresses. May be specified multiple times. Required. Personally, in an effort to make this more clear, from this reference: Cryptokey Routing https://www.wireguard.com/#cryptokey-routing This quote offered clarity to me ... -- When sending packets, the list of allowed IPs behaves as a sort of routing table, and when receiving packets, the list of allowed IPs behaves as a sort of access control list. -- Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Embedded x86 Benchmarks v0.0.20180202
Greetings, I have a collection of lower-end (embedded) x86 boxes that I use for testing with our AstLinux project. I previously posted WireGuard performance results for v0.0.20171211 ... Embedded x86 Benchmarks https://lists.zx2c4.com/pipermail/wireguard/2017-December/002204.html Results for v0.0.20180202 are below. Executive summary, v0.0.20180202 ranges from 0.7% slower to 2.9% faster than v0.0.20171211. If nothing else, a good sanity check. Lonnie = All WireGuard endpoints: Linux 3.16.51 WireGuard 0.0.20180202 Common "Server" endpoint: VMware VM x86_64, 2-core, 3.7 GHz Xeon E5-1620 -- vmware-vm ~ # iperf3 -s -- "Client" endpoints: Qotom Q190G4N-S07 x86_64, 4-core, 2.0 GHz Celeron J1900 -- [ 4] 0.00-30.00 sec 3.03 GBytes 867 Mbits/sec 14 sender [ 4] 0.00-30.00 sec 3.03 GBytes 867 Mbits/sec receiver -- 0.7% slower than v0.0.20171211 Jetway NF9HG-2930 x86_64, 4-core, 1.8 GHz Celeron N2930 -- [ 4] 0.00-30.00 sec 3.03 GBytes 867 Mbits/sec 11 sender [ 4] 0.00-30.00 sec 3.03 GBytes 866 Mbits/sec receiver -- 0.7% slower than v0.0.20171211 Lanner FW-7541D x86_64, 2-core,4-thread, 1.8 GHz Atom D525 -- [ 4] 0.00-30.00 sec 2.33 GBytes 668 Mbits/sec0 sender [ 4] 0.00-30.00 sec 2.33 GBytes 667 Mbits/sec receiver -- 0.1% slower than v0.0.20171211 PC Engines APU2 x86_64, 4-core, 1.0 GHz AMD GX-412TC -- [ 4] 0.00-30.00 sec 1.84 GBytes 526 Mbits/sec0 sender [ 4] 0.00-30.00 sec 1.83 GBytes 525 Mbits/sec receiver -- 2.9% faster than v0.0.20171211 Lanner LEC-7220-N4 i686, 2-core,4-thread, 1.9 GHz Atom N2800 -- [ 4] 0.00-30.00 sec 1.15 GBytes 328 Mbits/sec0 sender [ 4] 0.00-30.00 sec 1.14 GBytes 327 Mbits/sec receiver -- 0.9% faster than v0.0.20171211 Soekris net5501 i586, 1-core, 0.5 GHz AMD Geode LX -- [ 4] 0.00-30.00 sec 76.9 MBytes 21.5 Mbits/sec0 sender [ 4] 0.00-30.00 sec 76.8 MBytes 21.5 Mbits/sec receiver -- 0.5% faster than v0.0.20171211 = ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
FLOSS WEEKLY - Episode 468: WireGuard
FYI, Jason gave another fine WireGuard talk ... Jan 24th 2018 FLOSS WEEKLY - Episode 468: WireGuard https://twit.tv/shows/floss-weekly/episodes/468 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Embedded x86 Benchmarks
Greetings, I have a collection of lower-end (embedded) x86 boxes that I use for testing with our AstLinux project. I ran iperf3 tests of WireGuard performance with a common "fast" VMware VM WireGuard endpoint. Interestingly the J1900 and N2930 can saturate the 1 Gb interface with 1 to 1.5 CPU cores still available. The similar OpenVPN performance maxes out at only 100 to 130 Mbps of tunneled traffic. Also note that the Lanner Atom N2800 system is 32-bit (i686), so even with 'ssse3' it appears there is no optimization, and the performance reflects that. Hopefully others find this interesting. Lonnie = All WireGuard endpoints: Linux 3.16.51 WireGuard 0.0.20171211 Common "Server" endpoint: VMware VM x86_64, 2-core, 3.7 GHz Xeon E5-1620 -- vmware-vm ~ # iperf3 -s -- "Client" endpoints: Qotom Q190G4N-S07 x86_64, 4-core, 2.0 GHz Celeron J1900 -- [ 4] 0.00-30.00 sec 3.05 GBytes 874 Mbits/sec 14 sender [ 4] 0.00-30.00 sec 3.05 GBytes 873 Mbits/sec receiver -- Jetway NF9HG-2930 x86_64, 4-core, 1.8 GHz Celeron N2930 -- [ 4] 0.00-30.00 sec 3.05 GBytes 873 Mbits/sec 10 sender [ 4] 0.00-30.00 sec 3.05 GBytes 872 Mbits/sec receiver -- Lanner FW-7541D x86_64, 2-core,4-thread, 1.8 GHz Atom D525 -- [ 4] 0.00-30.00 sec 2.34 GBytes 669 Mbits/sec0 sender [ 4] 0.00-30.00 sec 2.33 GBytes 668 Mbits/sec receiver -- PC Engines APU2 x86_64, 4-core, 1.0 GHz AMD GX-412TC -- [ 4] 0.00-30.00 sec 1.78 GBytes 510 Mbits/sec0 sender [ 4] 0.00-30.00 sec 1.78 GBytes 510 Mbits/sec receiver -- Lanner LEC-7220-N4 i686, 2-core,4-thread, 1.9 GHz Atom N2800 -- [ 4] 0.00-30.00 sec 1.14 GBytes 325 Mbits/sec0 sender [ 4] 0.00-30.00 sec 1.13 GBytes 324 Mbits/sec receiver -- Soekris net5501 i586, 1-core, 0.5 GHz AMD Geode LX -- [ 4] 0.00-30.00 sec 76.6 MBytes 21.4 Mbits/sec0 sender [ 4] 0.00-30.00 sec 76.5 MBytes 21.4 Mbits/sec receiver -- = ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [patch] add support for peer names using a file in userspace
On Dec 8, 2017, at 12:45 PM, Jason A. Donenfeld wrote: > >> 3) Make "wg show" display either "peer: orQ..." or "peer-some_custom_name: >> orQ..." >> >> 4) Any spaces in the "some_custom_name" text are ignored and truncated to 64 >> characters. > > Yikes. I'm inclined to make Description or the like follow whatever > other plaintext rules the netfilter comment stuff has, not something > restrictive like "no spaces". I suggested "no spaces" since currently all spaces are stripped in config_read_line() https://git.zx2c4.com/WireGuard/tree/src/tools/config.c#n434 Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [patch] add support for peer names using a file in userspace
On Dec 7, 2017, at 10:23 PM, Jason A. Donenfeld wrote: > Thanks for sending this to the mailing list. Indeed it got lost in the > fold of disorganized email filters when you sent it to me directly > twice earlier; sorry about that. The latest patch is reworked, disabled by default and requires WITH_PEERDATA=yes to be enabled. > I'm not certain this is the right approach -- having wg(8) rely on > fixed filesystem paths, and splitting peer configuration information > across three places (original config file, peer data file, kernel). I'm just trying to find a solution with traction. My latest patch works perfectly fine on our Linux appliance, but alternate approaches could be a more general solution. > I think the way forward for this kind of feature would be what I > proposed in an earlier thread, of attaching it to the kernel object, > just like ifalias does or netfilter's comment target. However, the > question I'm still faced with is -- is this really necessary? Yes, Jason, I think it is necessary. Consider a GUI showing a list of peers that you can click on to edit, there needs some sort of human-memerable "name" associated with each peer. Additionally, the "wg show" output is sorted by "handshake time" (a good thing), so remembering your peer config order does not help identifying the peers. While I would be happy with a compile-time option to support peer-names via a userspace file (per my patch), a kernel object would be better. Suggested configuration syntax: 1) Support either [Peer] or [Peer-some_custom_name] in "wg setconf" configurations. 2) Make "wg showconf" parrot back any [Peer-some_custom_name] context names. 3) Make "wg show" display either "peer: orQ..." or "peer-some_custom_name: orQ..." 4) Any spaces in the "some_custom_name" text are ignored and truncated to 64 characters. Thanks for your consideration. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
[patch] wg: add support for peer names using a file in userspace
Enclosed is a patch: wg: add support for peer names using a file in userspace Disabled by default, build with WITH_PEERDATA=yes to enable peer name support. Config [Peer] sections can optionally be [Peer-custom_name] with "show" and "showconf" displaying the "peer-custom_name" label. Spaces are ignored. The data file location is PEERDATAFILE, which defaults to /var/run/wg.peerdata Comments are appreciated. Lonnie 0001-wg-add-support-for-peer-names.patch Description: Binary data ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Standardized IPv6 ULA from PublicKey
Hi, Has anyone thought about a standardized WireGuard IPv6 ULA generated from the PublicKey ? WireGuard Unique Identifier (WUI) allowing a host to assign iteslf a unique 64-Bit IPv6 interface identifier (WUI-64) ? Possibly picking off bits of a hash of the PublicKey ? For mass deployments, could this be a useful standard ? Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Dynamic Adresses
On Nov 29, 2017, at 7:44 AM, Georg Faerber wrote: > On 17-11-29 14:40:25, Jason A. Donenfeld wrote: >> On Wed, Nov 29, 2017 at 2:35 PM, Mytril wrote: >>> Yes i have written a similar script for the german ubuntuusers.de wiki. >> >> Care to share? > In this season of sharing :-) last week I took Jason's reresolve-dns script as a reference and created a persistent background script "wireguard-monitor" that is started/stopped along side wireguard in our AstLinux project. wireguard-monitor https://github.com/astlinux-project/astlinux/blob/master/package/wireguard/wireguard-monitor Currently wireguard-monitor only updates DNS endpoints when WIREGUARD_DNS_UPDATE="yes" in the sourced /etc/rc.conf file. wireguard-monitor can be stopped by deleting the PIDFILE. One minor improvement over Jason's example is only DNS endpoints are updated, I test for manual IPv4/IPv6 addresses. I also wrote it hoping someday [Peer-peername] will be a valid config syntax. Note, there are several things specific to our project, such as we create /var/lock/wireguard.lock when wireguard is active, and we include /usr/lib/bash/sleep as a bash builtin, but there might be a few ideas to take away. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: roaming and ddns dynamic ip
On Nov 22, 2017, at 6:51 AM, d tbsky wrote: > 2017-11-22 19:59 GMT+08:00 Jason A. Donenfeld : >> Hello, >> >> This is not a bug. DNS resolution is not done by the WireGuard module, >> but rather by the configuration tool. If you want to update an IP, >> you'll need to devise a mechanism for this. One popular one is this >> example script: >> https://git.zx2c4.com/WireGuard/tree/contrib/examples/reresolve-dns , >> but many other possibilities exist too. >> >> Jason > > I don't think it's a bug. as you said, that's by design.although it > means I need other tool to co-maintain the vpn connection. Jason, question, if each endpoint had PersistentKeepalive enabled, does that update the endpoint addresses via your roaming code ? Or does actual tunnel data traffic need to occur to update roaming endpoints ? If PersistentKeepalive updates roaming endpoints, then it would seem to be a very rare situation when both endpoints had an address change within the PersistentKeepalive window. Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Request: Optional "Comment" [Peer] entry
I have a suggestion, feature request ... With several peers, the output of "wg show" is difficult to visually identify the peers at a quick glance. How about an optional "Comment = " entry for the [Peer] section. For Example: -- [Peer] PublicKey = UMJMPFVTzjmzr7SJMQ7k+Z+3Pr1aq4w+5chtUny6Akg= Endpoint = [fda6:66b2:b74a:50::3]:51820 AllowedIPs = 10.4.0.2/32 Comment = pbx3 - Jetway NF9HG-2930 -- For each peer in "wg show" with a "Comment = " defined ... -- peer: HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw= endpoint: [fda6:662b:b74a:50::3]:51820 allowed ips: 10.4.0.2/32 latest handshake: 3 seconds ago transfer: 376 B received, 680 B sent comment: pbx3 - Jetway NF9HG-2930 -- If others like this idea, should the comment be displayed first, last, etc. ? Truncating the comment string to 64 characters would be fine. Or even 32 chars. Thoughts ? Lonnie ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Roaming Mischief
On Nov 14, 2017, at 4:30 AM, Kalin KOZHUHAROV wrote:
> On Tue, Nov 14, 2017 at 10:59 AM, Jason A. Donenfeld wrote:
>> The other approach would be to add an optional exclamation
>> mark to the end of an endpoint specification
>> (Endpoint=my.server.whatever.zx2c4.com:51820!), that would prevent
>> servers from roaming; the client would still roam in the eyes of the
>> server, but the server, would no longer roam in the eyes of the
>> client. In other words, an option -- gasp, a nob! -- to disable
>> roaming on a per-by-peer one-sided basis. As you know, I don't really
>> like nobs. And I'd hate to add this, and then for people to use it,
>> and then loose some nice aspects of roaming, if it's not really even
>> required.
>>
> I have been wondering along those lines of roaming...
> There are certain use cases that require no roaming at all, e.g. a
> small set of servers that don't change IP.
> Anyway, a somewhat limited "roaming" can be achieved via DNS/hosts, if
> one trusts that system.
>
> While seamless roaming is a feature you use often I guess, my personal
> preference is to have it optional and explicitly specified, e.g. I
> have a few mobile devices (laptop, tablet), that only talk to 1 (or
> few at most) fixed IP (or DNS at least) "servers" (yes I know WG is
> P2P) and via those to the rest of the fixed hosts. So in this scenario
> (somewhat hard to achieve by {ip,nf}tables), I'd rather spec who is
> talking to whom, who can roam, etc.
>
> As for the syntax, and I hate to suggest that, adding a new option
> (breaking compatibility) like "AllowRoaming=yes|1" with default
> AllowRoaming=no is what I would like, instead of somewhat vague "!" at
> the end.
Kalin, I don't care for the somewhat vague "!" notation either ... reads NOT
to me.
But, I would not break compatibility, I suggest adding a "paranoid option"
EndpointFixed ...
--
EndpointFixed - Optional, defaults to 0|no, endpoint roaming is enabled by
default,. Set EndpointFixed to 1|yes to disable endpoint roaming. Ignored if
Endpoint is not defined.
--
As a side-benefit, the documentation of this option provides some
quick-reference documentation to the operation of WireGuard.
Lonnie
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
