What's new

Wireguard Session Manager - Discussion (2nd) thread

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

@DreaZ Reported the same problem over a month ago here,
OK thanks, so its probably/definitely not IPv6 related, as it hopefully IPv6 isn't ENABLED
What would the difference be by uninstalling wgm and stopping the peers? Or installing wgm new vs restarting the peers? It doesn't make sense (to me)...
Perhaps when issuing the wireguard_manager 'stop wg1x' command I don't properly clear/tear-down everything whereas an uninstall/reboot does.

So the only thing that wireguard_manager can influence is the MTU used by the peer and the TCP MSS '--clamp-mss-to-pmtu'

I have uploaded wireguard_manager Beta v4.12bE which contains a couple of tweaks
  1. Optionally DISABLE the TCP MSS '--clamp-mss-to-pmtu' firewall rule
  2. Increase the range of the allowed Peer MTU to 1280-1500 (default if not specified is 1420)
To upgrade use
Code:
e  = Exit Script [?]

E:Option ==> uf dev

    Router RT-AC86U Firmware (v3.0.0.4.386.3_beta1)

    [✔] Entware Architecture arch=aarch64


    v4.12bE WireGuard Session Manager (Change Log: https://github.com/MartineauUK/wireguard/commits/dev/wg_manager.sh)
    MD5=442977f9e06ba0d911bcdfcd809aeecd /jffs/addons/wireguard/wg_manager.sh

    wireguard: WireGuard 1.0.20210124 loaded. See www.wireguard.com for information.
    wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.

    [✔] WireGuard Module LOADED
then issue
Code:
e  = Exit Script [?]

E:Option ==> createconfig

    Warning: WireGuard configuration file '/jffs/addons/wireguard/WireguardVPN.conf' already exists!...renamed to 'WireguardVPN.conf20211208-105150'

    Creating WireGuard configuration file '/jffs/addons/wireguard/WireguardVPN.conf'

     WireGuard ACTIVE Peer Status: Clients 0, Servers 0
So to disable the TCP clamping of MSS to PMTU (tutorial description here ) use vx command to uncomment the 'NOTCPMSS' directive in the WireGuard config.

...then restart ALL servers/clients.

Messing with MTU value can be tedious, but WireGuard apparently tolerates any value between 1280 and 1500 (although wireguard_manager previously only allowed 1420 as the maximum value.)

@DreaZ

You can certainly try disabling the TCPMSS then try setting the Peer MTU to the lowest value 1280
e.g.
Code:
e  = Exit Script [?]

E:Option ==> peer wg11 mtu=1280

    [✔] Updated MTU
then restart the 'client' Peer, then check its MTU when it has initialised/connected to its Peer

e.g.
Code:
ip a l wg11 | head -n 1
77: wg11: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000
and see if the slowdown still occurs.

P.S. I recall seeing 1380 being a suggested working WireGuard MTU value rather than the default 1420, but you could even try 1500 but it may simply fail to connect.
 
Last edited:
I set up the server & added a test client, imported config to Wireguard app on phone, and now I can access the router login page from my phone on cellular data (but no internet access). So, it works?
ok, how were your speeds? This is the real question
 
OK thanks, so its probably/definitely not IPv6 related, as it hopefully IPv6 isn't ENABLED

Perhaps when issuing the wireguard_manager 'stop wg1x' command I don't properly clear/tear-down everything whereas an uninstall/reboot does.

So the only thing that wireguard_manager can influence is the MTU used by the peer and the TCP MSS '--clamp-mss-to-pmtu'

I have uploaded wireguard_manager Beta v4.12bE which contains a couple of tweaks
  1. Optionally DISABLE the TCP MSS '--clamp-mss-to-pmtu' firewall rule
  2. Increase the range of the allowed Peer MTU to 1280-1500 (default if not specified is 1420)
To upgrade use
Code:
e  = Exit Script [?]

E:Option ==> uf dev

    Router RT-AC86U Firmware (v3.0.0.4.386.3_beta1)

    [✔] Entware Architecture arch=aarch64


    v4.12bE WireGuard Session Manager (Change Log: https://github.com/MartineauUK/wireguard/commits/dev/wg_manager.sh)
    MD5=442977f9e06ba0d911bcdfcd809aeecd /jffs/addons/wireguard/wg_manager.sh

    wireguard: WireGuard 1.0.20210124 loaded. See www.wireguard.com for information.
    wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.

    [✔] WireGuard Module LOADED
then issue
Code:
e  = Exit Script [?]

E:Option ==> createconfig

    Warning: WireGuard configuration file '/jffs/addons/wireguard/WireguardVPN.conf' already exists!...renamed to 'WireguardVPN.conf20211208-105150'

    Creating WireGuard configuration file '/jffs/addons/wireguard/WireguardVPN.conf'

     WireGuard ACTIVE Peer Status: Clients 0, Servers 0
So to disable the TCP clamping of MSS to PMTU (tutorial description here ) use vx command to uncomment the 'NOTCPMSS' directive in the WireGuard config.

...then restart ALL servers/clients.

Messing with MTU value can be tedious, but WireGuard apparently tolerates any value between 1280 and 1500 (although wireguard_manager previously only allowed 1420 as the maximum value.)

@DreaZ

You can certainly try disabling the TCPMSS then try setting the Peer MTU to the lowest value 1280
e.g.
Code:
e  = Exit Script [?]

E:Option ==> peer wg11 mtu=1280

    [✔] Updated MTU
then restart the 'client' Peer, then check its MTU when it has initialised/connected to its Peer

e.g.
Code:
ip a l wg11 | head -n 1
77: wg11: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group default qlen 1000
and see if the slowdown still occurs.

P.S. I recall seeing 1380 being a suggested working WireGuard MTU value rather than the default 1420, but you could even try 1500 but it may simply fail to connect.

Done uf dev and createconfig. Restarted peer and uncommented NOTCPMSS and tried MTU 1280, 1380, 1420, 1500 and saw no difference. Did a restart of peer after every change.

I restarted router and have only WGM active now to get full speed again, no WG or OpenVPN active atm on computer or any OpenVPN active on router, just WGM.

Uploaded pic with some details. Will upload a new pic with in a couple of hours when speed limit is down to 300/300. Funny thing, it is always around 300/300 it drops down to and usually after a day. And there is no internet activity except for the speedtest.
Issue disappears if I reboot router, or if I uninstall WGM. It's a strange issue indeed.

1639027129195.png


Edit: I hope I didn't post to much info now :\
 
Last edited:
P.S. I recall seeing 1380 being a suggested working WireGuard MTU value rather than the default 1420, but you could even try 1500 but it may simply fail to connect.
a 3yr-old post, but CloudFlare has chosen 1400...that may have changed:

I believe as we transition faster and deeper into a v6 internet, bigger datagrams will become increasingly discussed and agreed to, as jumbo frames were what the framers had in mind IIRC.
check the options on your devices network interfaces, I guess...

I'm actually rather excited. I've not followed this thread for a while, but I almost cheered out loud with a sleeping house to see Merlin step in and bring this onboard in preparation for his new v386.4 release (a ways off yet, but still...)

I've Native v6, @Martineau. and if my Christmas is as quiet as I suspect it will be, I'll be offering my services to help bring things further along here.
 
Done uf dev and createconfig. Restarted peer and uncommented NOTCPMSS and tried MTU 1280, 1380, 1420, 1500 and saw no difference. Did a restart of peer after every change.
what happens if you go above 1500? not just by a few bytes, either - double, triple, quadruple that. 3000, 4500, 6000 bytes?

Are we thinking correctly about these things? if wireguard encapsulates v4 traffic within v6 automagically (I would tend to infer that wireguard defaults to v6, and has gently and elegantly worked out how to handle v4 traffic from the start so that we may not have to), what's to say that 1500 is the max between clients when moving data within a WG (read IPv6) tunnel? does MTU even matter in a v6 network? is it more a function of what the NIC of the clients on each end are capable of? can they negotiate between themselves individually what works best...while they do the key exchange/verification?

are we stuck in v4 world thinking, where there is an MTU of 1500B...that IPv6 folks decided to do away with in preparation for a higher speed interconnected world? All of our LANs, after all, are capable of 1Gbps these days. we all may not have WAN speeds in line with it (yet), but with native v6 creeping in faster and wider, does setting an MTU even matter anymore when wireguard is taken into account?

UPDATE - I've had jumbo frames enabled on my ac86 for 24+ hrs now...LAN feels/acts faster (unprompted comments from users), and CPU/radio temps have dropped. My ISP doesn't officially support jumbo frames, but given the native connection, I'm wondering if its possible for them to be routed from capable servers to clients... Another thing: ntpMerlin is reporting a stable offset and very low drift compared to before jumbo frames... Isn't reverse engineering fun?
 
Last edited:
Done uf dev and createconfig. Restarted peer and uncommented NOTCPMSS and tried MTU 1280, 1380, 1420, 1500 and saw no difference. Did a restart of peer after every change.
Thank you for taking the time to test.

To be honest, in my limited testing, I don't think tweaking MTU made a tangible difference - simply retrieved a 10MB file via the 'client Peer and changing the MTU may have changed +/-2 secs to the transfer, but basically wireguard still worked.

Is there a specific time that the slowdown occurs?, or can it be apparently random?
 
ok, how were your speeds? This is the real question
My connection is a 100DL/5UL asymmetric cable, and fast.com gives me 3.4UL/3.9DL.
 
My connection is a 100DL/5UL asymmetric cable, and fast.com gives me 3.4UL/3.9DL.
With 100/5 speed, wireguard should barely be noticeable on your system, still your speed gets cut to 3.9 download...

You might need to disable flow cache as is needed in the AX86U model. If you issue at router prompt:
Code:
fc disable
Wgm handles this for the AX86U but since your AX58U is pioneering wireguard I'm guessing wgm would not set this.


Is your download speed increased?

//Zeb
 
My connection is a 100DL/5UL asymmetric cable, and fast.com gives me 3.4UL/3.9DL.

This is from your mobile as wg client dial in to your home router acting as wg server right? Your client download speed is limited by your mobile network download speed and also home connection upload speed of 5Mbps. Likewise, your client upload speed will be limited by mobile network upload speed and home router download speed. Since you have 100Mbps DL, your upload speed is likely limited by your mobile network at that time.

Edit: Your client upload will eventually reach home router (via 100Mbps DL) and then using its 5Mbps UL to reach fast.com. Looks like on client, both upload and download will be limited by your home 5Mbps UL.
 
Last edited:
New wireguard kernel version, 20211208


Code:
bump HEAD v1.0.20211208 master

-crypto: curve25519-x86_64: solve register constraints with reserved registers
-udp_tunnel: don't take reference to non-init namespace
-compat: siphash: use _unaligned version by default
-ratelimiter: use kvcalloc() instead of kvzalloc()
-receive: drop handshakes if queue lock is contended
-receive: use ring buffer for incoming handshakes
-device: reset peer src endpoint when netns exits
-main: rename 'mod_init' & 'mod_exit' functions to be module-specific
-netns: actually test for routing loops
-compat: update for RHEL 8.5
-compat: account for grsecurity backports and changes
-compat: account for latest c8s backports

Kernel modules for RT-AC86U and RT-AX88U compiled and AC86U is currently under test.

Still looking for anyone who could contribute to test the RT-AX88U, if you have the ability please pm me and I will send instructions.

//Zeb
 
Last edited:
With 100/5 speed, wireguard should barely be noticeable on your system, still your speed gets cut to 3.9 download...
Not sure if related but Cake-QoS is enabled on the router with 95DL/4.8UL caps. I’ll check it with fc disable when I get back home.
This is from your mobile as wg client dial in to your home router acting as wg server right?
Yes.
Looks like on client, both upload and download will be limited by your home 5Mbps UL.
I believe that’s how it’s supposed to work with any VPN server running on the router. You’re limited to your UL speed.

(Sorry for the short answers but I’m on mobile and it’s hard to type with my relatively fat fingers)
 
Hello my fellow netbuilders, i am experimenting with wireguard. The connection seems to be going well, only problem is i cant seem to access my Synology nas samba shares. I did add on the smb.conf on the synology allready allow hosts with the 10.50.0.0/24 ip range but that doesnt seem to do the trick. Can anyone help me to get access with wireguard to my samba shares on the nas? I can access all my local ip-adresses (192.168.1.0/24 range). Thx for helping out!
 
Hello my fellow netbuilders, i am experimenting with wireguard. The connection seems to be going well, only problem is i cant seem to access my Synology nas samba shares. I did add on the smb.conf on the synology allready allow hosts with the 10.50.0.0/24 ip range but that doesnt seem to do the trick. Can anyone help me to get access with wireguard to my samba shares on the nas? I can access all my local ip-adresses (192.168.1.0/24 range). Thx for helping out!

Hi, since you have allow wg client subnet, are you able to ping to your nas and vice versa? Also, do you access samba share by ip or hostname?
 
1. yes i can ping my nas from my devices when using wireguard
2. i tried to access the samba shares of the nas trough the hostname and the ip-adress, they both dont work
 
Thank you for taking the time to test.

To be honest, in my limited testing, I don't think tweaking MTU made a tangible difference - simply retrieved a 10MB file via the 'client Peer and changing the MTU may have changed +/-2 secs to the transfer, but basically wireguard still worked.

Is there a specific time that the slowdown occurs?, or can it be apparently random?

It is random. Speed limit happened yesterday evening. 100% confident if I restart router (it will reappear though) it will be back to full speed, or if uninstall WGM (issue doesn't reappear).
And it is not speedtest.net because I get same measurement on bredbandskollen.se

1639237124801.png


No WiFi
1639237254637.png


Barely any traffic w/o speedtest
1639237660821.png
 
Last edited:
if I restart router (it will reappear though) it will be back to full speed, or if uninstall WGM (issue doesn't reappear).
This is puzzling indeed.

Wgm should really not affect your wan speed, sounds like wireguard somehow is interfering with your system...

Is the anything in the sys logs, meybee something crashes?

Been looking into what happens when wgm uninstalls and one thing is that it un-installs the entware kernel modules (not sure if that means it will unload but I guess)

Next time it happens, Instead of uninstalling wireguard, stop all peers and see if you can un-load the kernel module and see if that makes your wan speed pick up:
Code:
rmmod -f wireguard
(It will be reloaded as you start the peers again)

If it does work it might indicate that wireguard is somehow clashing with the kernel or other kernel modules.

//Zeb
 
Last edited:
This is puzzling indeed.

Wgm should really not affect your wan speed, sounds like wireguard somehow is interfering with your system...

Is the anything in the sys logs, meybee something crashes?

Been looking into what happens when wgm uninstalls and one thing is that it un-installs the entware kernel modules (not sure if that means it will unload but I guess)

Next time it happens, Instead of uninstalling wireguard, stop all peers and see if you can un-load the kernel module and see if that makes your wan speed pick up:
Code:
rmmon -f wireguard
(It will be reloaded as you start the peers again)

If it does work it might indicate that wireguard is somehow clashing with the kernel or other kernel modules.

//Zeb

E:Option ==> rmmon -f wireguard

Invalid Option " Invalid Option "rmmon -f wireguard" Please enter a valid option" Please enter a valid option


RT-AC86U-7848:/tmp/home/root# rmmon -f wireguard
-sh: rmmon: not found
 
Sorry, typo, rmmod should be correct

Code:
rmmod -f wireguard

And it should be executed at ssh prompt, not in wgm.
 
Last edited:
Hello my fellow netbuilders, i am experimenting with wireguard. The connection seems to be going well, only problem is i cant seem to access my Synology nas samba shares. I did add on the smb.conf on the synology allready allow hosts with the 10.50.0.0/24 ip range but that doesnt seem to do the trick. Can anyone help me to get access with wireguard to my samba shares on the nas? I can access all my local ip-adresses (192.168.1.0/24 range). Thx for helping out!
With a lot of effort and help of ZebMcKayhan it was resolved. To also help others who struggle with this issue about using smb shares on a nas (not your router, but for instance synology) add on ssh router this:

"iptables -t nat -I POSTROUTING -s 10.50.X.0/24 -d 192.168.1.Y -j SNAT --to-source 192.168.1.Z -m comment --comment "WireGuard 'server'" where 10.50.x.0/24 stands for your wireguard server ip-range, 192.168.1.Y is the ip of your nas/samba share device, 192.168.1.z is the local ip-adress of your router.

All credit goes to zeb for this one, thx!

Btw the samba shares can't be reached with the samba server name but you got to use the ip-adress like for example \\ip-adress of your nas or samba share device, this is because wireguard is udp-based.
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top