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!

How do I update to 4.13? Because uf dev still says 4.12bc
When you invoke the uf command, all scripts are downloaded as a set......i.e. the auxiliary scripts have different version numbers but only the main script wg_manager.sh version number is reported e.g. v4.12bC
Code:
e  = Exit Script [?]

E:Option ==> uf dev

    Router RT-AC86U Firmware (v3.0.0.4.386.3_beta1)

    [✔] Entware Architecture arch=aarch64


    v4.12bD WireGuard Session Manager (Change Log: https://github.com/MartineauUK/wireguard/commits/dev/wg_manager.sh)
    MD5=586c73e28cc4855706902e86f4e4730d /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


    ***ERROR: MD5= ???? - WireGuard exists in firmware for  (v3.0.0.4.386.3_beta1)

    Checking for WireGuard Kernel and Userspace Tool updates...

    [✔] WireGuard Kernel module/User Space Tools included in Firmware RT-AC86U (v3.0.0.4.386.3_beta1) (1.0.20210124)

        WireGuard exists in firmware       - use 'vx' command to override with 3rd-Party/Entware (if available)
        User Space tool exists in firmware - use 'vx' command to override with 3rd-Party/Entware (if available)


    [✔] WireGuard Kernel module/User Space Tools included in Firmware (1.0.20210124)

    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.


    Forced Update

    Downloading scripts
    wg_manager.sh downloaded successfully Github 'dev/development' branch
    wg_client downloaded successfully Github 'dev/development' branch
    wg_server downloaded successfully Github 'dev/development' branch
    UDP_Updater.sh downloaded successfully Github 'dev/development' branch

I have uploaded Beta wireguard_manager v4.12bD which hopefully contains a patched wg_manager.sh which may correct your issue where the retrieved Received/Transmit metrics appear to be blank rather than a valid numerical value - hence the error messages trying to perform the arithmetic operation in order to create the report.

If you have time, could you please upgrade and test.

NOTE: During the uf dev upgrade, you may see errors such as
Code:
find: ‘/proc/nnnn/task/nnnn/net’: Invalid argument
find: ‘/proc/nnnn/net’: Invalid argument
if so, then simply immediately reissue
Code:
e  = Exit Script [?]

E:Option ==> uf dev
 
Last edited:
It appears I cannot get ipv6 because my infrastructure provider have not updated their stuff... I tried to get a target date but got something like "any year now" so there goes that dream...
Truly disappointed for you, as I was hoping to have an enthusiastic supporter/guinea pig to keep me honest with my blind hacks in the dark with my naïve attempts at the wireguard_manager IPv6 support mods.

Did contemplate switching to a ISP that currently supports IPv6, given I received a similar response >5 years ago "well maybe in the future ...if there is a demand for it" from my current ISP that I have used for over a decade - but, better the devil you know etc., and I have experienced only 1 outage lasting > 3 hours during the contract so their IPv4 support is sound.

Anyhow, really hope someone else with a dual stack ipv6 continues to elaborate this with wgm.
Indeed, but I agree that the list of IPv6 hybrid options

1638440715284.png

clearly shows that I was brain-dead to originally assume wg_managershould be using either IPv4 or IPv6

I am going to spend time over the next couple of weeks from my home, so will take my development routers, so may be able to gain some practical hands-on IPv6 experience. Sadly I will behind a Sky router that is running IPv6, not ideal, but better than nothing.

Perhaps I'm overthinking the wireguard_manager IPv4/IPv6 impacts based on this snippet

1638441526618.png


but it will me keep me sane/occupied over the festive period.
 
Truly disappointed for you, as I was hoping to have an enthusiastic supporter/guinea pig to keep me honest with my blind hacks in the dark with my naïve attempts at the wireguard_manager IPv6 support mods.
Thanks! I was looking forward to the journey too.

Perhaps I'm overthinking the wireguard_manager IPv4/IPv6 impacts based on this snippet
I'm not to sure... I'm still concerned about the nat:ing part and the stateless assignment (or lack of) of ips (apparently Android don't support stateful). Guess we don't know until one tries it out, then hopefully it folds out.

If you think I'm of any use, feel free to pm me if the brick-wall is cloosing in.

As long as we can get the ipv6 client up and running in parallel with the ipv4 I don't think the other modes will be any problem. But the policy routing could be a hand-ful to figure out.

//Zeb
 
Last edited:
As wgm restart all interfaces whenever nat-start or firewall-start event happens it is really hard to get good up-time figure. Yesterday I updated YazFi without thinking which lead to a firewall-start event and a restart of wireguard (which went perfectly smooth and if I hadn't seen it in the logs I wouldn't have noted it).
This is my best achievement so far:
Code:
Dec  4 21:59:02 RT-AC86U-D7D8 (wg_manager.sh): 27244 wg11: transfer: 105.65 GiB received, 9.16 GiB sent        
25 days 20:18:44 from 2021-11-09 01:40:18 >>>>>>

Well, down to 0 now

//Zeb
 
Last edited:
As wgm restart all interfaces whenever nat-start or firewall-start event happens it is really hard to get good up-time figure.
Indeed - but not sure what you consider an acceptable 'good up-time figure' ?
Yesterday I updated YazFi without thinking which lead to a firewall-start event and a restart of wireguard (which went perfectly smooth....
Code:
Dec  4 21:59:02 RT-AC86U-D7D8 (wg_manager.sh): 27244 wg11: transfer: 105.65 GiB received, 9.16 GiB sent     
25 days 20:18:44 from 2021-11-09 01:40:18 >>>>>>
3 weeks (uninterrupted?) wireguard (compared with an undisclosed WAN) up-time would seem to be acceptably 'good'?
Well, down to 0 now
So I'm not sure what you propose.

e.g. perhaps making the enforced bounce of ALL ACTIVE wireguard Peers on say the firewall-start event execution (which normally would be associated with a WAN restart but in this case is caused by the 3rd-party script update) optional?
or
something else?
 
Last edited:
So I'm not sure what you propose.
Not proposing anything really. I was trying to reach as good as I could, but at the end I couldn't keep my hands away. Wireguard/wgm could probably go on forever.
My WAN uptime is abit over 50 days but 25 days ago I stopped messing around with various troubleshooting and the system has performed flawless ever since. Adding wgm to firewall-start and disable kill-switch was the final piece of the puzzle that broke my ipset access. An hazzle free YazFi upgrade finally proved everything to be working.

The reason for posting was 2-fold:
- I would find it interesting to find out how long up-time others have.
- Informational for those not running wireguard(yet) that it is actually really stable.

I would say 3 weeks uninterrupted up-time is mediocre. Atleast proving no major memory leaks exists. But I'm certain there are much higher numbers out there.

//Zeb
 
As wgm restart all interfaces whenever nat-start or firewall-start event happens it is really hard to get good up-time figure. Yesterday I updated YazFi without thinking which lead to a firewall-start event and a restart of wireguard (which went perfectly smooth and if I hadn't seen it in the logs I wouldn't have noted it).
This is my best achievement so far:
Code:
Dec  4 21:59:02 RT-AC86U-D7D8 (wg_manager.sh): 27244 wg11: transfer: 105.65 GiB received, 9.16 GiB sent      
25 days 20:18:44 from 2021-11-09 01:40:18 >>>>>>

Well, down to 0 now

Not proposing anything really. I was trying to reach as good as I could, but at the end I couldn't keep my hands away. Wireguard/wgm could probably go on forever.
My WAN uptime is abit over 50 days but 25 days ago I stopped messing around with various troubleshooting and the system has performed flawless ever since. Adding wgm to firewall-start and disable kill-switch was the final piece of the puzzle that broke my ipset access. An hazzle free YazFi upgrade finally proved everything to be working.

The reason for posting was 2-fold:
- I would find it interesting to find out how long up-time others have.
- Informational for those not running wireguard(yet) that it is actually really stable.

I would say 3 weeks uninterrupted up-time is mediocre. Atleast proving no major memory leaks exists. But I'm certain there are much higher numbers out there.

//Zeb
OK,

I now understand, although I don't believe OpenVPN itself provides session up-time metrics, so it would be difficult to provide a comparison between the reliability of the two protocols - unlike throughput performance; given WireGuard's tangibly higher figures! :D
 
OK,

I now understand, although I don't believe OpenVPN itself provides session up-time metrics, so it would be difficult to provide a comparison between the reliability of the two protocols - unlike throughput performance; given WireGuard's tangibly higher figures! :D

I have been using your script to track openvpn uptime. In my case with NordVPN, wireguard is much more stable. The longest openvpn session I had is around two weeks but wireguard just keep running. I only have 100Mbps Internet access so there is not much speed difference between openvpn and wireguard. The major difference for me is unbound dns. Unbound routed via openvpn will restart whenever openvpn flap and losses its cache. Unbound routed via wireguard does not have this behavior.
 
I don't believe OpenVPN itself provides session up-time metrics, so it would be difficult to provide a comparison
Sure, but I guess one could also question wireguard up-time as it is connection-less and if the internet server were down for an hour it wouldn't show (or?)

(If internet goes down when no one is surfing, does it still make a noise?)

The longest openvpn session I had is around two weeks but wireguard just keep running.
Is this a tracking difference or did you manage to properly track the wireguard connection? The wg interface will not disconnect when/if the server is not responding as openVPN does (it will just resume whenever it gets back up) . This could subsequently be why unbound does not seem to restart?

//Zeb
 
I have been using your script to track openvpn uptime. In my case with NordVPN, wireguard is much more stable. The longest openvpn session I had is around two weeks but wireguard just keep running. I only have 100Mbps Internet access so there is not much speed difference between openvpn and wireguard. The major difference for me is unbound dns. Unbound routed via openvpn will restart whenever openvpn flap and losses its cache. Unbound routed via wireguard does not have this behavior.
Hi, I have been following this thread for a while but doing nothing because (a) I am waiting for inbuilt wireguard support (which seems to be getting ever closer) and (b) I had thought that you needed to use the NordVPN clients to access 'Nordlynx' (I already use Nord for outgoing OpenVPN). Are you accessing Nord's wireguard VPN service directly from the router and if so how do you go about it (e.g., can you start from an OpenVPN .opvn config file or is another approach needed)?
 
Sure, but I guess one could also question wireguard up-time as it is connection-less and if the internet server were down for an hour it wouldn't show (or?)

(If internet goes down when no one is surfing, does it still make a noise?)


Is this a tracking difference or did you manage to properly track the wireguard connection? The wg interface will not disconnect when/if the server is not responding as openVPN does (it will just resume whenever it gets back up) . This could subsequently be why unbound does not seem to restart?

//Zeb
I try to track by latest handshake time. I have a cronjob that check the latest handshake time every minute. If it is over 2.5 minutes, then it initiate a ping over wgvpn to check the peer connectivity. If ping timeout then it is record as operational down. I think I only saw this once.
More process are restarted when openvpn restart compared to wgvpn. When I route unbound via wgvpn, unbound will not restart even if I manually restart wireguard client.

Hi, I have been following this thread for a while but doing nothing because (a) I am waiting for inbuilt wireguard support (which seems to be getting ever closer) and (b) I had thought that you needed to use the NordVPN clients to access 'Nordlynx' (I already use Nord for outgoing OpenVPN). Are you accessing Nord's wireguard VPN service directly from the router and if so how do you go about it (e.g., can you start from an OpenVPN .opvn config file or is another approach needed)?
Yes, looks like buildin wireguard support is coming soon for AX models. Hopefully it will cover AC models too.
I use steps from the link below to get Nordlynx wireguard config information. Tested the config on my phone wireguard apps, then import the same config to wireguard manager in the router.
 
Sure, but I guess one could also question wireguard up-time as it is connection-less and if the internet server were down for an hour it wouldn't show (or?)

(If internet goes down when no one is surfing, does it still make a noise?)
I recall reading that if no data is sent between Peers then (by design?) no one can determine if the two endpoints are UP?, so is that more secure than unnecessarily pinging thru' the tunnel to advertise their presence?

Also, given WireGuard is designed to allow Peer roaming, then does it become even more difficult to reliably track the 'client' Peer up-time?

So I'd agree, tracking Peer up-time probably isn't a useful metric.
 
so, you mean the wgm exception for your computer appears to have been removed once a day?
whenever this happens, instead of removing wgm, try just to restart the peers to get all rules re-applied.

did you re-make your setup like I advised earlier?:

please verify if you computer is actually going out VPN even though the computer VPN is turned off when this has happened.

I have never experienced anything like this. whenever this is working, take a snip of the router output of "ip rule" before and after this has happened and compare if something has changed.

//Zeb

Edit: also check so your computer has not changed ip.

No the exception for my computer is still there in WGM. But after a couple of hours the speed gets limited somehow on my computer to 300mbit.

Restarting peer does not help. I must restart router or uninstall WGM. I don't get the issue if I use OpenVPN on the router with policy rules (192.168.1.0/24=VPN and 192.168.1.20=WAN).

I did follow your advice on

What exatcly do you mean with
take a snip of the router output of "ip rule" before and after this has happened and compare if something has changed.
?

I have uninstalled Diversion and Skynet but the issue is still there. What I have left is WGM, AMTM and Entware.
 
Last edited:
No the exception for my computer is still there in WGM. But after a couple of hours the speed gets limited somehow on my computer to 300mbit.
Have you checked so your computer have not changed ip adress?

What exatcly do you mean with
If you exit wgm and in the terminal issue
Code:
ip rule
It will show you the routing rules the system obeys along with priorities.
It could also be good to look at your main routing table so nothing have changed:
Code:
ip route show table main
If none of these have changed then your problem is not with wgm.

Please remove any public ip you might have if you post anything here.

//Zeb
 
DreaZ said:


No the exception for my computer is still there in WGM. But after a couple of hours the speed gets limited somehow on my computer to 300mbit.
Have you checked so your computer have not changed ip adress?
This im certain of because I have set static ip 192.168.1.20 on the computers nic mac address on the router.
 
Restarting peer does not help. I must restart router or uninstall WGM
??? what if you just stop the peers, are you still getting the low speed? (i.e. is it actually something else at play here)
restarting the peers are infact re-setting up everything in wgm, just in the same way as when you install it. rebooting the router or re-install wgm should not really make any difference for wgm, but it might for other auxiliary functions in the router.

still think it sounds like an issue between your computer and the router, like computer swapping to wifi (which has a different mac adress) or that the router for some reason assigns a different ip...

if its a windows machine you can check the windows routing table by open a command prompt and issue:
Code:
route print -4

here you shall se something like this:
Code:
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    192.168.106.1  192.168.106.228     35

here, my ip adress for the interface used to access unknown addresses (internet) is routed from interface with ip 192.168.106.228. this should in your case be "192.168.1.20" and your gateway should be "192.168.1.1". this is interesting in particular when you are experiencing the speed drop too se if your computer for some reason have a different interface/ip that routes data.

//Zeb
 
??? what if you just stop the peers, are you still getting the low speed? (i.e. is it actually something else at play here)
restarting the peers are infact re-setting up everything in wgm, just in the same way as when you install it. rebooting the router or re-install wgm should not really make any difference for wgm, but it might for other auxiliary functions in the router.

still think it sounds like an issue between your computer and the router, like computer swapping to wifi (which has a different mac adress) or that the router for some reason assigns a different ip...

if its a windows machine you can check the windows routing table by open a command prompt and issue:
Code:
route print -4

here you shall se something like this:
Code:
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    192.168.106.1  192.168.106.228     35

here, my ip adress for the interface used to access unknown addresses (internet) is routed from interface with ip 192.168.106.228. this should in your case be "192.168.1.20" and your gateway should be "192.168.1.1". this is interesting in particular when you are experiencing the speed drop too se if your computer for some reason have a different interface/ip that routes data.

//Zeb

The only thing I know for sure, is if I restart router or uninstall WGM, I don't have the issue. And it cannot be wifi, because I don't have that on the computer.

But I will do some more digging today and tomorrow with all your other helpful information.

Thanks for all the help Zeb.
 
The only thing I know for sure, is if I restart router or uninstall WGM, I don't have the issue.
As the wireguard_manager v4.23bX Beta contains numerous blind hacks to accommodate IPv6, I may have inadvertently caused a problem.

I suggest you revert to the stable version v3.22, and see if the 'slowdown' problem persists
Code:
e  = Exit Script [?]

E:Option ==> uf
 
I suggest you revert to the stable version v3.22, and see if the 'slowdown' problem persists
@DreaZ Reported the same problem over a month ago here, but I agree that this should be the first resort before deeper troubleshooting.

Assuming his computer slips over to vpn which is why his speed drops, but what if it's not? Could his ISP be throttling his speed because of heavy udp data? Then uninstalling wgm wouldn't matter, neither stopping the peers, but a reboot might get a new connection and reset everything.

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)...

Maybee unplugging the wan cord and then back in again could be worth a try from debugging perspective.

//Zeb
 

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