Wireguard Session Manager - Discussion (2nd) thread

[Martineau]

Whenever I have some spare time I'm trying to write together some kind of tutorial for using wgm. Trying too add information about common questions as well as some specific "how to's". It is not really finished yet but the headlines shows what information I would like to have there. For a sneak-peak check it out here
If you find any errors, please let me know.

When writing this I encountered the expected behavior of a peer in auto=n mode.

The obvious part is that it won't start on boot.
And by looking at the code it looks like it won't start on the generic:

E:Option ==> start

But it looks like it might start when explicitly started

E:Option ==> start wg11
or
E:Option ==> peer wg11 start

But what is the expected behavior of this peer when started like this? @Martineau ?

//Zeb

Peers that are either auto='Y' or auto='P' are automatically started during the boot process i.e. when there is no explicit peer specified with the start command.

Clearly auto='N' means that the peer will be excluded from the auto-start selection process, but still remains eligible to be explicitly controlled/managed manually using

E:Option ==> start wgxx

 

[ZebMcKayhan]

Peers that are either auto='Y' or auto='P' are automatically started during the boot process i.e. when there is no explicit peer specified with the start command.

Clearly auto='N' means that the peer will be excluded from the auto-start selection process, but may be controlled/managed manually using

E:Option ==> start wgxx

Thanks! So if you start an auto=N peer will it then start in default routing mode? Or will it start without any routes?

//Zeb

 

[Martineau]

Thanks! So if you start an auto=N peer will it then start in default routing mode? Or will it start without any routes?

//Zeb

Yes, it will start in the default (ALL) routing mode overriding any current ACTIVE 'client' peers.

 

[DragonOfJustice]

Whenever I have some spare time I'm trying to write together some kind of tutorial for using wgm. Trying too add information about common questions as well as some specific "how to's". It is not really finished yet but the headlines shows what information I would like to have there. For a sneak-peak check it out here
If you find any errors, please let me know.

When writing this I encountered the expected behavior of a peer in auto=n mode.

The obvious part is that it won't start on boot.
And by looking at the code it looks like it won't start on the generic:

E:Option ==> start

But it looks like it might start when explicitly started

E:Option ==> start wg11
or
E:Option ==> peer wg11 start

But what is the expected behavior of this peer when started like this? @Martineau ?

//Zeb

wow thanks Zeb the Unbound script actually fixed one of my issue, so before i use OpenVPN i can't find a way to mask DNS because it's showing my ISP IP unless i route ALL traffic through OpenVPN, i tried unbound_manager vpn=1 but no luck, after i use your script i'm able to route it through 192.168.50.1 and it has masked DNS IP wit VPN IP.
One thing i notice that, why does router using 192.168.50.1 but it's using WAN IP when i tried an ip curl in PuTTY, but when i bind 192.168.50.1 through Transmission or Unbound, it actually route through VPN. what's is happening?

 

[ZebMcKayhan]

wow thanks Zeb the Unbound script actually fixed one of my issue, so before i use OpenVPN i can't find a way to mask DNS because it's showing my ISP IP unless i route ALL traffic through OpenVPN, i tried unbound_manager vpn=1 but no luck, after i use your script i'm able to route it through 192.168.50.1 and it has masked DNS IP wit VPN IP.
One thing i notice that, why does router using 192.168.50.1 but it's using WAN IP when i tried an ip curl in PuTTY, but when i bind 192.168.50.1 through Transmission or Unbound, it actually route through VPN. what's is happening?

The difference is that packages from a local process typically does not have a source address that is fixed... if a package from i.e. "curl" appears it will have a destination adress based on what you specified (on the internet) but no source adress. so our rules like:
from 192.168.50.1 table 121
will not apply to this package until the package has got a source address.

during routing, since it will end up in the main table (since no other rules applies) and for unknown destinations it will be the default routing, so then the source address will be set to your wan interface. if the package will go out on your main lan (br0) then the source address will be 192.168.50.1. making a rule for source addresses 192.168.50.1 will only affect packages going to our local network which is not really what we wanted. Altough table 121 does contain routes to 192.168.50.x subnet so it wont create any problem it does not solve our problem.

we can make rules based on interface "local" (iif lo) which will redirect ALL local packages to another table. but the problem is that the policy routing table does not contain enough routes to serve our entire system. also the VPN udp packages will go out vpn which will not work. this is all very possible to work around but special rules and specific routes needs to be added which is kind of tedious and difficult to make work for any system.

some applications (like Transmission and Unbound) does support to have the local process request a specific source adress. This means that if we can use this and have these packages given a source address of 192.168.50.1 then our rule
from 192.168.50.1 table 121
will then apply to this package and it will be sent out on VPN. but this will only apply to the programs you configure this way which means it will not work for curl and it will not affect your vpn udp packages.

however, care must be taken on both these programs since table 121 only contains routes to LAN and VPN. both Unbound and Transmission might need to contact other subnets, like guest networks, vpn clients a.s.o. which means that these packages still needs to be redirected to the main routing table using rules like:
from ALL to 192.168.1.1/16 table main
from ALL to 10.50.1.1/24 table main

to redirect packages TO these subnets to the main routing table otherwise they will end up sent out the internet were the packages will be dropped.

hope this clears it out.

//Zeb

 

[DragonOfJustice]

The difference is that packages from a local process typically does not have a source address that is fixed... if a package from i.e. "curl" appears it will have a destination adress based on what you specified (on the internet) but no source adress. so our rules like:
from 192.168.50.1 table 121
will not apply to this package until the package has got a source address.

during routing, since it will end up in the main table (since no other rules applies) and for unknown destinations it will be the default routing, so then the source address will be set to your wan interface. if the package will go out on your main lan (br0) then the source address will be 192.168.50.1. making a rule for source addresses 192.168.50.1 will only affect packages going to our local network which is not really what we wanted. Altough table 121 does contain routes to 192.168.50.x subnet so it wont create any problem it does not solve our problem.

we can make rules based on interface "local" (iif lo) which will redirect ALL local packages to another table. but the problem is that the policy routing table does not contain enough routes to serve our entire system. also the VPN udp packages will go out vpn which will not work. this is all very possible to work around but special rules and specific routes needs to be added which is kind of tedious and difficult to make work for any system.

some applications (like Transmission and Unbound) does support to have the local process request a specific source adress. This means that if we can use this and have these packages given a source address of 192.168.50.1 then our rule
from 192.168.50.1 table 121
will then apply to this package and it will be sent out on VPN. but this will only apply to the programs you configure this way which means it will not work for curl and it will not affect your vpn udp packages.

however, care must be taken on both these programs since table 121 only contains routes to LAN and VPN. both Unbound and Transmission might need to contact other subnets, like guest networks, vpn clients a.s.o. which means that these packages still needs to be redirected to the main routing table using rules like:
from ALL to 192.168.1.1/16 table main
from ALL to 10.50.1.1/24 table main

to redirect packages TO these subnets to the main routing table otherwise they will end up sent out the internet were the packages will be dropped.

hope this clears it out.

//Zeb

Thank you for clearing out, one more thing i encountered is that from my network Unbound only works with 192.168.50.1, if i tried to bind it to .3 i have no internet access though (router is fine), but for Transmission .3 works fine and from Connections tab i can see .3 being ESTABLISHED from other peers when torrenting, also i tested out aria2c as well to see some performance boost from Transmission, and if i bind aria2c with .3 (using command --interface=192.168.50.3) it has no internet access as well, and it only works if i bind it with .1, is there something special going on? Btw i already set DHCP from .4 so .3 shouldn't be automatically bind to other devices and my WG11 is set VPN to 192.168.50.1/24 so it should be cover from .1 to .255

 

[ZebMcKayhan]

Thank you for clearing out, one more thing i encountered is that from my network Unbound only works with 192.168.50.1, if i tried to bind it to .3 i have no internet access though (router is fine), but for Transmission .3 works fine and from Connections tab i can see .3 being ESTABLISHED from other peers when torrenting, also i tested out aria2c as well to see some performance boost from Transmission, and if i bind aria2c with .3 (using command --interface=192.168.50.3) it has no internet access as well, and it only works if i bind it with .1, is there something special going on? Btw i already set DHCP from .4 so .3 shouldn't be automatically bind to other devices and my WG11 is set VPN to 192.168.50.1/24 so it should be cover from .1 to .255

I don't know your system so I cant really answer this. the address used should be the interface br0 address (ifconfig br0) which I'm guessing is 192.168.50.1 but not sure. I wouldn't think that using an arbitrary address would work but I read something about binding to a non local address but I really wouldn't know. I would recommend to bind it to br0 local address.

//Zeb

Edit: Updated the section with required ip should be an ip local to the router itself and usually br0 ip address.

 

[DreaZ]

WGM is working great now as I/we found out it was the ipv6 line in the .conf that killed internet before. I use policy mode with my main comp excluded. And use the Wireguard on my computer instead to get full guns blazing on my internet speed. I get a stable 800/800mbit, sometimes up to around 900mbit. The devices going through Wireguard on the router is around 300/300mbit.

Once a day though the speed on my computer goes down to about 300/300mbit and stays there. I deactive Wireguard on the computer, no difference.

But If I uninstall WGM on the router, the speed stays stable at 800/800mbit, and does not go down to 300/300mbit.

It's weird.

 

[ZebMcKayhan]

WGM is working great now as I/we found out it was the ipv6 line in the .conf that killed internet before. I use policy mode with my main comp excluded. And use the Wireguard on my computer instead to get full guns blazing on my internet speed. I get a stable 800/800mbit, sometimes up to around 900mbit. The devices going through Wireguard on the router is around 300/300mbit.

Once a day though the speed on my computer goes down to about 300/300mbit and stays there. I deactive Wireguard on the computer, no difference.

But If I uninstall WGM on the router, the speed stays stable at 800/800mbit, and does not go down to 300/300mbit.

It's weird.

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.

 

[Martineau]

I've not seen any review on the WireGuard feature included by ASUS on supported AX routers, so.....

I had the opportunity to try it on a RT-AX86U running stock RC3-2 Firmware (v9.0.0.4.386_56898-ge21e952)

The 'Multiple VPN Connection' tab states 16 servers may be defined, but I suspect that total is for the mix of available clients rather than say 16 WireGuard 'client' Peers.

Along with the usual suspects PPTP,L2TP and OpenVPN in the 'VPN type' dropdown, being a long time HMA subscriber, it was a surprise/bonus to see HMA included in the firmware alongside WireGuard!

so I was able test L2TP and OpenVPN clients via HMA - and they worked.


WireGuard Peers, I was able to create both a 'server' and 'client' Peer (USA, Los Angeles) and the ASUS GUI duly created interfaces 'wgs1' and 'wgc5' respectively.

I hadn't seen the use of the WireGuard 'Pre-shared Key' option before, and IMHO there were a couple of clunky GUI issues.

The first appears to be that if you wish to set up a split tunnel say with one LAN device using the tunnel, the GUI will not allow you to add another LAN device until you terminate the 'client' Peer connection.
Probably best practice, but a little tedious considering the following dynamic command is presumambly all that is required
ip rule add from xxx.xxx.xxx.xxx table X prio x00;ip route flush cache

The second minor quibble is you can't use the Vendor supplied WireGuard configuration file as-is, you need to manually cut'n'paste the configuration into the individual GUI fields.
Not a big deal, but wouldn't it be nice if you could import the .conf directly into the GUI?

Hang on, I know a script that could do it!

Initially I was only going to add a simple command line option
e.g. '/jffs/addons/wireguard/wg_manager.sh import wireguard_configuration_file'

but since I was bored, I decided that with a little bit of tweaking, there is no reason why wireguard_manager shouldn't be able to run on stock firmware, pending @RMerlin's next firmware release based on v386_56898 or later.

NOTE: This exercise was a proof of concept, as there is no reliable '/jffs/' auto scripting etc. on stock firmware
Although there does appear to be the (circa 2019) bug where memaccess is apparently invoked/executed?!!!....success

e  = Exit Script [?]

E:Option ==> ?

    Router RT-AX86U Firmware (v9.0.0.4.386_56898-ge21e952)

    [✔] Entware Architecture arch aarch64-3.10 160


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

    [✔] Wireguard Kernel module/User Space Tools included in Firmware (Versions unidentified!)


    [✖] DNSmasq is not listening on any WireGuard interfaces 'wg*'

    [✔] firewall-start is monitoring WireGuard Firewall rules

    [✖] WAN KILL-Switch STATUS N/A (/jffs/addons/wireguard//WireGuardVPN.conf not found?)
    [✖] UDP monitor is DISABLED

    [ℹ ] Reverse Path Filtering ENABLED

    [ℹ ] Speedtest quick link https://fast.com/en/gb/

    [✔] Statistics gathering is ENABLED

     WireGuard ACTIVE Peer Status: Clients 1, Servers 1
                   ASUS GUI Peers: Clients 1, Servers 1

I deleted the GUI 'client' Peer and the import menu command seems to work...

e  = Exit Script [?]

E:Option ==> import Mullvad_Paris

    [✔] Config Mullvad_Paris import as wg11 , wgc5 success

    Peers (Auto=P - Policy, Auto=X - External i.e. Cell/Mobile)
Server  Auto  Subnet        Port   Annotate
wg21    Y     10.50.1.1/24  51820  # RT-AX86U Server #1

Client  Auto  IP               Endpoint             DNS             MTU  Annotate
wg11    N     10.67.146.14/32  103.231.88.18:51820  193.138.218.74       # Mullvad EU, Paris

and also appeared in the GUI, which I then connected.

e  = Exit Script [?]

E:Option ==> 3

    interface: wgc5                                          ***ASUS Internal GUI 'client' Peer***
        peer: 3CkVF922uY4xAZBfgRQq3U1mwr24uJlXxvLc3gsHgwA=
         latest handshake: 1 minute, 55 seconds ago
         transfer: 30.19 KiB received, 111.53 KiB sent       ***Session statistics (Duration/data transferred) N/A ***

    interface: wg21     Port:51820    10.50.1.1/24           VPN Tunnel Network    # RT-AX86U Server #1

    interface: wgs1     Port:51821    10.6.0.1/24            VPN Tunnel Network    ***ASUS Internal GUI 'server' Peer***

    interface: wg11     103.231.88.18:51820                  10.67.146.14/32       # Mullvad EU, Paris
        peer: D2ltFd7TbpYNq9PejAeGwlaJ2bEFLqOSYywdY9N5xCY=
         latest handshake: 54 seconds ago
         transfer: 1.78 MiB received, 907.64 KiB sent        0 Days, 00:33:11 from >>>>>>

     WireGuard ACTIVE Peer Status: Clients 1, Servers 1
                   ASUS GUI Peers: Clients 1, Servers 1

In summary, whilst wireguard_manager may be compatible with RC3-2, ASUS again have made strange choices in particular with the Selective Routing table names and RPDB PRIO values

i.e. single digit routing tables

e.g. Selective routing of a single LAN device

ip rule

    0:    from all lookup local
    100:    from 192.168.50.38 lookup 5
    32766:    from all lookup main
    32767:    from all lookup default

ip route show table 5

    0.0.0.0/1 dev wgc5  scope link
    default via 192.168.0.1 dev eth0
    127.0.0.0/8 dev lo  scope link
    128.0.0.0/1 dev wgc5  scope link
    192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.48
    192.168.0.1 dev eth0  proto kernel  scope link
    192.168.50.0/24 dev br0  proto kernel  scope link  src 192.168.50.1
    193.138.218.74 dev wgc5  scope link

If default is clicked in the GUI

ip rule

    0:    from all lookup local
    10000:    from all lookup 1
    32766:    from all lookup main
    32767:    from all lookup default

So there is a potential conflict i.e. ASUS use PRI=100 to PRIO=10000, with x3mrouting and wireguard_manager using RPDB PRIO 99xx thru' 99xx.

 

[ZebMcKayhan]

I've not seen any review on the WireGuard feature included by ASUS on supported AX routers, so.....

I had the opportunity to try it on a RT-AX86U running stock RC3-2 Firmware (v9.0.0.4.386_56898-ge21e952)

The 'Multiple VPN Connection' tab states 16 servers may be defined, but I suspect that total is for the mix of available clients rather than say 16 WireGuard 'client' Peers.

Along with the usual suspects PPTP,L2TP and OpenVPN in the 'VPN type' dropdown, being a long time HMA subscriber, it was a surprise/bonus to see HMA included in the firmware alongside WireGuard!

View attachment 37217

so I was able test L2TP and OpenVPN clients via HMA - and they worked.


WireGuard Peers, I was able to create both a 'server' and 'client' Peer (USA, Los Angeles) and the ASUS GUI duly created interfaces 'wgs1' and 'wgc5' respectively.

I hadn't seen the use of the WireGuard 'Pre-shared Key' option before, and IMHO there were a couple of clunky GUI issues.

The first appears to be that if you wish to set up a split tunnel say with one LAN device using the tunnel, the GUI will not allow you to add another LAN device until you terminate the 'client' Peer connection.
Probably best practice, but a little tedious considering the following dynamic command is presumambly all that is required
ip rule add from xxx.xxx.xxx.xxx table X prio x00;ip route flush cache

The second minor quibble is you can't use the Vendor supplied WireGuard configuration file as-is, you need to manually cut'n'paste the configuration into the individual GUI fields.
Not a big deal, but wouldn't it be nice if you could import the .conf directly into the GUI?

Hang on, I know a script that could do it!

Initially I was only going to add a simple command line option
e.g. '/jffs/addons/wireguard/wg_manager.sh import wireguard_configuration_file'

but since I was bored, I decided that with a little bit of tweaking, there is no reason why wireguard_manager shouldn't be able to run on stock firmware, pending @RMerlin's next firmware release based on v386_56898 or later.

NOTE: This exercise was a proof of concept, as there is no reliable '/jffs/' auto scripting etc. on stock firmware
Although there does appear to be the (circa 2019) bug where memaccess is apparently invoked/executed?!!!....success

e  = Exit Script [?]

E:Option ==> ?

    Router RT-AX86U Firmware (v9.0.0.4.386_56898-ge21e952)

    [✔] Entware Architecture arch aarch64-3.10 160


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

    [✔] Wireguard Kernel module/User Space Tools included in Firmware (Versions unidentified!)


    [✖] DNSmasq is not listening on any WireGuard interfaces 'wg*'

    [✔] firewall-start is monitoring WireGuard Firewall rules

    [✖] WAN KILL-Switch STATUS N/A (/jffs/addons/wireguard//WireGuardVPN.conf not found?)
    [✖] UDP monitor is DISABLED

    [ℹ ] Reverse Path Filtering ENABLED

    [ℹ ] Speedtest quick link https://fast.com/en/gb/

    [✔] Statistics gathering is ENABLED

     WireGuard ACTIVE Peer Status: Clients 1, Servers 1
                   ASUS GUI Peers: Clients 1, Servers 1

I deleted the GUI 'client' Peer and the import menu command seems to work...

e  = Exit Script [?]

E:Option ==> import Mullvad_Paris

    [✔] Config Mullvad_Paris import as wg11 , wgc5 success

    Peers (Auto=P - Policy, Auto=X - External i.e. Cell/Mobile)
Server  Auto  Subnet        Port   Annotate
wg21    Y     10.50.1.1/24  51820  # RT-AX86U Server #1

Client  Auto  IP               Endpoint             DNS             MTU  Annotate
wg11    N     10.67.146.14/32  103.231.88.18:51820  193.138.218.74       # Mullvad EU, Paris

and also appeared in the GUI, which I then connected.

View attachment 37218

e  = Exit Script [?]

E:Option ==> 3

    interface: wgc5                                          ***ASUS Internal GUI 'client' Peer***
        peer: 3CkVF922uY4xAZBfgRQq3U1mwr24uJlXxvLc3gsHgwA=
         latest handshake: 1 minute, 55 seconds ago
         transfer: 30.19 KiB received, 111.53 KiB sent       ***Session statistics (Duration/data transferred) N/A ***

    interface: wg21     Port:51820    10.50.1.1/24           VPN Tunnel Network    # RT-AX86U Server #1

    interface: wgs1     Port:51821    10.6.0.1/24            VPN Tunnel Network    ***ASUS Internal GUI 'server' Peer***

    interface: wg11     103.231.88.18:51820                  10.67.146.14/32       # Mullvad EU, Paris
        peer: D2ltFd7TbpYNq9PejAeGwlaJ2bEFLqOSYywdY9N5xCY=
         latest handshake: 54 seconds ago
         transfer: 1.78 MiB received, 907.64 KiB sent        0 Days, 00:33:11 from >>>>>>

     WireGuard ACTIVE Peer Status: Clients 1, Servers 1
                   ASUS GUI Peers: Clients 1, Servers 1

In summary, whilst wireguard_manager may be compatible with RC3-2, ASUS again have made strange choices in particular with the Selective Routing table names and RPDB PRIO values

i.e. single digit routing tables

e.g. Selective routing of a single LAN device

ip rule

    0:    from all lookup local
    100:    from 192.168.50.38 lookup 5
    32766:    from all lookup main
    32767:    from all lookup default

ip route show table 5

    0.0.0.0/1 dev wgc5  scope link
    default via 192.168.0.1 dev eth0
    127.0.0.0/8 dev lo  scope link
    128.0.0.0/1 dev wgc5  scope link
    192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.48
    192.168.0.1 dev eth0  proto kernel  scope link
    192.168.50.0/24 dev br0  proto kernel  scope link  src 192.168.50.1
    193.138.218.74 dev wgc5  scope link

If default is clicked in the GUI

ip rule

    0:    from all lookup local
    10000:    from all lookup 1
    32766:    from all lookup main
    32767:    from all lookup default

So there is a potential conflict i.e. ASUS use PRI=100 to PRIO=10000, with x3mrouting and wireguard_manager using RPDB PRIO 99xx thru' 99xx.

Thats really cool! So it appears that wgm might have a future after all. That makes me really glad! Altough we will have to see what magic @RMerlin could sprinkle on this.

Did you get to check if the stock Firmware also disables the flow-cache (which we have to do)? Or have they managed to make the changes needed to have the kernel modules work with the flow-cache?

Remember someone noticing limited network performance when disabling the flow-cache but can't find the message now.

//Zeb

 

[Martineau]

Did you get to check if the stock Firmware also disables the flow-cache (which we have to do)? Or have they managed to make the changes needed to have the kernel modules work with the flow-cache?

Remember someone noticing limited network performance when disabling the flow-cache but can't find the message now.

Wireguard - Session Manager - Discussion thread (CLOSED/EXPIRED Oct 2021 use http://www.snbforums.com/threads/session-manager-discussion-2nd-thread.75129/)

Here are some of my observations and input from a new install of wg_manager v4.11b3: 1. On a remote peer server I created a device peer: Device Auto IP DNS Allowed IPs Annotate MSG X 10.50.1.3/32 192.168.2.1 0.0.0.0/0 # MSG "Device" From the local PC I logged...

www.snbforums.com

Stock RT-AX86U does indeed set

fc_disable=1

 

[ZebMcKayhan]

I'm starting to feel quite ok with this content. Thinking it could be a Tutorial for beginners and might add some value for those who have imported a client peer but might be struggling with the final touch.

All the headlines does now contain something, but I have tried to stick with the most common use cases and not floated away too much to not create too much confusion.

Please have a look at:

GitHub - ZebMcKayhan/WireguardManager: Manage/Install WireGuard on applicable ASUS routers

Manage/Install WireGuard on applicable ASUS routers - ZebMcKayhan/WireguardManager

github.com

Here are the headlines:

Table of content

Setup wgm
-Import Client
-Add persistentKeepalive
-Manage Killswitch
-Change DNS/mtu/Name
-ipv6
-Check connection
-Default or Policy routing
-Create rules in WGM
-Create categories
-Geo-location
-Manage/Setup IPSETs for policy based routing
-Route WG Server to internet via WG Client

Why is Diversion not working for WG Clients

Using Yazfi and WGM to route different SSIDs to different VPNs

Setup a reverse policy based routing

Setup Transmission and/or Unbound to use WG Client

It probably reeks of spelling errors but most of the wgm command have been tested so they should be ok.

If you have any criticism (good or bad) please let me know (pm or here). You are also welcome to wish for additional headlines and I will consider it. Keep in mind that I cannot create server peers so I can only elaborate on the information available.

Enjoy!

//Zeb

 

[RMerlin]

@Martineau , would having the kernel module + userspace tools present in the firmware before the rest of the Asus implementation be of any use to you? I cannot guarantee that the kernel patches that I have at this time are fully functionnal, since Asus did most of their development on the newer RC3 branch, which might contain additional kernel patches that I currently don't have yet.

 

[Martineau]

@Martineau , would having the kernel module + userspace tools present in the firmware before the rest of the Asus implementation be of any use to you? I cannot guarantee that the kernel patches that I have at this time are fully functionnal, since Asus did most of their development on the newer RC3 branch, which might contain additional kernel patches that I currently don't have yet.

Clearly having the WireGuard modules (if not the complete ASUS GUI Peer implementation) would absolve members @Odkrys and @ZebMcKayhan from having to formally maintain/host them.

wireguard_manager happily accepts any module

e.g. RC3-2 on the RT-AX86U uses the WireGuard Kernel v20210124 (maybe the same across the other supported AX routers?)

and @ZebMcKayhan has generously compiled v20210606 for the RT-AC86U.

So, at the moment wireguard_manager does not currently allow overriding the modules if they exist in the firwmware, but I will probably provide the option for Advanced users to be able to take advantage of any 3rd-Party compiled modules, but yes the inclusion of the modules would most certainly be beneficial.

 

[RMerlin]

Clearly having the WireGuard modules (if not the complete ASUS GUI Peer implementation) would absolve members @Odkrys and @ZebMcKayhan from having to formally maintain/host them.

Ok, I'll see if it would be doable. I haven't kept track of which kernels were patched with 45581, I only tested compiling it with the RT-AX88U (but didn't confirm whether it was working at all).

 

[RMerlin]

Test builds 386.4_alpha2-g952c6bdecc contain both the kernel module and the userspace tool.

I only tested loading the module on the RT-AX88U and RT-AX86U, I didn't test any further.

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.

 

[RMerlin]

BTW, as a FYI, I know this had been debated in the past... Asus disables fc when Wireguard is enabled.

 

[ZebMcKayhan]

Has anyone attempted to run the new Alpha2 firmware with wgm?

Seeing the AX56U/AX58U in there, this would maybe be a first possible attempt to get wireguard & wgm working on these models.

@Martineau is wgm latest dev version compatible with this?

//Zeb

 

[Martineau]

Has anyone attempted to run the new Alpha2 firmware with wgm?

@Martineau is wgm latest dev version compatible with this?

What's the adage "devs don't develop on/for ALPHA" releases?

However, wireguard_manager Beta v4.12b9 on the dev Github branch should now provide the ability to override/switch-back ALPHA firmware modules if required

but it seems to work with the ALPHA...