Wireguard Session Manager - Discussion (2nd) thread

[ZebMcKayhan]

This is a big deal, being able to follow ISP-initiated WAN IP changes - it (if I understand things correctly) does away with needing to set up DDNS tunneling, and maybe even FQDNs with HTTPS certs. Possibly (and this is a stretch) get out from behind IPv4 CGNAT

I don't really follow you, but if you say so.

You will still need your router gua as an Endpoint for your wireguard device peer.

I'm just not sure how you've accomplished making this change, where in the router GUI to find it; by selecting/configuring Native IPv6, I don't get the option: it auto-populates...I may be missing something. Is it a command line thing, why you've added scripts? (the thought occurred when reading the github that anyone with a /48 should know how to amend the scripts themselves if they've come this far) (it's not the best time of day for me to use my brain on this stuff)

My setup is maybee not representative. I don't have ipv6 wan at all. But I get ipv6 connection via my Wireguard internet client. So I flipped the ipv6 switch, and turned of dhcp-pd (as there is no one there that deligates any prefix). When turning this off you get to specify your lan ip yourself. Thats where I entered my private ipv6.
I tried to use the same prefix as my wireguard client, but it didn't work. Apparently I only get a single ipv6 address (sigh) so I used ipv6 masquarading included in 386.4 and later. It works. No scripting involved other then adding the masquarading rule in wgm custom scripts.

I also setup YazFi to give another ipv6 subnet to guest wifi and masquaraded this to my other wireguard client. Also works but requires more scripting, but its all on my github.

I don't really see any advantage in running ula on lan then masquarade it if you have gua assigned but I guess if you have a dynamic ip then your internal prefix would be fixed. Better use NPT then. Whatever floats your boat.

I have never masquaraded to ipv6 wan, don't know how much Plug'nPlay it will be. Some wan only have link-local addresses so you might need dhcp-pd to get which prefix you should NPT to.

Wouldn't it be better to keep gua on lan and use double NPT to access it, so it appears as you are trying to connect to a private prefix but translated to gua lan prefix whilst also changing source prefix. Then the lan device will think this is a local package and from wg server everything appears as local prefix and on lan everything appears as global prefix. That would be neat!

 

[Martineau]

Thanks, no problems with creating server peer, or delete devices anymore:

OK so delX is no longer required (I'll disable/remove it)

tried out the new experimental ula generator, and it worked after installing the required package:

wierd that ipv6 ula gives aa prefix in both cases, thought it would give fd and suggest to use aa. But when creating the peer it gives fd (which makes sense if the generated ula proposed fd).

Ahhh, the demo portion of ipv6 ula hasn't been corrected.........but Syslog should show both?

RT-AX86U-22B0 (wg_manager.sh): 15226 Here is your IPv6 ULA based on this hardware's MACs IPV6=fdc3:c4b8:7bdf::1/64 (Use 'aac3:c4b8:7bdf::1/64' for Dual-stack IPv4+IPv6)

but when used in anger...

e  = Exit Script [?]

E:Option ==> peer new ipv6

    Press y to Create (IPv4/IPv6) 'server' Peer (wg26) 10.50.6.1/24,aac3:c4b8:7bdf::1/64:11506 or press [Enter] to SKIP.

e  = Exit Script [?]

E:Option ==> peer new ipv6 ula

    Press y to Create (IPv4/IPv6) 'server' Peer (wg26) 10.50.6.1/24,fd9b:fd3d:532e::1/64:11506 or press [Enter] to SKIP.

e  = Exit Script [?]

E:Option ==> peer new ipv6 ula4

    Press y to Create (IPv4/IPv6) 'server' Peer (wg26) 10.50.6.1/24,fd00:50:6::1/64:11506 or press [Enter] to SKIP.

 

[ZebMcKayhan]

but Syslog should show both?

Yes it does.

But when looking in my syslog I found that whenever the server peer is started it always loads the build in kernel modules:

Mar 22 19:29:02 RT-AC86U-D7D8 WireGuard-serverwg21: Initialising WireGuard Kernel module '/lib/modules/4.1.27/kernel/net/wireguard/wireguard.ko'
Mar 22 19:29:02 RT-AC86U-D7D8 WireGuard-serverwg21: Initialising WireGuard VPN (IPv6) [aaff:a37f:fa75:6::1] 'Server' Peer (wg21) on 192.168.100.1,[aaff:a37f:fa75:100:100::1]:11501
Mar 22 19:29:03 RT-AC86U-D7D8 WireGuard-serverwg21: Executing wg21-up.sh
Mar 22 19:29:03 RT-AC86U-D7D8 WireGuard-serverwg21: Initialisation complete.
Mar 22 19:30:52 RT-AC86U-D7D8 WireGuard-serverwg21: Initialising WireGuard Kernel module '/lib/modules/4.1.27/kernel/net/wireguard/wireguard.ko'
Mar 22 19:30:52 RT-AC86U-D7D8 WireGuard-serverwg21: Executing wg21-down.sh

I checked the config and Entware modules are enabled and according to ? It is also enabled.
loadmodules Takes care of it and loads the Entware modules.
Bug?

Edit: wg_client always seems to insmod /opt/lib module but wg_server tries to locate Entware modules if exist, dont know why it dont find it on my system and decides to load buildt in.

Do we know how the system reacts if Wg_manager loads Entware module and wg_server later loads buildt in modules? will it overwrite or refuse to load? what about the started peers, they are not stopped?

 

[archiel]

@archiel

Well, my scripting skills is alittle embarrassing, but it would be great if you want to give it a try:

###############################################################################
# Example for wg21 ipv6 = aa00:aaaa:bbbb:cccc:100::1/120
# Change to your needs but keep formatting
Wg21Prefix=aa00:aaaa:bbbb:cccc:: #Wg21 ULA prefix with aa instead of fd
Wg21Suffix=100::1  #Wg21 Device suffix (last 64 bits)
Wg21PrefixLength=120   #Wg21 Prefix Length (120 recommended)
WanInterface=eth0

# Changing below lines should not be needed:
WanIp6Prefix=${nvram get ipv6_prefix}     #WanIp6Prefix=2001:1111:2222:3333::
Wg21_PrefIp=${Wg21Prefix%:*}${Wg21Suffix}/${Wg21PrefixLength}      #aa00:aaaa:bbbb:cccc:100::1/120
WanWg21_PrefIp=${WanIp6Prefix%:*}${Wg21Suffix}/${Wg21PrefixLength}   #2001:1111:2222:3333:100::1/120

# Execute firewall commands:
ip6tables -t mangle -I POSTROUTING -s ${Wg21_PrefIp} -o ${WanInterface} -j SNPT --src-pfx ${Wg21Prefix}/64 --dst-pfx ${WanIp6Prefix}/64
ip6tables -t mangle -I PREROUTING -i ${WanInterface} -d ${WanWg21_PrefIp} -j DNPT --src-pfx ${WanIp6Prefix}/64 --dst-pfx ${Wg21Prefix}/64
###############################################################################

The idea is to change the first lines according to your choice of wg21 address (note the suffix must not be ::1 and since wgm varies last digits it is convenient to use 100::1) the creation of wg21 must match prefix+suffix/cidr.

The target would be to put this in wg21-up.sh and in wg21-down.sh (change -I to -D) but for test each line could just be executed from shell.

Sorry for the delay in looking at this

I have tried running from the ssh prompt (manually inserting the relevant addresses), but while this allowed echo'd pings, it did not give the IPv6 connection.

When I tried running the script (after inserting #!/bin/sh and setting to 0755) automatically it did not create the routing rules - I tested by trying to delete the POSTROUTING rule only to get

ip6tables: No chain/target/match by that name

and when I ran wg25-up from the prompt I got line 11: syntax error: bad substitution where line 11 is WanIp6Prefix=${nvram get ipv6_prefix}

I am wondering if NPTv6 should even work if both the source and destination subnets are GUA, as I understand it is designed to map ULA to GUA. If you can let me know how to fix the syntax error, I can try again with both a real and modified ULA.

 

[ZebMcKayhan]

Sorry for the delay in looking at this

I have tried running from the ssh prompt (manually inserting the relevant addresses), but while this allowed echo'd pings, it did not give the IPv6 connection.

When I tried running the script (after inserting #!/bin/sh and setting to 0755) automatically it did not create the routing rules - I tested by trying to delete the POSTROUTING rule only to get

ip6tables: No chain/target/match by that name

and when I ran wg25-up from the prompt I got line 11: syntax error: bad substitution where line 11 is WanIp6Prefix=${nvram get ipv6_prefix}

I am wondering if NPTv6 should even work if both the source and destination subnets are GUA, as I understand it is designed to map ULA to GUA. If you can let me know how to fix the syntax error, I can try again with both a real and modified ULA.

No worries. We all do this on our "spare" time and sometimes there just aren't any.

That's exactly what I would like to find out too.

Figures my rotten scripting skills gets in the way... please pm me your wan prefix and your wg25 ip/cidr and I will make them manually for you to put in.

Or if you rather like, publish wg25 ip/cidr here (if it is indeed private) and you could fill in the wan prefix.

Edit:

 WanIp6Prefix=${nvram get ipv6_prefix}

Should be replaced by:

 WanIp6Prefix=$(nvram get ipv6_prefix)

Thats why you get the error message

 

[ZebMcKayhan]

@archiel

dont know why it's apparently not working for you when you enter the commands manually. I will probably need to look at your commands and wg21 ip to be able to determine this.

however, the tricky part is that, since the prefix are interchangeable with NPT then the device suffix (or wan prefix) must be locally unique.

so if your wan prefix is:
2001:db8:1111:2222::/64 and the router br0 has 2001:db8:1111:2222::1
and your wg21 is:
aaaa:bbbb:cccc:dddd::/64 and wg21 has aaaa:bbbb:cccc:dddd::1

it is not gonna work, and it is abit tricky to explain/understand. but imagine wg21 send a package to wan so the source address would be translated accordingly:
aaaa:bbbb:cccc:dddd::1 --> 2001:db8:1111:2222::1
which means the source address is now the same as br0 which is not really a problem for the outgoing package but the reply would then be destined to:
2001:db8:1111:2222::1 and if we apply our rule all these packages will be translated to:
2001:db8:1111:2222::1 --> aaaa:bbbb:cccc:dddd::1

which effectively means there is no way for packages on WAN to contact the router br0 anymore... so your ipv6 connection is probably lost on your router. and according to the /64 the entire lan will be translated to your private prefix, so, no more ipv6.

this is why I recommend to use another address range and slim down the range:
aaaa:bbbb:cccc:dddd:100::/120

this way we only translate the smaller range which does not conflict with br0, as packages on wan within:
2001:db8:1111:2222:100::1 - 2001:db8:1111:2222:100::ff
will be translated accordingly:
2001:db8:1111:2222:100::/120 --> aaaa:bbbb:cccc:dddd:100::/120
and if there by some odd chance that any lan device assignes itself this device id, well then, tough luck for that device as it is probably not following the address assignment standards. but an easy fix would be to just switch wg21 to some other range.

so the commands:

ip6tables -t mangle -I POSTROUTING -s aaaa:bbbb:cccc:dddd:100::/120 -o etho -j SNPT --src-pfx aaaa:bbbb:cccc:dddd::/64 --dst-pfx 2001:db8:1111:2222::/64
ip6tables -t mangle -I PREROUTING -i wg21 -d 2001:db8:1111:2222:100::/120 -j DNPT --src-pfx 2001:db8:1111:2222::/64 --dst-pfx aaaa:bbbb:cccc:dddd::/64

would do exactly that.

now, it we have a /56 or /48 we could change the prefix instead and not have this conflict:
so if your wan prefix is:
2001:db8:1111::/48 and the router br0 has 2001:db8:1111::1

we could simply use a unique subnet for our server, like this:
2001:db8:1111:100::/64
so if we translate to and from this unique subnet, we could keep our full range wg21 as:
aaaa:bbbb:cccc:dddd::/64 and wg21 has aaaa:bbbb:cccc:dddd::1

and the rules will be something like:

ip6tables -t mangle -I POSTROUTING -s aaaa:bbbb:cccc:dddd::/64 -o etho -j SNPT --src-pfx aaaa:bbbb:cccc:dddd::/64 --dst-pfx 2001:db8:1111:100::/64
ip6tables -t mangle -I PREROUTING -i wg21 -d 2001:db8:1111:100::/64 -j DNPT --src-pfx 2001:db8:1111:100::/64 --dst-pfx aaaa:bbbb:cccc:dddd::/64

the problem is if the your wan is dynamic. a script needs to obtain the prefix via:

nvram get ipv6_prefix

then make changes within this. for a /48 subnet it would be rather easy since it always looks the same, but for a /56 prefix there could be omitted leading zeroes or actually omitted the entire last part if your assignement happens to be 0 which leads to the expansion and compression of ipv6 which is beyond my scripting skills.

I'm just throwing this out there as something like this may have been your problem?

 

[Martineau]

I found that whenever the server peer is started it always loads the build in kernel modules:
I checked the config and Entware modules are enabled and according to ? It is also enabled.
loadmodules Takes care of it and loads the Entware modules.
Bug?

Indeed

Edit: wg_client always seems to insmod /opt/lib module but wg_server tries to locate Entware modules if exist, dont know why it dont find it on my system and decides to load buildt in.

I've uploaded wireguard_manager Beta v4.16b8

i.e. Loading of the expected (Firmware or 3rd-party) Kernel modules should now ONLY occur during the initialisation of wireguard_manager @boot-time

To upgrade use

e  = Exit Script [?]

E:Option ==> uf dev

 

[archiel]

@archiel

dont know why it's apparently not working for you when you enter the commands manually. I will probably need to look at your commands and wg21 ip to be able to determine this.

however, the tricky part is that, since the prefix are interchangeable with NPT then the device suffix (or wan prefix) must be locally unique.

so if your wan prefix is:
2001:db8:1111:2222::/64 and the router br0 has 2001:db8:1111:2222::1
and your wg21 is:
aaaa:bbbb:cccc:dddd::/64 and wg21 has aaaa:bbbb:cccc:dddd::1

it is not gonna work, and it is abit tricky to explain/understand. but imagine wg21 send a package to wan so the source address would be translated accordingly:
aaaa:bbbb:cccc:dddd::1 --> 2001:db8:1111:2222::1
which means the source address is now the same as br0 which is not really a problem for the outgoing package but the reply would then be destined to:
2001:db8:1111:2222::1 and if we apply our rule all these packages will be translated to:
2001:db8:1111:2222::1 --> aaaa:bbbb:cccc:dddd::1

which effectively means there is no way for packages on WAN to contact the router br0 anymore... so your ipv6 connection is probably lost on your router. and according to the /64 the entire lan will be translated to your private prefix, so, no more ipv6.

this is why I recommend to use another address range and slim down the range:
aaaa:bbbb:cccc:dddd:100::/120

this way we only translate the smaller range which does not conflict with br0, as packages on wan within:
2001:db8:1111:2222:100::1 - 2001:db8:1111:2222:100::ff
will be translated accordingly:
2001:db8:1111:2222:100::/120 --> aaaa:bbbb:cccc:dddd:100::/120
and if there by some odd chance that any lan device assignes itself this device id, well then, tough luck for that device as it is probably not following the address assignment standards. but an easy fix would be to just switch wg21 to some other range.

so the commands:

ip6tables -t mangle -I POSTROUTING -s aaaa:bbbb:cccc:dddd:100::/120 -o etho -j SNPT --src-pfx aaaa:bbbb:cccc:dddd::/64 --dst-pfx 2001:db8:1111:2222::/64
ip6tables -t mangle -I PREROUTING -i wg21 -d 2001:db8:1111:2222:100::/120 -j DNPT --src-pfx 2001:db8:1111:2222::/64 --dst-pfx aaaa:bbbb:cccc:dddd::/64

would do exactly that.

now, it we have a /56 or /48 we could change the prefix instead and not have this conflict:
so if your wan prefix is:
2001:db8:1111::/48 and the router br0 has 2001:db8:1111::1

we could simply use a unique subnet for our server, like this:
2001:db8:1111:100::/64
so if we translate to and from this unique subnet, we could keep our full range wg21 as:
aaaa:bbbb:cccc:dddd::/64 and wg21 has aaaa:bbbb:cccc:dddd::1

and the rules will be something like:

ip6tables -t mangle -I POSTROUTING -s aaaa:bbbb:cccc:dddd::/64 -o etho -j SNPT --src-pfx aaaa:bbbb:cccc:dddd::/64 --dst-pfx 2001:db8:1111:100::/64
ip6tables -t mangle -I PREROUTING -i wg21 -d 2001:db8:1111:100::/64 -j DNPT --src-pfx 2001:db8:1111:100::/64 --dst-pfx aaaa:bbbb:cccc:dddd::/64

the problem is if the your wan is dynamic. a script needs to obtain the prefix via:

nvram get ipv6_prefix

then make changes within this. for a /48 subnet it would be rather easy since it always looks the same, but for a /56 prefix there could be omitted leading zeroes or actually omitted the entire last part if your assignement happens to be 0 which leads to the expansion and compression of ipv6 which is beyond my scripting skills.

I'm just throwing this out there as something like this may have been your problem?

script is still not working

I created the server with

peer new ip=10.50.7.1/24 ipv6=aa36:7ef1:2add:aa88:100::1/120

which shows as (wg option 3)

interface: wg25  Port:11505     10.50.7.1/24                    VPN Tunnel Network      # RT-AX88U (IPv4/IPv6) Server 5
                peer: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=      10.50.7.2/32,aa36:7ef1:2add:aa88:100::2/128             # sam25 "Device"
                 latest handshake: 1 minute, 47 seconds ago
                 transfer: 1.01 MiB received, 2.69 MiB sent             0 Days, 00:43:33 since Thu Mar 24 20:19:30 2022

the wg25-up script is

#!/bin/sh
###############################################################################
# Example for Wg25 ipv6 = aa00:aaaa:bbbb:cccc:100::1/120
# Change to your needs but keep formatting
Wg25Prefix=aa36:7ef1:2add:aa88:: #Wg25 ULA prefix with aa instead of fd
Wg25Suffix=100::1  #Wg25 Device suffix (last 64 bits)
Wg25PrefixLength=120   #Wg25 Prefix Length (120 recommended)
WanInterface=eth0
 
# Changing below lines should not be needed:
WanIp6Prefix=$(nvram get ipv6_prefix)     #WanIp6Prefix=2001:1111:2222:3333::
Wg25_PrefIp=${Wg25Prefix%:*}${Wg25Suffix}/${Wg25PrefixLength}      #aa00:aaaa:bbbb:cccc:100::1/120
WanWg25_PrefIp=${WanIp6Prefix%:*}${Wg25Suffix}/${Wg25PrefixLength}   #2001:1111:2222:3333:100::1/120

# Execute firewall commands:
ip6tables -t mangle -I POSTROUTING -s ${Wg25_PrefIp} -o ${WanInterface} -j SNPT --src-pfx ${Wg25Prefix}/64 --dst-pfx ${WanIp6Prefix}/64
ip6tables -t mangle -I PREROUTING -i ${WanInterface} -d ${WanWg25_PrefIp} -j DNPT --src-pfx ${WanIp6Prefix}/64 --dst-pfx ${Wg25Prefix}/64
###############################################################################

As I still get no echo from checking

tcpdump -i eth0 -vv icmp6

I tried running the script directly and got

admin@RT-AX88U-5050:/tmp/home/root# sh /jffs/addons/wireguard/Scripts/wg25-up.sh
: not founds/wireguard/Scripts/wg25-up.sh: line 9:
: not founds/wireguard/Scripts/wg25-up.sh: line 14:
ip6tables v1.4.21: SNPT: bad value for option "--dst-pfx", neither a valid network mask nor valid CIDR (0-128).
Try `ip6tables -h' or 'ip6tables --help' for more information.
ip6tables v1.4.21: DNPT: bad value for option "--dst-pfx", neither a valid network mask nor valid CIDR (0-128).
Try `ip6tables -h' or 'ip6tables --help' for more information.

Testing

admin@RT-AX88U-5050:/tmp/home/root# echo WanIp6Prefix=$(nvram get ipv6_prefix)
WanIp6Prefix=2a02:c7f:yyyy:xxxx::

which is my LAN IPv6 Prefix as shown in the IPv6 log page, save it is /56 rather than /64

 

[JGrana]

@Martineau , can I recommend you add an additional field to the server peer in a site-2-site configuration?
I was having the wg tunnel occasionally drop. I run an rsync script in the wee hours of the morning and it often complained it could not establish a connection. I would restart the Home server peer - and the tunnel would re-establish. Restarting the remote Cabin peer didn't re-establish.
I did some research:

The PersistentKeepalive setting in a config is useful if both of the following bullet points apply

    you are behind NAT (without having configured port-forwarding) or you have a dynamically changing IP address

    you want a WireGuard peer to be able to send you data after a longer pause (e.g. initiation of a new connection or a long-lived TCP connection with hardly any data flowing most of the time).

Not using the PersistentKeepalive feature in this scenario would make the incoming connection not work or the long-lived TCP connection break down.

So, I added "PersistentKeepalive = 25" to the Home wg22.conf file (under the Cabin peer) and it has been stable for a week.
I believe for site-2-site, where you want the tunnel always up, this makes sense. For more dynamic peers (i.e. phones, laptops, etc.) I don't believe it is necessary - and likely not recommended since it makes wireguard a little more "chatty".

Here is part of my Home wg22.conf file showing my addition:

# Home - 192.168.1.0/24
[Interface]
PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Address = 10.9.8.1/32
ListenPort = 61820

# WireGuard (%p - ListenPort ONLY recognised by Martineau's WireGuard Manager/wg-quick2)

PostUp =   iptables -I INPUT -p udp --dport %p -j ACCEPT; iptables -I INPUT -i %i -j ACCEPT; iptables -I FORWARD -i %i -j ACC
PostDown = iptables -D INPUT -p udp --dport %p -j ACCEPT; iptables -D INPUT -i %i -j ACCEPT; iptables -D FORWARD -i %i -j ACC


# Cabin LAN
[Peer]
PublicKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
AllowedIPs = 10.9.8.2/32, 192.168.2.0/24
Endpoint = myrouter.asuscomm.com:61821
PersistentKeepalive = 25

I do not have the Keepalive setting in the Cabin's wg22.conf. I'm guessing just setting it on one end of the tunnel is fine.

 

[Martineau]

@Martineau , can I recommend you add an additional field to the server peer in a site-2-site configuration?
I was having the wg tunnel occasionally drop. I run an rsync script in the wee hours of the morning and it often complained it could not establish a connection. I would restart the Home server peer - and the tunnel would re-establish. Restarting the remote Cabin peer didn't re-establish.
I did some research:

The PersistentKeepalive setting in a config is useful if both of the following bullet points apply

    you are behind NAT (without having configured port-forwarding) or you have a dynamically changing IP address

    you want a WireGuard peer to be able to send you data after a longer pause (e.g. initiation of a new connection or a long-lived TCP connection with hardly any data flowing most of the time).

Not using the PersistentKeepalive feature in this scenario would make the incoming connection not work or the long-lived TCP connection break down.

So, I added "PersistentKeepalive = 25" to the Home wg22.conf file (under the Cabin peer) and it has been stable for a week.
I believe for site-2-site, where you want the tunnel always up, this makes sense. For more dynamic peers (i.e. phones, laptops, etc.) I don't believe it is necessary - and likely not recommended since it makes wireguard a little more "chatty".

Here is part of my Home wg22.conf file showing my addition:

# Home - 192.168.1.0/24
[Interface]
PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Address = 10.9.8.1/32
ListenPort = 61820

# WireGuard (%p - ListenPort ONLY recognised by Martineau's WireGuard Manager/wg-quick2)

PostUp =   iptables -I INPUT -p udp --dport %p -j ACCEPT; iptables -I INPUT -i %i -j ACCEPT; iptables -I FORWARD -i %i -j ACC
PostDown = iptables -D INPUT -p udp --dport %p -j ACCEPT; iptables -D INPUT -i %i -j ACCEPT; iptables -D FORWARD -i %i -j ACC


# Cabin LAN
[Peer]
PublicKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
AllowedIPs = 10.9.8.2/32, 192.168.2.0/24
Endpoint = myrouter.asuscomm.com:61821
PersistentKeepalive = 25

I do not have the Keepalive setting in the Cabin's wg22.conf. I'm guessing just setting it on one end of the tunnel is fine.

Many thanks.

It shouldn't cause any harm having PersistentKeepalive = 25 on both ends - which is what I have added.

I've uploaded a Hotfix to wireguard_manager Beta v4.16b8

To apply the patch use:

e  = Exit Script [?]

E:Option ==> uf dev

 

[ZebMcKayhan]

script is still not working

I created the server with

peer new ip=10.50.7.1/24 ipv6=aa36:7ef1:2add:aa88:100::1/120

which shows as (wg option 3)

interface: wg25  Port:11505     10.50.7.1/24                    VPN Tunnel Network      # RT-AX88U (IPv4/IPv6) Server 5
                peer: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=      10.50.7.2/32,aa36:7ef1:2add:aa88:100::2/128             # sam25 "Device"
                 latest handshake: 1 minute, 47 seconds ago
                 transfer: 1.01 MiB received, 2.69 MiB sent             0 Days, 00:43:33 since Thu Mar 24 20:19:30 2022

the wg25-up script is

#!/bin/sh
###############################################################################
# Example for Wg25 ipv6 = aa00:aaaa:bbbb:cccc:100::1/120
# Change to your needs but keep formatting
Wg25Prefix=aa36:7ef1:2add:aa88:: #Wg25 ULA prefix with aa instead of fd
Wg25Suffix=100::1  #Wg25 Device suffix (last 64 bits)
Wg25PrefixLength=120   #Wg25 Prefix Length (120 recommended)
WanInterface=eth0

# Changing below lines should not be needed:
WanIp6Prefix=$(nvram get ipv6_prefix)     #WanIp6Prefix=2001:1111:2222:3333::
Wg25_PrefIp=${Wg25Prefix%:*}${Wg25Suffix}/${Wg25PrefixLength}      #aa00:aaaa:bbbb:cccc:100::1/120
WanWg25_PrefIp=${WanIp6Prefix%:*}${Wg25Suffix}/${Wg25PrefixLength}   #2001:1111:2222:3333:100::1/120

# Execute firewall commands:
ip6tables -t mangle -I POSTROUTING -s ${Wg25_PrefIp} -o ${WanInterface} -j SNPT --src-pfx ${Wg25Prefix}/64 --dst-pfx ${WanIp6Prefix}/64
ip6tables -t mangle -I PREROUTING -i ${WanInterface} -d ${WanWg25_PrefIp} -j DNPT --src-pfx ${WanIp6Prefix}/64 --dst-pfx ${Wg25Prefix}/64
###############################################################################

As I still get no echo from checking

tcpdump -i eth0 -vv icmp6

I tried running the script directly and got

admin@RT-AX88U-5050:/tmp/home/root# sh /jffs/addons/wireguard/Scripts/wg25-up.sh
: not founds/wireguard/Scripts/wg25-up.sh: line 9:
: not founds/wireguard/Scripts/wg25-up.sh: line 14:
ip6tables v1.4.21: SNPT: bad value for option "--dst-pfx", neither a valid network mask nor valid CIDR (0-128).
Try `ip6tables -h' or 'ip6tables --help' for more information.
ip6tables v1.4.21: DNPT: bad value for option "--dst-pfx", neither a valid network mask nor valid CIDR (0-128).
Try `ip6tables -h' or 'ip6tables --help' for more information.

Testing

admin@RT-AX88U-5050:/tmp/home/root# echo WanIp6Prefix=$(nvram get ipv6_prefix)
WanIp6Prefix=2a02:c7f:yyyy:xxxx::

which is my LAN IPv6 Prefix as shown in the IPv6 log page, save it is /56 rather than /64

well, I will have to look at the script in time... since there are error messages the rules will not be applied.

try to add these rules manually:

ip6tables -t mangle -I POSTROUTING -s aa36:7ef1:2add:aa88:100::1/120 -o eth0 -j SNPT --src-pfx aa36:7ef1:2add:aa88::/64 --dst-pfx 2a02:c7f:yyyy:xxxx::/64
ip6tables -t mangle -I PREROUTING -i eth0 -d 2a02:c7f:yyyy:xxxx:100::1/120 -j DNPT --src-pfx 2a02:c7f:yyyy:xxxx::/64 --dst-pfx aa36:7ef1:2add:aa88::/64

maybee it is the same as you already tried to enter manually?

It is possible that this is not really compatible with our routers. There could be issues with IPv6 neighbor proxy or conntrack... but if you can see a reply using tcpdump thats a good start... you can also check the packet hit count on the rules by:

ip6tables -nvL PREROUTING -t mangle

and:

ip6tables -nvL POSTROUTING -t mangle

 

[archiel]

@ZebMcKayhan

Well this time I re-ran

ip6tables -t mangle -I POSTROUTING -s aa36:7ef1:2add:aa88:100::1/120 -o eth0 -j SNPT --src-pfx aa36:7ef1:2add:aa88::/64 --dst-pfx 2a02:c7f:yyyy:xxxx::/64
ip6tables -t mangle -I PREROUTING -i eth0 -d 2a02:c7f:yyyy:xxxx:100::1/120 -j DNPT --src-pfx 2a02:c7f:yyyy:xxxx::/64 --dst-pfx aa36:7ef1:2add:aa88::/64

and I could get an echo but I still have no IPv6 on the phone

 tcpdump -i eth0 -vv icmp6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:21:52.171178 IP6 (flowlabel 0x2e700, hlim 63, next-header ICMPv6 (58) payload length: 64) 2a02:c7f:xxxx:yyyy:c848::2 > 2600::: [icmp6 sum ok] ICMP6, echo request, seq 1
17:21:52.275047 IP6 (hlim 52, next-header ICMPv6 (58) payload length: 64) 2600:: > 2a02:c7f:xxxx:yyyy:c848::2: [icmp6 sum ok] ICMP6, echo reply, seq 1
17:21:56.231301 IP6 (flowlabel 0x2e700, hlim 63, next-header ICMPv6 (58) payload length: 64) 2a02:c7f:xxxx:yyyy:c848::2 > 2600::: [icmp6 sum ok] ICMP6, echo request, seq 1
17:21:56.335373 IP6 (hlim 52, next-header ICMPv6 (58) payload length: 64) 2600:: > 2a02:c7f:xxxx:yyyy:c848::2: [icmp6 sum ok] ICMP6, echo reply, seq 1
17:22:00.230919 IP6 (flowlabel 0x2e700, hlim 63, next-header ICMPv6 (58) payload length: 64) 2a02:c7f:f0c3:1000:c848::2 > 2600::: [icmp6 sum ok] ICMP6, echo request, seq 1
17:22:00.335200 IP6 (hlim 52, next-header ICMPv6 (58) payload length: 64) 2600:: > 2a02:c7f:xxxx:yyyy:c848::2: [icmp6 sum ok] ICMP6, echo reply, seq 1

Looking at ip6tables -nvL PREROUTING -t mangle

BEFORE
admin@RT-AX88U-5050:/tmp/home/root# ip6tables -nvL PREROUTING -t mangle
Chain PREROUTING (policy ACCEPT 402 packets, 116K bytes)
pkts bytes target     prot opt in     out     source               destination
    8   696 MARK       all      wg25   *       ::/0                 ::/0                 /* WireGuard 'server' */ MARK xset 0x1/0x7
    0     0 DNPT       all      eth0   *       ::/0                 2a02:c7f:xxxx:yyyy:100::/120 src-pfx 2a02:c7f:xxxx:yyyy::/64 dst-pfx aa36:7ef1:2add:aa88::/64

AFTER
admin@RT-AX88U-5050:/tmp/home/root# ip6tables -nvL PREROUTING -t mangle
Chain PREROUTING (policy ACCEPT 3888 packets, 1234K bytes)
pkts bytes target     prot opt in     out     source               destination
   23  1968 MARK       all      wg25   *       ::/0                 ::/0                 /* WireGuard 'server' */ MARK xset 0x1/0x7
    0     0 DNPT       all      eth0   *       ::/0                 2a02:c7f:xxxx:yyyy:100::/120 src-pfx 2a02:c7f:xxxx:yyyy::/64 dst-pfx aa36:7ef1:2add:aa88::/64

and ip6tables -nvL POSTROUTING -t mangle

BEFORE
admin@RT-AX88U-5050:/tmp/home/root# ip6tables -nvL POSTROUTING -t mangle
Chain POSTROUTING (policy ACCEPT 1403 packets, 414K bytes)
pkts bytes target     prot opt in     out     source               destination
  400  109K SNPT       all      *      eth0    aa36:7ef1:2add:aa88:100::/120  ::/0                src-pfx aa36:7ef1:2add:aa88::/64 dst-pfx 2a02:c7f:xxxx:yyyy::/64
AFTER
admin@RT-AX88U-5050:/tmp/home/root# ip6tables -nvL POSTROUTING -t mangle
Chain POSTROUTING (policy ACCEPT 3860 packets, 1175K bytes)
pkts bytes target     prot opt in     out     source               destination
  408  110K SNPT       all      *      eth0    aa36:7ef1:2add:aa88:100::/120  ::/0                src-pfx aa36:7ef1:2add:aa88::/64 dst-pfx 2a02:c7f:xxxx:yyyy::/64

Is it relevant that the ping from the phone to 2600:: appear to coming from 2a02:c7f:xxxx:yyyy:c848::2 rather than 2a02:c7f:xxxx:yyyy:100::2 which should(?) be the translated address from aa36:7ef1:2add:aa88:100::2

 

[ZebMcKayhan]

Is it relevant that the ping from the phone to 2600:: appear to coming from 2a02:c7f:xxxx:yyyy:c848::2 rather than 2a02:c7f:xxxx:yyyy:100::2 which should(?) be the translated address from aa36:7ef1:2add:aa88:100::2

It is indeed.... looks like the snpt messed up somehow and changed the device suffix altough Thats not what the command says, and that's not what it did for me... any proxy involved?

Edit:
Checking my old command, I see the same thing, cant believe I didn't see that before:

Before command:
fc00:192:168:100::2 > arn11s11-in-x0e.1e100.net:

Issuing command
ip6tables -t mangle -I POSTROUTING -s fc00:192:168:100::/64 -o wg11 -j SNPT --src-pfx fc00:192:168:100::/64 --dst-pfx fdab:1337:1337:69::/64 

fdab:1337:1337:69:db77::2 > arn11s11-in-x0e.1e100.net:

So the command seems to append a db77 as the first part of the device suffix...

If this is always true, and fixed, it means that we wouldnt need the 100::1 on wg21, but we need to know that it is fixed for the reciever, or how to obtain which is used...

 

[ZebMcKayhan]

@archiel
After some reading I have not found anything really explaining this behavior. Given that it is meant to work on a /64 subnet so you may have better luck assigning a wan subnet for wg-server (you did have a /56 assignement right?). This means your 2 last xx is 00 and you are allowed to set this yourself. It would look something like:

ip6tables -t mangle -I POSTROUTING -s aa36:7ef1:2add:aa88::/64 -o eth0 -j SNPT --src-pfx aa36:7ef1:2add:aa88::/64 --dst-pfx 2a02:c7f:yyyy:xx01::/64 
ip6tables -t mangle -I PREROUTING -i eth0 -d 2a02:c7f:yyyy:xx01::/64 -j DNPT --src-pfx 2a02:c7f:yyyy:xx01::/64 --dst-pfx aa36:7ef1:2add:aa88::/64

Now, even if the device part is changed, it should be changed back(?)

It seems a known fact that NPT6 is not compatible with CONNTRACK which is used in ASUS stateful firewall. This would mean that we simply cannot use it..

There is actually another way, which is compatible with CONNTRACK but it leans more towards NAT6 but could be worth a try? I tested the commands and they are accepted by ip6tables but never checked if they worked:

ip6tables -t nat -A POSTROUTING -o eth0 -s aa36:7ef1:2add:aa88:100::1/120 -j NETMAP --to 2a02:c7f:yyyy:xxxx::/64 
ip6tables -t nat -A PREROUTING -i eth0 -d 2a02:c7f:yyyy:xxxx:100::1/120 -j NETMAP --to aa36:7ef1:2add:aa88::/64

//Zeb

 

[archiel]

@archiel
After some reading I have not found anything really explaining this behavior. Given that it is meant to work on a /64 subnet so you may have better luck assigning a wan subnet for wg-server (you did have a /56 assignement right?). This means your 2 last xx is 00 and you are allowed to set this yourself. It would look something like:

ip6tables -t mangle -I POSTROUTING -s aa36:7ef1:2add:aa88::/64 -o eth0 -j SNPT --src-pfx aa36:7ef1:2add:aa88::/64 --dst-pfx 2a02:c7f:yyyy:xx01::/64
ip6tables -t mangle -I PREROUTING -i eth0 -d 2a02:c7f:yyyy:xx01::/64 -j DNPT --src-pfx 2a02:c7f:yyyy:xx01::/64 --dst-pfx aa36:7ef1:2add:aa88::/64

Now, even if the device part is changed, it should be changed back(?)

It seems a known fact that NPT6 is not compatible with CONNTRACK which is used in ASUS stateful firewall. This would mean that we simply cannot use it..

There is actually another way, which is compatible with CONNTRACK but it leans more towards NAT6 but could be worth a try? I tested the commands and they are accepted by ip6tables but never checked if they worked:

ip6tables -t nat -A POSTROUTING -o eth0 -s aa36:7ef1:2add:aa88:100::1/120 -j NETMAP --to 2a02:c7f:yyyy:xxxx::/64
ip6tables -t nat -A PREROUTING -i eth0 -d 2a02:c7f:yyyy:xxxx:100::1/120 -j NETMAP --to aa36:7ef1:2add:aa88::/64

//Zeb

Thanks for your patience with this. I do not have a proxy and I do have an assigned /56 so I can modify the last two bits from 00 to bb.
Trying NPT6 again, while I can see the ping echoed on the router

admin@RT-AX88U-5050:/tmp/home/root# tcpdump -i eth0 -vv icmp6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:42:24.811345 IP6 (flowlabel 0x655ed, hlim 63, next-header ICMPv6 (58) payload length: 64) 2a02:c7f:xxxx:yybb:c78d::2 > 2600::: [icmp6 sum ok] ICMP6, echo request, seq 1
17:42:24.917695 IP6 (hlim 52, next-header ICMPv6 (58) payload length: 64) 2600:: > 2a02:c7f:xxxx:yybb:c78d::2: [icmp6 sum ok] ICMP6, echo reply, seq 1

and I can see the packet count increase using ip6tables -nvL POSTROUTING -t mangle & ip6tables -nvL PREROUTING -t mangle, from the phone's perspective there is still no reply and IPv6 is not functioning.

Switching to NETMAP and everything worked - pings echoed on router and phone and phone has IPv6

Just need to fix wgNN-up.sh / wgNN-down.sh and and that should be it.

 

[ZebMcKayhan]

Switching to NETMAP and everything worked - pings echoed on router and phone and phone has IPv6

Wow, cool! Guessing Entware iptables are required for this but not sure.

By the way, finally found why device ip is changed during NTP. It is to maintain package checksum:

RFC 6296: IPv6-to-IPv6 Network Prefix Translation

This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes...

datatracker.ietf.org

The translation function calculates the one's complement sum of the 16-bit words of the /64 external prefix and the /64 internal prefix. It then calculates the difference between these values: internal minus external. This value, called the "adjustment", is effectively constant for the lifetime of the NPTv6 Translator configuration and is used in per-datagram processing.

So I tested it by hand, and it works:

fc00:0192:0168:0100::
fdab:1337:1337:0069::
Resulting translation: 
fdab:1337:1337:69:db77:: 

fc00:0192:0168:0100
Ones complement:
03ff:fe6d:fe97:feff
Sum:
0x03ff+0xfe6d+0xfe97+0xfeff=0x30002 

fdab:1337:1337:0069
Ones complement:
0254:ecc8:ecc8:ff96
Sum:
0x254+0xecc8+0xecc8+0xff96=0x2db7a 

0x2db7a - 0x30002 = 0xdb77 (negative)

so it means the value is static and should be calculable in I.e a script.

However, from this point I'm guessing the problem is incompability with conntrack so it is probably blocking replies.

I'll take a look into adjusting the script for NMAP.

 

[ZebMcKayhan]

@archiel
Try this, but change to match your ip's
You can execute each command at the prompt first to make sure it is working, but as is it is working on my router

#!/bin/sh 
###############################################################################
 # Example for wg21 ipv6 = aa00:aaaa:bbbb:cccc:100::1/120
 # Change to your needs but keep formatting 
Wg21Prefix=aa00:aaaa:bbbb:cccc:: #Wg21 ULA prefix with aa instead of fd 
Wg21Suffix=100::1 #Wg21 Device suffix (last 64 bits) 
Wg21PrefixLength=120 #Wg21 Prefix Length (120 recommended) 
WanInterface=eth0 
# Changing below lines should not be needed: 
WanIp6Prefix=$(nvram get ipv6_prefix) #WanIp6Prefix=2001:1111:2222:3333:: 
Wg21_PrefIp=${Wg21Prefix%:*}${Wg21Suffix}/${Wg21PrefixLength} #aa00:aaaa:bbbb:cccc:100::1/120 
WanWg21_PrefIp=${WanIp6Prefix%:*}${Wg21Suffix}/${Wg21PrefixLength} #2001:1111:2222:3333:100::1/120 
# Execute firewall commands: 
ip6tables -t nat -I POSTROUTING -s ${Wg21_PrefIp} -o ${WanInterface} -j NETMAP --to ${WanIp6Prefix}/64 
ip6tables -t nat -I PREROUTING -i ${WanInterface} -d ${WanWg21_PrefIp} -j NETMAP --to ${Wg21Prefix}/64 
###############################################################################

fingers crossed.

If you run into problems, run all commands in sequence at the prompt and put an echo before the last to commands, as:

echo ip6tables -t nat -I POSTROUTING -s ${Wg21_PrefIp} -o ${WanInterface} -j NETMAP --to ${WanIp6Prefix}/64 
echo ip6tables -t nat -I PREROUTING -i ${WanInterface} -d ${WanWg21_PrefIp} -j NETMAP --to ${Wg21Prefix}/64

And you can look at how the commands look and find out where it is going wrong.

 

[heysoundude]

Wow, cool! Guessing Entware iptables are required for this but not sure.

By the way, finally found why device ip is changed during NTP. It is to maintain package checksum:

RFC 6296: IPv6-to-IPv6 Network Prefix Translation

This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes...

datatracker.ietf.org

So I tested it by hand, and it works:

fc00:0192:0168:0100::
fdab:1337:1337:0069::
Resulting translation:
fdab:1337:1337:69:db77::

fc00:0192:0168:0100
Ones complement:
03ff:fe6d:fe97:feff
Sum:
0x03ff+0xfe6d+0xfe97+0xfeff=0x30002

fdab:1337:1337:0069
Ones complement:
0254:ecc8:ecc8:ff96
Sum:
0x254+0xecc8+0xecc8+0xff96=0x2db7a

0x2db7a - 0x30002 = 0xdb77

so it means the value is static and should be calculable in I.e a script.

However, from this point I'm guessing the problem is incompability with conntrack so it is probably blocking replies.

I'll take a look into adjusting the script for NMAP.

Does this help?

Routing & Network Namespaces - WireGuard

www.wireguard.com

@archiel
After some reading I have not found anything really explaining this behavior. Given that it is meant to work on a /64 subnet so you may have better luck assigning a wan subnet for wg-server (you did have a /56 assignement right?). This means your 2 last xx is 00 and you are allowed to set this yourself. It would look something like:

ip6tables -t mangle -I POSTROUTING -s aa36:7ef1:2add:aa88::/64 -o eth0 -j SNPT --src-pfx aa36:7ef1:2add:aa88::/64 --dst-pfx 2a02:c7f:yyyy:xx01::/64
ip6tables -t mangle -I PREROUTING -i eth0 -d 2a02:c7f:yyyy:xx01::/64 -j DNPT --src-pfx 2a02:c7f:yyyy:xx01::/64 --dst-pfx aa36:7ef1:2add:aa88::/64

Now, even if the device part is changed, it should be changed back(?)

It seems a known fact that NPT6 is not compatible with CONNTRACK which is used in ASUS stateful firewall. This would mean that we simply cannot use it..

There is actually another way, which is compatible with CONNTRACK but it leans more towards NAT6 but could be worth a try? I tested the commands and they are accepted by ip6tables but never checked if they worked:

ip6tables -t nat -A POSTROUTING -o eth0 -s aa36:7ef1:2add:aa88:100::1/120 -j NETMAP --to 2a02:c7f:yyyy:xxxx::/64
ip6tables -t nat -A PREROUTING -i eth0 -d 2a02:c7f:yyyy:xxxx:100::1/120 -j NETMAP --to aa36:7ef1:2add:aa88::/64

//Zeb

Is this the NETMAP to which you refer?

http://info.iet.unipi.it/~luigi/netmap/

 

[ZebMcKayhan]

Does this help?

I don't know. I have never really grasped the network namespaces. Checked it on my router and no namespaces existed. Given how picky broadcom is about bridges and interfaces it may be a long way down this path.

Is this the NETMAP to which you refer?
http://info.iet.unipi.it/~luigi/netmap/

I don't think so... but I don't find too much information about it. It appears as it is not checksum neutral as NTP so it is not as lean and fast. But iptables manual says NPT is not compatible with conntrack hence not with the stateful firewall we all have and enjoy. Some links:

Netfilter Extensions HOWTO: New netfilter targets

Is there a way to have NPTv6 with connection tracking on Linux?

Apparently, the implementation of NPTv6 (Network Prefix Translation for IPv6) which is currently in Linux kernel is incompatible with connection tracking. This is quite disappointing, since I feel ...

unix.stackexchange.com

Man page of iptables-extensions

 

[archiel]

@archiel
Try this, but change to match your ip's
You can execute each command at the prompt first to make sure it is working, but as is it is working on my router

#!/bin/sh
###############################################################################
# Example for wg21 ipv6 = aa00:aaaa:bbbb:cccc:100::1/120
# Change to your needs but keep formatting
Wg21Prefix=aa00:aaaa:bbbb:cccc:: #Wg21 ULA prefix with aa instead of fd
Wg21Suffix=100::1 #Wg21 Device suffix (last 64 bits)
Wg21PrefixLength=120 #Wg21 Prefix Length (120 recommended)
WanInterface=eth0
# Changing below lines should not be needed:
WanIp6Prefix=$(nvram get ipv6_prefix) #WanIp6Prefix=2001:1111:2222:3333::
Wg21_PrefIp=${Wg21Prefix%:*}${Wg21Suffix}/${Wg21PrefixLength} #aa00:aaaa:bbbb:cccc:100::1/120
WanWg21_PrefIp=${WanIp6Prefix%:*}${Wg21Suffix}/${Wg21PrefixLength} #2001:1111:2222:3333:100::1/120
# Execute firewall commands:
ip6tables -t nat -I POSTROUTING -s ${Wg21_PrefIp} -o ${WanInterface} -j NETMAP --to ${WanIp6Prefix}/64
ip6tables -t nat -I PREROUTING -i ${WanInterface} -d ${WanWg21_PrefIp} -j NETMAP --to ${Wg21Prefix}/64
###############################################################################

fingers crossed.

If you run into problems, run all commands in sequence at the prompt and put an echo before the last to commands, as:

echo ip6tables -t nat -I POSTROUTING -s ${Wg21_PrefIp} -o ${WanInterface} -j NETMAP --to ${WanIp6Prefix}/64
echo ip6tables -t nat -I PREROUTING -i ${WanInterface} -d ${WanWg21_PrefIp} -j NETMAP --to ${Wg21Prefix}/64

And you can look at how the commands look and find out where it is going wrong.

The script works fine. Next step is to add clients to the router for which I will need a new VPN provider if I want dual stack, as I am currently using NordVPN. Once I have chosen I will follow your guide and let you know if I have any issues, and then finally to check for and lock down any DNS leaks. Thanks for all your help so far.

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