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!

Edit: I don't know if the Entware iptables is needed - I can always remove and see if the script still works if it would help
Great. If you wouldn't mind it would be helpful, as if it is needed it may be a less attractive solution for some...
 
Great. If you wouldn't mind it would be helpful, as if it is needed it may be a less attractive solution for some...
Looks like Entware iptables is needed. Running the wgNN-up script shows
Code:
ip6tables v1.4.15: unknown option "--to"
Try `ip6tables -h' or 'ip6tables --help' for more information.
ip6tables v1.4.15: unknown option "--to"
Try `ip6tables -h' or 'ip6tables --help' for more information.
and ping 2600:: gets no echo and IPv6 connectivity is lost.

I rebooted the router after removing to see if that helped - it didn't.
 
Looks like Entware iptables is needed. Running the wgNN-up script shows
Code:
ip6tables v1.4.15: unknown option "--to"
Try `ip6tables -h' or 'ip6tables --help' for more information.
ip6tables v1.4.15: unknown option "--to"
Try `ip6tables -h' or 'ip6tables --help' for more information.
and ping 2600:: gets no echo and IPv6 connectivity is lost.

I rebooted the router after removing to see if that helped - it didn't.
Thanks for the test. Yep, Thats what I thought, ASUS only patched ip6tables for MASQUARADING and not for SNAT, DNAT, NETMAP (and probably others) extensions. But good news that netfilter supports it so we can use entware iptables which I have yet not found any drawbacks (dont meant there isnt any).

ASUS just recently added ipv6 server support but unclear if that is only local connection, atleast that is how I enterpret it. Don't know how much of latest public beta is included in Merlin 386.5 and if further implementations could be expected. Time will tell. NETMAP is a better alternative then MASQUARADE since the 1:1 translation makes your server device recieve icmp6 package flow messages and you should have a better experience.

I'll update my github page with this info.
 
Thanks for the test. Yep, Thats what I thought, ASUS only patched ip6tables for MASQUARADING and not for SNAT, DNAT, NETMAP (and probably others) extensions. But good news that netfilter supports it so we can use entware iptables which I have yet not found any drawbacks (dont meant there isnt any).

ASUS just recently added ipv6 server support but unclear if that is only local connection, atleast that is how I enterpret it. Don't know how much of latest public beta is included in Merlin 386.5 and if further implementations could be expected. Time will tell. NETMAP is a better alternative then MASQUARADE since the 1:1 translation makes your server device recieve icmp6 package flow messages and you should have a better experience.

I'll update my github page with this info.
If you are referring to adding IPv6 support to the OpenVPN server, then I don't think that is the same issue. That fully supports dual stack from standard OpenVPN clients (have tested android on my phone and windows on my laptop) without any additional scripts, the only issue I am aware of there is trying to connect with the asuswrt client from another Asus router as noted here https://www.snbforums.com/threads/asuswrt-merlin-386-5-is-now-available.77691/post-753921
 
If you are referring to adding IPv6 support to the OpenVPN server, then I don't think that is the same issue. That fully supports dual stack from standard OpenVPN clients (have tested android on my phone and windows on my laptop) without any additional scripts, the only issue I am aware of there is trying to connect with the asuswrt client from another Asus router as noted here https://www.snbforums.com/threads/asuswrt-merlin-386-5-is-now-available.77691/post-753921
Well, now I had to look it up again. It was the 386.4 change log from @RMerlin
- NEW: IPv6 support for OpenVPN server. Allows to remotely connect to your router's OpenVPN server over IPv6, and reach LAN clients over their IPv6 (redirecting IPv6 Internet traffic does not work).


And I can't find any more recent updates telling otherwise.
 
@Martineau
Now that we have ipv4+ipv6 client and server. How is the passthru command working with this? Is it possible to passthru a dual stack server client peer to a dual stack internet client peer?
 
@Martineau
I wanted to create an IPv4 only server for testing (I have a dual stack setup on the router)

If I run peer new I had expected an IPv4 only setup but i see
Code:
E:Option ==> peer new

        Press y to Create (IPv6) 'server' Peer (wg23) 10.50.3.1/24:11503 or press [Enter] to SKIP.
y
        Creating WireGuard Private/Public key-pair for (IPv6) 'server' Peer wg23 on RT-AX88U (v386.5_2)
        Press y to Start (IPv6) 'server' Peer (wg23) or press [Enter] to SKIP.
y

        Requesting WireGuard VPN Peer start (wg23)
and when I create a device the device.conf (sam23.conf) contains
Code:
# sam23
[Interface]
PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
Address = 10.50.3.2/32
DNS = 10.50.3.1,2620:119:35::35

# RT-AX88U (IPv6) 'server' (wg23)
[Peer]
PublicKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
AllowedIPs = 0.0.0.0/0, ::/0     # ALL Traffic
# DDNS yyyyyyyy.asuscomm.com
Endpoint = dancingb.asuscomm.com:11503
PresharedKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
PersistentKeepalive = 25
# sam23 End

I assume that IPv6 in the initial setup should be IPv4, but should the device.conf contain an IPv6 DNS and IP range?
 
@Martineau
I wanted to create an IPv4 only server for testing (I have a dual stack setup on the router)

If I run peer new I had expected an IPv4 only setup but i see
Code:
E:Option ==> peer new

        Press y to Create (IPv6) 'server' Peer (wg23) 10.50.3.1/24:11503 or press [Enter] to SKIP.
y
        Creating WireGuard Private/Public key-pair for (IPv6) 'server' Peer wg23 on RT-AX88U (v386.5_2)
        Press y to Start (IPv6) 'server' Peer (wg23) or press [Enter] to SKIP.
y

        Requesting WireGuard VPN Peer start (wg23)
and when I create a device the device.conf (sam23.conf) contains
Code:
# sam23
[Interface]
PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
Address = 10.50.3.2/32
DNS = 10.50.3.1,2620:119:35::35

# RT-AX88U (IPv6) 'server' (wg23)
[Peer]
PublicKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
AllowedIPs = 0.0.0.0/0, ::/0     # ALL Traffic
# DDNS yyyyyyyy.asuscomm.com
Endpoint = dancingb.asuscomm.com:11503
PresharedKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
PersistentKeepalive = 25
# sam23 End

I assume that IPv6 in the initial setup should be IPv4, but should the device.conf contain an IPv6 DNS and IP range?
Whilst it looks (logically) ugly, I don't think it actually impacts the Road-Warrior 'device' Peer?

i.e. I have always assumed that the Road-Warrior 'device' Peer such as a mobile phone is IPv6 capable and as such the following directive is the standard acceptable default
Bash:
AllowedIPs = 0.0.0.0/0, ::/0    # ALL traffic
Similarly for the DNS, if an IPv6 DNS server is defined on the host IPv6 'server' Peer environment , then the Road-Warrior 'device Peer should have the option to use it or not ( more than likely not on Android?).

However, since IPv6 is still in its infancy (on ASUS routers), it is probably prudent to err on the side of the lowest common (working) denominator IPv4, so if you want IPv6 WireGuard Peers (even if IPv6 is fully configured on the router), for the time being, you must now explicitly specify the ipv6 directive for both the WireGuard 'server' and 'client' Peer creation request.

I have uploaded wireguard_manager Beta v4.16b9
To apply the patch use
Code:
e  = Exit Script [?]

E:Option ==> uf dev
 
Last edited:
i.e. I have always assumed that the Road-Warrior 'device' Peer such as a mobile phone is IPv6 capable and as such the following directive is the standard acceptable default
Bash:
AllowedIPs = 0.0.0.0/0, ::/0 # ALL traffic
if the android is ipv6 capable and currently connected to an ipv6 network/internet would having an ipv4 wireguard server in combination with
Code:
AllowedIPs = 0.0.0.0/0
risk of not changing ipv6 standard route in phone and ipv6 data still going outside vpn?

was thinking that the entry shifted the default route to Wireguard and if there is no ipv6 capable connection there, ipv6 will be broken and ipv4 only used (as intended).

if I'm reading this right, wg-quick is using AllowedIPs to setup routes:
Code:
for i in $(while read -r _ i; do for i in $i; do [[ $i =~ ^[0-9a-z:.]+/[0-9]+$ ]] && echo "$i"; done; done < <(wg show "$INTERFACE" allowed-ips) | sort -nr -k 2 -t /); do
        add_route "$i"
    done

Or maybe I'm just wrong and got this all backwards?
 
if the android is ipv6 capable and currently connected to an ipv6 network/internet would having an ipv4 wireguard server in combination with
Code:
AllowedIPs = 0.0.0.0/0
risk of not changing ipv6 standard route in phone and ipv6 data still going outside vpn?

was thinking that the entry shifted the default route to Wireguard and if there is no ipv6 capable connection there, ipv6 will be broken and ipv4 only used (as intended).

if I'm reading this right, wg-quick is using AllowedIPs to setup routes:
Code:
for i in $(while read -r _ i; do for i in $i; do [[ $i =~ ^[0-9a-z:.]+/[0-9]+$ ]] && echo "$i"; done; done < <(wg show "$INTERFACE" allowed-ips) | sort -nr -k 2 -t /); do
        add_route "$i"
    done

Or maybe I'm just wrong and got this all backwards?
I was not saying it was wrong, I was just asking why and I can see the logic of including ::/0. What I was less certain about was whether for an IPv4 server the routers IPv6 DNS servers need to be referenced or whether those requests could/should be routed through the allocated IPV4 DNS server.

As it stands the IPv4 DNS points to the root IPv4 config (though this may be because I am using DOT and have blanked out the standard DNS servers), but the IPv6 DNS points to those setup in the IPv6 config tab.

I think I will need to do some manual edits to the server and device.conf files to see what happens if I add/remove IPv6 routing and DNS and what happens if I repopulate the server DNS.

The starting point is that when I have my phone connected over WireGuard and then go to Browserleaks it shows the phones IP address as the Router WAN for IPv4 and the WanIPv6::100:2 for IPv6stop wg21 and WebRTC shows both of these plus the expected VPN addresses (10.50.2.1 and modified ULA::100:2) and I am wondering if this is right. Technically I am not revealing my phone's details if it is not directly on the LAN but it still seems odd.
 
I think I will need to do some manual edits to the server and device.conf files to see what happens if I add/remove IPv6 routing and DNS and what happens if I repopulate the server DNS.
Well, I propose, in my guide, that it is good idea to always look into the device config and check Endpoint, DNS and such. Wgm would be far to complex to use if it account for all cases. Please report you findings regarding AllowedIPs here.

The starting point is that when I have my phone connected over WireGuard and then go to Browserleaks it shows the phones IP address as the Router WAN for IPv4 and the WanIPv6::100:2 for IPv6stop wg21 and WebRTC shows both of these plus the expected VPN addresses (10.50.2.1 and modified ULA::100:2) and I am wondering if this is right. Technically I am not revealing my phone's details if it is not directly on the LAN but it still seems odd.
This all sounds as it is working as intended. WebRTC is able to request your device ip from the device, that's why you are seing what you are. Use a browser that blocks webRTC if you like to hide it (don't know for android)
 
Similarly for the DNS, if an IPv6 DNS server is defined on the host IPv6 'server' Peer environment , then the Road-Warrior 'device Peer should have the option to use it or not ( more than likely not on Android?).

However, since IPv6 is still in its infancy (on ASUS routers), it is probably prudent to err on the side of the lowest common (working) denominator IPv4, so if you want IPv6 WireGuard Peers (even if IPv6 is fully configured on the router), for the time being, you must now explicitly specify the ipv6 directive for both the WireGuard 'server' and 'client' Peer creation request.
This is why I think Asus is taking their time (dragging their feet?) with WireGuard - it'll probably force a not insignificant re-do of their firmware, one they may not be ready to undertake or that will break some of their other functionality (AiMesh, maybe?)
I see an opportunity for you here: beat them to the punch, show 'em how to do it. You've got the DNS server part handled with unbound, now extend privacy/security around these routers with WireGuard. As I understand it (and I'm quite likely gravely mistaken), these two things are fundamental stumbling blocks to how they've been applying things and you can choose to discard what's irrelevant/antiquated and make shiny-new-modern-cutting edge without having to answer to marketing depts...if you want. I have faith in your abilities to fork forward. Or you can straighten my bent thinking at your convenience.
 
I was not saying it was wrong, I was just asking why and I can see the logic of including ::/0.
So running Dual-Stack IPv4+IPv6 on the router, when creating the Road-Warrior 'device' Peer you can decide to choose between
Code:
                                'server Peer'

                IPv4 Only           IPv6 Only              IPv4+IPv6
    
    
    AllowedIPs  0.0.0.0/0           ::/0                    0.0.0.0/0,::/0
                0.0.0.0/0,::/0      0.0.0.0/0,::/0            ::/0
                ::/0 ?              0.0.0.0/0 ?             0.0.0.0/0
                nnn.nnn.nnn.nnn/24  xxxx:xxxx:xxxx::/64     nnn.nnn.nnn.nnn/24,xxx:xxxx:xxxx::/64

....even if some are clearly illogical.

So wireguard_manager could attempt to assist with auto-creating the necessary config on the Road-Warrior device, but not having IPv6 I can't really test.

i.e. is '0.0.0.0/0,::/0' explicitly required to allow encapsulated IPv6_in_IPv4, or does 0.0.0.0/0 suffice?

For the DNS, again it depends on what you need/expect....'Advertise or not' vs. Public/Private etc.
 
So running Dual-Stack IPv4+IPv6 on the router, when creating the Road-Warrior 'device' Peer you can decide to choose between
Code:
                                'server Peer'

                IPv4 Only           IPv6 Only              IPv4+IPv6
   
   
    AllowedIPs  0.0.0.0/0           ::/0                    0.0.0.0/0,::/0
                0.0.0.0/0,::/0      0.0.0.0/0,::/0            ::/0
                ::/0 ?              0.0.0.0/0 ?             0.0.0.0/0
                nnn.nnn.nnn.nnn/24  xxxx:xxxx:xxxx::/64     nnn.nnn.nnn.nnn/24,xxx:xxxx:xxxx::/64

....even if some are clearly illogical.

So wireguard_manager could attempt to assist with auto-creating the necessary config on the Road-Warrior device, but not having IPv6 I can't really test.

i.e. is '0.0.0.0/0,::/0' explicitly required to allow encapsulated IPv6_in_IPv4, or does 0.0.0.0/0 suffice?

For the DNS, again it depends on what you need/expect....'Advertise or not' vs. Public/Private etc.
It would seem that 0.0.0.0/0,::/0 is probably the easiest option. Having had a look around it seem that Allowed IPs refers to the address ranges entering the tunnel. so while I have no direct experience of 6to4 tunnels, the aim is to route internal IPv6 addresses across an IPv4 network, so the local addresses would be IPv6 (presumably ULA subnets) and therefore adding ::/0 would be correct. So presumably if you want to restrict the local address that can access or be accessed over WireGuard by a particular remote peer, you can create a defined subnet (or subnets) to do just that.
 
I was not saying it was wrong, I was just asking why and I can see the logic of including ::/0. What I was less certain about was whether for an IPv4 server the routers IPv6 DNS servers need to be referenced or whether those requests could/should be routed through the allocated IPV4 DNS server.

As it stands the IPv4 DNS points to the root IPv4 config (though this may be because I am using DOT and have blanked out the standard DNS servers), but the IPv6 DNS points to those setup in the IPv6 config tab.

I think I will need to do some manual edits to the server and device.conf files to see what happens if I add/remove IPv6 routing and DNS and what happens if I repopulate the server DNS.

The starting point is that when I have my phone connected over WireGuard and then go to Browserleaks it shows the phones IP address as the Router WAN for IPv4 and the WanIPv6::100:2 for IPv6stop wg21 and WebRTC shows both of these plus the expected VPN addresses (10.50.2.1 and modified ULA::100:2) and I am wondering if this is right. Technically I am not revealing my phone's details if it is not directly on the LAN but it still seems odd.
A few observations, nothing very earth-shattering.

My starting setup is dual stacked with WAN: Connect to DNS Server: No, DNS Servers: empty and DNS Privacy Protocol: DOT, Strict
IPv6: Connect to DNS Server automatically: Disable
and using OpenDNS (Cisco) servers (you cannot have both IPv6 DNS servers empty). I am also using Unbound for DNS

As a result if I create a tunnel with say 10.50.1.1/24 then, because WAN DNS fields are empty, 10.50.1.1 will be the default IPv4 DNS in the device.conf, [Interface] DNS field. As the IPv6 DNS fields are not empty, the first IPV6 DNS server address will be added to device.conf, [Interface] DNS, if the WireGuard server is dual stack.

Disabling IPv6 on the router had no real effect apart from noting that I also need to remove the IPv6 support from Unbound or it gets very unhappy. What I did notice was that with an IPv4 only wg/peer setup that if I left the WAN DNS empty then diversion worked on the phone and if added DNS servers it did not. I also got the same result if I blanked the WAN DNS, but edited the WAN DNS on the device.conf on the phone to point to an external DNS server. I had previously noted that on dual stack diversion was not working.

Following this logic, I edited the ipv6 DNS to point to the wg server address root and re-enabled IPv6 on the router and, as hoped, diversion was working again.

Short version: To get diversion to work on the remote device I need to set the device.conf to the root of the selected IPs
So if I have wg21
Subnet 10.50.1.1/24,aa36:7ef1:xxxx:yyyy:100::1/120
then I want the device.conf [Interface] DNS set to
DNS 10.50.1.1,aa36:7ef1:xxxx:yyyy:100::1
The the same might apply to other router based DNS add-blockers, but I have not tested this.
 
A few observations, nothing very earth-shattering.

My starting setup is dual stacked with WAN: Connect to DNS Server: No, DNS Servers: empty and DNS Privacy Protocol: DOT, Strict
IPv6: Connect to DNS Server automatically: Disable
and using OpenDNS (Cisco) servers (you cannot have both IPv6 DNS servers empty). I am also using Unbound for DNS

As a result if I create a tunnel with say 10.50.1.1/24 then, because WAN DNS fields are empty, 10.50.1.1 will be the default IPv4 DNS in the device.conf, [Interface] DNS field. As the IPv6 DNS fields are not empty, the first IPV6 DNS server address will be added to device.conf, [Interface] DNS, if the WireGuard server is dual stack.

Disabling IPv6 on the router had no real effect apart from noting that I also need to remove the IPv6 support from Unbound or it gets very unhappy. What I did notice was that with an IPv4 only wg/peer setup that if I left the WAN DNS empty then diversion worked on the phone and if added DNS servers it did not. I also got the same result if I blanked the WAN DNS, but edited the WAN DNS on the device.conf on the phone to point to an external DNS server. I had previously noted that on dual stack diversion was not working.

Following this logic, I edited the ipv6 DNS to point to the wg server address root and re-enabled IPv6 on the router and, as hoped, diversion was working again.

Short version: To get diversion to work on the remote device I need to set the device.conf to the root of the selected IPs
So if I have wg21

then I want the device.conf [Interface] DNS set to

The the same might apply to other router based DNS add-blockers, but I have not tested this.

If you've read through the wg server part on my github it would have saved you the trouble:
One important thing that should/could be checked and/or changed is the DNS we are telling our VPN device to use:

DNS = 9.9.9.9, 2620:fe::fe

This line is probably populated with your WAN DNS. Now, if you feel that this is good, then just leave it. For some people, they might want to use the router as DNS to use dnsmasq with all the benefits (local hosts resolv, Diversion, Unbound et.c.). then simply change this to point at your wg21 IP instead. i.e. from my dynamic example above:

DNS = 192.168.100.1, fc00:192:168:100::1

But anyhow, the self learned experience are indeed the best ones!
 
@ZebMcKayhan , a minor word of warning in your example…Many Cable Modems (at least in the US) use 192.168.100.1 as their self assigned IP address.
 
@ZebMcKayhan , a minor word of warning in your example…Many Cable Modems (at least in the US) use 192.168.100.1 as their self assigned IP address.
Thanks, yea and some use the 10.0.0.0/8 range and mine seems to be on 172.16.0.0/12 range. ASUS sometimes uses 192.168.50.1 for br0 and sometimes 192.168.1.1 whatever address I choose it will probably conflict somewhere to someone....
Hence my preface:
https://github.com/ZebMcKayhan/WireguardManager/blob/main/README.md#preface
This guide is written for the purpose of aiding users in setting up Wireguard Session Manager on their ASUS router. When it comes to setting up Wgm, the guide serves as informational and also as a command reference. However, some of the examples may not always be applicable for your specific system. You are advised to read the text to understand what different parts do and adopt each command to suite your system.

Following all parts of this guide as-is may cause conflicts in your system as many parts are stand alone demonstrative examples.

With that said, Congratulations on your choice of setting up Wireguard and Wireguard Session Manager. I hope this guide will serve you well and provide a hazzle free setup of Wireguard on your ASUS router.

If my ISP used 192.168.0.0/16 addresses I would probably consider switching my LAN to 10.0.0.0/8 range just to be able to have a /16 network to work with for br0, GuestWifi's, WireguardServers and such, as some of my rules depends on this to work to redirect packets TO other subnets to the main routing table. System will eventually become pretty messy if I had to individually steer different subnets to Main routing table.

I'm open to suggestions if you have a an idea how to make it better.

//Zeb
 
I'm open to suggestions if you have a an idea how to make it better.

//Zeb
I hear you, you can't win :)

Look at this mash:


I think your warning is fine!
 

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