How do I update to 4.13? Because uf dev still says 4.12bcWg_client (dev) was updated 29/11 whilst wg_manager (4.12bC) was updated 23/11.
Do you still have the same issues if you use wg client 4.13 (29/11)
//Zeb
How do I update to 4.13? Because uf dev still says 4.12bcWg_client (dev) was updated 29/11 whilst wg_manager (4.12bC) was updated 23/11.
Do you still have the same issues if you use wg client 4.13 (29/11)
//Zeb
When you invoke theHow do I update to 4.13? Because uf dev still says 4.12bc
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.12bCe = 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
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.uf dev
upgrade, you may see errors such asfind: ‘/proc/nnnn/task/nnnn/net’: Invalid argument
find: ‘/proc/nnnn/net’: Invalid argument
e = Exit Script [?]
E:Option ==> uf dev
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 theIt 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...
wireguard_manager
IPv6 support mods.Indeed, but I agree that the list of IPv6 hybrid optionsAnyhow, really hope someone else with a dual stack ipv6 continues to elaborate this with wgm.
wg_manager
should be using either IPv4 or IPv6wireguard_manager
IPv4/IPv6 impacts based on this snippetThanks! I was looking forward to the journey too.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 thewireguard_manager
IPv6 support mods.
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.Perhaps I'm overthinking thewireguard_manager
IPv4/IPv6 impacts based on this snippet
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 >>>>>>
Indeed - but not sure what you consider an acceptable 'good up-time figure' ?As wgm restart all interfaces whenever nat-start or firewall-start event happens it is really hard to get good up-time figure.
3 weeks (uninterrupted?)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 >>>>>>
wireguard
(compared with an undisclosed WAN) up-time would seem to be acceptably 'good'?So I'm not sure what you propose.Well, down to 0 now
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?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.So I'm not sure what you propose.
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
OK,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!
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?)I don't believe OpenVPN itself provides session up-time metrics, so it would be difficult to provide a comparison
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?The longest openvpn session I had is around two weeks but wireguard just keep running.
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)?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 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.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
Yes, looks like buildin wireguard support is coming soon for AX models. Hopefully it will cover AC models too.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)?
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?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?)
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?:
Wireguard - Session Manager - Discussion (2nd) thread
Ok, so now I know for sure what is the real deal in my conf if I want it to work. Its the ipv6 in Address and Allowedips. I must remove those, otherwise it wont work. Nothing else needs changed. Ok so it is ipv6 related. When you import a Peer with ipv4 and ipv6 and look at the output of (in...www.snbforums.com
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.
Wireguard - Session Manager - Discussion (2nd) thread
Ok, so now I know for sure what is the real deal in my conf if I want it to work. Its the ipv6 in Address and Allowedips. I must remove those, otherwise it wont work. Nothing else needs changed. Ok so it is ipv6 related. When you import a Peer with ipv4 and ipv6 and look at the output of (in...www.snbforums.com
?take a snip of the router output of "ip rule" before and after this has happened and compare if something has changed.
Have you checked so your computer have not changed ip adress?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.
If you exit wgm and in the terminal issueWhat exatcly do you mean with
ip rule
ip route show table main
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.
This im certain of because I have set static ip 192.168.1.20 on the computers nic mac address on the router.Have you checked so your computer have not changed ip adress?
??? 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 peer does not help. I must restart router or uninstall WGM
route print -4
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
??? 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
As theThe only thing I know for sure, is if I restart router or uninstall WGM, I don't have the issue.
wireguard_manager
v4.23bX Beta contains numerous blind hacks to accommodate IPv6, I may have inadvertently caused a problem.e = Exit Script [?]
E:Option ==> uf
@DreaZ Reported the same problem over a month ago here, but I agree that this should be the first resort before deeper troubleshooting.I suggest you revert to the stable version v3.22, and see if the 'slowdown' problem persists
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!