Wireguard Session Manager - Discussion (2nd) thread

[Swistheater]

Only appears to have been previously experienced/reported by RT-AX88U owners?

Not sure if/when/how it got fixed, but whilst the WireGuard kernel module may have changed, there are several users successfully running WireGuard on RT-AX88U.

Perhaps a simple reboot will fix it?

Help replacing OpenVPN with Wireguard on Asus RT-AX88U

Hello I just realized that with OpenVPN I was getting limited speeds. I only had 160 mbps service until today I upgraded to 500 mbps. If I use my VPN I only get 200 mbps and if I disconnect I am getting 500 mbps. I am using Torguard as my VPN provided and wanted to install wireguard but wasn't...

www.snbforums.com

BTW @Martineau , you shouldn't parse "nvram get innerver" for the current routers firmware version because this value only changes every factory reset, not every update.

"nvram get innerver" value carried over from ALPHA to STABLE

"nvram get innerver" value carried over from ALPHA to STABLE. Firmware reports 386.4 (I just switched to stable), but "nvram get innerver" reports innerver=3.0.0.4.386.4_alpha1-g8f4afe6890

www.snbforums.com

 

[Swistheater]

Unlike the OpenVPN Endpoint, there is no mechanism (that I have found) that allows the WireGuard Endpoint to interrogate/pass-on/react to any form of environment configuration/feature ....dhcp-option or otherwise.

In fact, you can't guarantee/deduce that the WireGuard Endpoint is even capable of responding to DNS requests locally - particularly relevant to Mullvad Endpoints etc.

I concurr, the only thing you can do with wiregaurd is control what gets "allowed". You can individually allow a /32 or /128 address, or you can pass the whole subnet /24, and ,/64.

 

[Martineau]

BTW @Martineau , you shouldn't parse "nvram get innerver" for the current routers firmware version because this value only changes every factory reset, not every update.

"nvram get innerver" value carried over from ALPHA to STABLE

"nvram get innerver" value carried over from ALPHA to STABLE. Firmware reports 386.4 (I just switched to stable), but "nvram get innerver" reports innerver=3.0.0.4.386.4_alpha1-g8f4afe6890

www.snbforums.com

I don't

However, back in Nov 2021, I tested wireguard_manager Beta v4.12b running stock RC3-2 Firmware (v9.0.0.4.386_56898-ge21e952), and to prove I really was on stock, reported the build number from innerver as updated by ASUS.

Wireguard - Session Manager - Discussion (2nd) thread

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

www.snbforums.com

I also found when @RMerlin Alpha(s) were available I could differentiate between them by continuing to extract innerver

I reverted back to using buildno/extendno once the Alphas were over.

 

[ZebMcKayhan]

Hopefully the new command options should cover most of your custom requirements, and should be self-explanatory.

• Home location will use tunnel IP 10.10.10.99 and thus Cabin will be assigned +1 i.e. 10.10.10.100
• Home location will Listen on Port 54321 and thus Cabin will Listen on Port +1 i.e. 54322
• Cabin LAN is 192.168.111.0, and if allowedips= is not specified; allowedips=192.168.111.0/24 will be used

Trying to write something about site-2-site and got me thinking. what if you want SiteB to access internet primarily through SiteA (or vice-versa)?
for SiteB to access internet through SiteA could you set

allowedips=0.0.0.0/0

or whould that break things?

//Zeb

 

[Martineau]

Trying to write something about site-2-site and got me thinking. what if you want SiteB to access internet primarily through SiteA (or vice-versa)?
for SiteB to access internet through SiteA could you set

allowedips=0.0.0.0/0

or whould that break things?

//Zeb

I could be wrong, but simply changing the allowed IPs range wouldn't provide the feature?, you would probably have to manually exploit "Selective Routing" on SiteB, either using WireGuard's fwmark feature or the current RPDB method for the 'server' Peer.

 

[ZebMcKayhan]

Added a Site-2-Site section.

I deliberately have left out the creation of Road-Warrior devices in site2site servers to not make the text too confusing, trying to stick with the basics.

WireguardManager/README.md at main · ZebMcKayhan/WireguardManager

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

github.com

//Zeb

 

[Martineau]

Added a Site-2-Site section.

I deliberately have left out the creation of Road-Warrior devices in site2site servers to not make the text too confusing, trying to stick with the basics.

WireguardManager/README.md at main · ZebMcKayhan/WireguardManager

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

github.com

You have already spent far too much time documenting the nuances of my shoddy script - but appreciated!

Whilst the new Site-to-Site section is extremely comprehensive, I have made a minor tweak in wireguard_manager Beta v4.15b

Effectively the creation/import of a 'Site-to-Site' Peer now has its own auto-start flag applied as appropriate.

e  = Exit Script [?]

E:Option ==> import Cabin type=server

    [✔] Config Cabin import as wg21 Site-to-Site (FORCED as 'server') success


    Peers (Auto start: Auto=P - Policy, Auto=S - Site-to-Site)
Server  Auto  Subnet        Port   Annotate
wg21    S     10.9.8.2/32   61821  # Cabin - 192.168.51.0/24

This seemingly cosmetic change eliminates the need to explicitly invoke the peer Cabin auto=Y command, although it is still perfectly valid and achieves the same effect.

I admit that this tweak may be contentious, given a standard import leaves auto=N, but I suspect a Site-to-Site configuration would warrant this change.

 

[ZebMcKayhan]

ou have already spent far too much time documenting the nuances of my shoddy script - but appreciated!

just glad to be of assistance. hoping it to render less repeated questions here and a smaller gap for them starting to use it. it also came really handy when I accidently removed wgm to serve as a command reference and a reminder of all crazy stuff Ive been trying to pull. got me back to the same setup in no time. so time well spent I would say.
I'm extremly pleased in how my setup works right now, cant wait for my ipv6 public ip so I can start working out dual stack server with the udp tunnel over ipv6 (altough I dont have mobile ipv6 service, but I get it if I run Wireguard.... dueh )

Effectively the creation/import of a 'Site-to-Site' Peer now has its own auto-start flag applied as appropriate.

so a site-2-site server peer has auto=S/N instead of Y/N ? and auto-sets to S (Y) after import?

so to toggle it, while keeping the same nomenclature:

peer Cabin auto=S
peer Cabin auto=N

if that is correct I could add it as informational instead.

 

[Martineau]

so a site-2-site server peer has auto=S/N instead of Y/N ? and auto-sets to S (Y) after import?

so to toggle it, while keeping the same nomenclature:

peer Cabin auto=S
peer Cabin auto=N

if that is correct I could add it as informational instead.

Basically yes....i.e. the option is there to set the Site-to-Site 'server' Peer auto=N, but the wg_server script might not then execute the correct logic if auto=Y was inadvertently reapplied instead of auto=S but it really all depends what I need/want to implement such as your query regarding forcing one Endpoint outbound via its Site-to-Site sibling Peer etc.

 

[JGrana]

You have already spent far too much time documenting the nuances of my shoddy script - but appreciated!

Whilst the new Site-to-Site section is extremely comprehensive, I have made a minor tweak in wireguard_manager Beta v4.15b

Effectively the creation/import of a 'Site-to-Site' Peer now has its own auto-start flag applied as appropriate.

e  = Exit Script [?]

E:Option ==> import Cabin type=server

    [✔] Config Cabin import as wg21 Site-to-Site (FORCED as 'server') success


    Peers (Auto start: Auto=P - Policy, Auto=S - Site-to-Site)
Server  Auto  Subnet        Port   Annotate
wg21    S     10.9.8.2/32   61821  # Cabin - 192.168.51.0/24

This seemingly cosmetic change eliminates the need to explicitly invoke the peer Cabin auto=Y command, although it is still perfectly valid and achieves the same effect.

I admit that this tweak may be contentious, given a standard import leaves auto=N, but I suspect a Site-to-Site configuration would warrant this change.

I think this is a great idea! I have done the

peer Cabin auto=y

so many times in testing it's almost become second nature.
Right now, both sites are auto=Y. Do you recommend I re-import (after uf dev) and let it set to S?
Also, the time when doing the

list

command shows off number:

E:Option ==> list

        interface: wg22  Port:61821     10.9.8.2/32                     VPN Tunnel Network      # Cabin - 192.168.2.0/24
                peer: VXlOz/BkxGWpYbvqVzDjz7tl/QkZkADrmpq07AT8FCM=      10.9.8.1/32             # Home - 192.168.1.0/24
                 latest handshake: 52 seconds ago
                 transfer: 22.42 MiB received, 136.04 MiB sent          19018 days 20:39:56 from 1643229596

It showed this with all the versions so far. I'm running 4.15b at the moment.

 

[Martineau]

I have done the

peer Cabin auto=y

so many times in testing it's almost become second nature.
Right now, both sites are auto=Y. Do you recommend I re-import (after uf dev) and let it set to S?

Changing auto=S will (for the time being at least) simply be purely cosmetic - only noticeable when issuing peer

Also, the time when doing the

list

command shows off number:

E:Option ==> list

        interface: wg22  Port:61821     10.9.8.2/32                     VPN Tunnel Network      # Cabin - 192.168.2.0/24
                peer: VXlOz/BkxGWpYbvqVzDjz7tl/QkZkADrmpq07AT8FCM=      10.9.8.1/32             # Home - 192.168.1.0/24
                 latest handshake: 52 seconds ago
                 transfer: 22.42 MiB received, 136.04 MiB sent          19018 days 20:39:56 from 1643229596

Could you see if the following command alters the incorrect duration display when issued on the Cabin site

TS=$(date +%s);sqlite3 /opt/etc/wireguard.d/WireGuard.db "INSERT into traffic values('wg22','$TS','0','0','0','0');"

 

[JGrana]

Could you see if the following command alters the incorrect duration display when issued on the Cabin site

TS=$(date +%s);sqlite3 /opt/etc/wireguard.d/WireGuard.db "INSERT into traffic values('wg22','$TS','0','0','0','0');"

Issued the command. No, it's still this:

19018 days 22:27:21 from 1643236041

If it helps any, this is $TS:

1643236029

 

[Martineau]

Issued the command. No, it's still this:

19018 days 22:27:21 from 1643236041

If it helps any, this is $TS:

1643236029

Can you try

TS=$(date +%s);sqlite3 /opt/etc/wireguard.d/WireGuard.db "INSERT into traffic values('wg21','$TS','*','*','*','*');"

then post the output of

sqlite3 /opt/etc/wireguard.d/WireGuard.db "SELECT * FROM traffic WHERE peer='wg21';"

 

[JGrana]

Can you try

TS=$(date +%s);sqlite3 /opt/etc/wireguard.d/WireGuard.db "INSERT into traffic values('wg21','$TS','*','*','*','*');"

then post the output of

sqlite3 /opt/etc/wireguard.d/WireGuard.db "SELECT * FROM traffic WHERE peer='wg21';"

Here is the output. I ran the commands twice. Looks like I now have 2 in the database...

sqlite3 /opt/etc/wireguard.d/WireGuard.db "SELECT * FROM traffic WHERE peer='wg21';"
wg21|1643282732|*|*|*|*
wg21|1643282795|*|*|*|*

 

[Martineau]

Here is the output. I ran the commands twice. Looks like I now have 2 in the database...

sqlite3 /opt/etc/wireguard.d/WireGuard.db "SELECT * FROM traffic WHERE peer='wg21';"
wg21|1643282732|*|*|*|*
wg21|1643282795|*|*|*|*

Hmmm, it's a pity I can't remember what I coded ...could have sworn that I needed to seed the database with either '0' or '*' but I can't replicate your issue here.

OK, if you have time, could you please provide a debug trace:

e  = Exit Script [?]

E:Option ==> debug

e  = Exit Script [?]

E:Debug mode enabledOption ==> list

and PM the debugging trace output which should be about 250-300 lines.

NOTE: If you wish you may redact the Public key etc.

 

[JGrana]

Done. Thanks!

 

[Martineau]

Done. Thanks!

Many thanks for the debugging trace

Not sure if this a quick fix....and it will only stand a chance if you do actually have the 'Home' and 'Cabin' Peers appearing in the output from the peer command under the devices column.

On local Home

TS=$(date +%s);sqlite3 /opt/etc/wireguard.d/WireGuard.db "UPDATE devices SET conntrack='$TS' WHERE name='Cabin';"

On remote Cabin

TS=$(date +%s);sqlite3 /opt/etc/wireguard.d/WireGuard.db "UPDATE devices SET conntrack='$TS' WHERE name='Home';"

 

[JGrana]

Many thanks for the debugging trace

Not sure if this a quick fix....and it will only stand a chance if you do actually have the 'Home' and 'Cabin' Peers appearing in the output from the peer command under the devices column.

On local Home

TS=$(date +%s);sqlite3 /opt/etc/wireguard.d/WireGuard.db "UPDATE devices SET conntrack='$TS' WHERE name='Cabin';"

On remote Cabin

TS=$(date +%s);sqlite3 /opt/etc/wireguard.d/WireGuard.db "UPDATE devices SET conntrack='$TS' WHERE name='Home';"

I had the tunnel up and running. Did the two commands on the local/remote.

Local has always had correct uptime. Even after the two commands, remote still shows odd time:

19019 days 17:05:39 from 1643303139

Another data point - maybe I did not configure the remote correctly? I did an import with type=server on remote.

When I run peer on remote, it only shows this (it's done this since initial 14.X)

E:Option ==> peer

        Peers (Auto start: Auto=P - Policy, Auto=S - Site-to-Site)
Server  Auto  Subnet       Port   Annotate
wg22    Y     10.9.8.2/32  61821  # Cabin - 192.168.2.0/24


        Peers (Auto=X - External i.e. Cell/Mobile/Site)

        WireGuard ACTIVE Peer Status: Clients 0, Servers 1

On the local machine (Home) it shows this running the peer command:

E:Option ==> peer

        Peers (Auto start: Auto=P - Policy, Auto=S - Site-to-Site)
Server  Auto  Subnet       Port   Annotate
wg21    Y     10.9.8.1/32  61820  # Home - 192.168.1.0/24


        Peers (Auto=X - External i.e. Cell/Mobile/Site)
Device    Auto  IP           DNS           Allowed IPs                  Annotate
SiteB     X     10.9.8.2/32                10.9.8.1/32, 192.168.1.0/24  # SiteB Site-to-Site LAN 192.168.2.0/24
Cabin     X     10.9.8.2/32                10.9.8.1/32, 192.168.1.0/24  # Cabin Site-to-Site LAN 192.168.2.0/24
iphone13  X     10.9.8.3/32  209.18.47.62  0.0.0.0/0                    # iphone13 "Device"

As you can see, I did add a mobile client. ;-)

 

[Martineau]

On the local machine (Home) it shows this running the peer command:

E:Option ==> peer

        Peers (Auto start: Auto=P - Policy, Auto=S - Site-to-Site)
Server  Auto  Subnet       Port   Annotate
wg21    Y     10.9.8.1/32  61820  # Home - 192.168.1.0/24


        Peers (Auto=X - External i.e. Cell/Mobile/Site)
Device    Auto  IP           DNS           Allowed IPs                  Annotate
SiteB     X     10.9.8.2/32                10.9.8.1/32, 192.168.1.0/24  # SiteB Site-to-Site LAN 192.168.2.0/24
Cabin     X     10.9.8.2/32                10.9.8.1/32, 192.168.1.0/24  # Cabin Site-to-Site LAN 192.168.2.0/24
iphone13  X     10.9.8.3/32  209.18.47.62  0.0.0.0/0                    # iphone13 "Device"

On Home, external site Cabin has been automagically 'imported'.....so

On Cabin, try

e  = Exit Script [?]

E:Option ==> import Home type=device

As you can see, I did add a mobile client. ;-)

I assume it works?

 

[ZebMcKayhan]

E:Option ==> import Home type=device

Sorry to chip in, but would this require you to copy Home.conf to the remote peer? As it is not in the list of files to copy over, or is this command not requiring this?