Wireguard speed
Help with speed in the wireguard vpn. There are 2 routers linksys with openwrt 19.07.7. And the wireguard tunnel between them. If the link between the Wan of both routers is 1 gigabit/s, then the speed inside the tunnel is 300-370 Mb/s, which I think is good. I understand that these are simple routers, not servers. This is done for the test. In real life, the speed between the feasts will be limited to 100 Mb/s. I decided to do a test and lowered the speed on the switch ports (routers connected through a gigabit switch) to 100 Mb/s. After that, the speed between routers through wg is 30-40 Mb/s. Processors on routers are loaded at 25-25%. Once I am on a channel in 100 Mb/s. received speeds between routers 85-90 Mb/s. So such speeds are possible on the wireguard. After that, something went wrong with the electricity and the routers were rebooted. I didn't have time to save the settings. From memory, I set everything up again, but now I can't achieve high speeds... I measure iperf3 installed on the routers themselves. How can I get ~ 80-90 Mb/s again via 100 Mb/s channel? I will be grateful for any help in setting the speed wireguard p.s Forgive my English. I do not know him well and use a translator
Re: FreeBSD if_wg POINTTOPOINT and MULTICAST behaviour
On Fri, Apr 16, 2021 at 9:17 AM Jason A. Donenfeld wrote: > > I set up a lab and will do some testing with version before and after > > the change, maybe for FRR it's enough to set NBMA or similar. > > Could you send a minimal bird config that's broken so that I can > reproduce the problem and debug? With the latest version -- https://lists.zx2c4.com/pipermail/wireguard/2021-April/006634.html -- wireguardd seems to be working out of the box with frr.
Re: FreeBSD if_wg POINTTOPOINT and MULTICAST behaviour
Hi Michael, On 4/16/21, Muenz, Michael wrote: > Am 16.04.2021 um 10:57 schrieb Stefan Haller: >> After applying Toke's patch for bird and your Wireguard patch in >> a7a84a17faf784 everything is working as before (with minor config >> changes). >> >> Just for the record, my previous configuration looked like this (using >> POINTTOPOINT interfaces, I use ifconfig to set the peer address): > > > Hi, > > Just following the conversation and also had a quick chat with Jason via > IRC (mimugmail). > We had a couple of reports that with latest change of removing PTP which > breaks OSPF. > In our case (OPNsense) we rely on FRR so it would be nice to have a > generic solution without toucingh routing software itself. > > >> So for me everything works as expected again. A big thanks to all of you >> for >> figuring out what was going wrong and getting it fixed so quickly. >> >> > > I set up a lab and will do some testing with version before and after > the change, maybe for FRR it's enough to set NBMA or similar. Could you send a minimal bird config that's broken so that I can reproduce the problem and debug? Jason
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: FreeBSD if_wg POINTTOPOINT and MULTICAST behaviour
Am 16.04.2021 um 10:57 schrieb Stefan Haller: After applying Toke's patch for bird and your Wireguard patch in a7a84a17faf784 everything is working as before (with minor config changes). Just for the record, my previous configuration looked like this (using POINTTOPOINT interfaces, I use ifconfig to set the peer address): Hi, Just following the conversation and also had a quick chat with Jason via IRC (mimugmail). We had a couple of reports that with latest change of removing PTP which breaks OSPF. In our case (OPNsense) we rely on FRR so it would be nice to have a generic solution without toucingh routing software itself. So for me everything works as expected again. A big thanks to all of you for figuring out what was going wrong and getting it fixed so quickly. I set up a lab and will do some testing with version before and after the change, maybe for FRR it's enough to set NBMA or similar. Best, Michael
Re: FreeBSD if_wg POINTTOPOINT and MULTICAST behaviour
Stefan Haller writes: > Hi Jason, > > On Thu, Apr 15, 2021 at 06:05:03PM -0600, Jason A. Donenfeld wrote: >> I spent the day playing around with bird and babel and sorted out >> FreeBSD's v6 situation. Basically, ff00::/8 addresses are treated >> differently, and they're blocked unless the interface sets >> IFF_MULTICAST. So I've committed >> https://git.zx2c4.com/wireguard-freebsd/commit/?id=a7a84a17faf784857f076e37aa4818f6b6c12a95 >> to do this. > > That is also what I observed. Without IFF_MULTICAST I see the following > error in bird's log: > > bird[8045]: babel1: Socket error: IPV6_MULTICAST_IF: Can't assign requested > address > bird[8045]: babel1: Cannot open socket for wg1 > >> Stefan - please let me know if those work for you. In my testing thus >> far, things seem to work for me. > > After applying Toke's patch for bird and your Wireguard patch in > a7a84a17faf784 everything is working as before (with minor config > changes). > > Just for the record, my previous configuration looked like this (using > POINTTOPOINT interfaces, I use ifconfig to set the peer address): > >> [Interface] >> ... >> Address = fe80::5/64 >> PostUp = ifconfig %i inet 169.254.42.5/32 169.254.42.2 > > My new configuration without POINTTOPOINT, but only a single peer > directly attached to other side of the wg tunnel: > >> [Interface] >> ... >> Address = 169.254.42.5/32, fe80::5/64 >> PostUp = route add 169.254.42.2 -iface %i > > So for me everything works as expected again. A big thanks to all of you for > figuring out what was going wrong and getting it fixed so quickly. Great! You're welcome :) -Toke
Re: FreeBSD if_wg POINTTOPOINT and MULTICAST behaviour
Hi Jason, On Thu, Apr 15, 2021 at 06:05:03PM -0600, Jason A. Donenfeld wrote: > I spent the day playing around with bird and babel and sorted out > FreeBSD's v6 situation. Basically, ff00::/8 addresses are treated > differently, and they're blocked unless the interface sets > IFF_MULTICAST. So I've committed > https://git.zx2c4.com/wireguard-freebsd/commit/?id=a7a84a17faf784857f076e37aa4818f6b6c12a95 > to do this. That is also what I observed. Without IFF_MULTICAST I see the following error in bird's log: bird[8045]: babel1: Socket error: IPV6_MULTICAST_IF: Can't assign requested address bird[8045]: babel1: Cannot open socket for wg1 > Stefan - please let me know if those work for you. In my testing thus > far, things seem to work for me. After applying Toke's patch for bird and your Wireguard patch in a7a84a17faf784 everything is working as before (with minor config changes). Just for the record, my previous configuration looked like this (using POINTTOPOINT interfaces, I use ifconfig to set the peer address): > [Interface] > ... > Address = fe80::5/64 > PostUp = ifconfig %i inet 169.254.42.5/32 169.254.42.2 My new configuration without POINTTOPOINT, but only a single peer directly attached to other side of the wg tunnel: > [Interface] > ... > Address = 169.254.42.5/32, fe80::5/64 > PostUp = route add 169.254.42.2 -iface %i So for me everything works as expected again. A big thanks to all of you for figuring out what was going wrong and getting it fixed so quickly. Kind regards, Stefan
