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!

FYI

In most cases, there is no need to explicitly specify any IPv4/IPv6 address when creating a new 'server' Peer........ be it IPv4 only (default), IPv6 only or Dual-stack IPv4+IPv6.

e.g. IPv4 only
Code:
peer new
IPv4+IPv6 Dual-stack
Code:
peer new ipv6
IPv6 only
Code:
peer new ipv6 noipv4
but if the default IP address/Port values etc. are deemed inappropriate or creates conflict then they should be specified etc.
I know... I just consider it as "good practice" to control this as with YazFi, OpenVPN, Wireguard, Unbound, Transmission ett.c eventually it is just a mess to arrange the routing. Keeping them in the same ranges atleast help me.

Wgm always gives a private ip right? So it will only be beneficial for those running with dynamic ipv6, otherwise you will have to nat a network which dont need it (which may prove difficult)?
 
wireguard_manager v4.15 Released

To upgrade
Code:
e  = Exit Script [?]

E:Option ==> uf
and to ensure new configuration options are available, it is prudent to issue
Code:
e  = Exit Script [?]

E:Option ==> createconfig

    Warning: WireGuard configuration file '/jffs/addons/wireguard/WireguardVPN.conf' already exists!...renamed to 'WireguardVPN.conf20220309-144455'

    Creating WireGuard configuration file '/jffs/addons/wireguard/WireguardVPN.conf'
and you will need to use command vx to check the configuration options still meet your requirements.
Just updated and generated a new config. Noticed that #NOTCPMSS appears twice in the new config?

Code:
# Override setting of the TCP MSS clamping of -t mangle FORWARD chain '-p tc>
#     Use command 'vx' to edit this setting.
#     https://www.linuxtopia.org/Linux_Firewall_iptables/x4700.html
#NOTCPMSS

# Override setting of the -t mangle FORWARD/PREROUTING '-j MARK --set-xmark >
# (NOT the user Selective Routing fwmarks for Ports/IPSETs etc.)
#     Use command 'vx' to edit this setting.
#NOSETXMARK

# Override setting of the TCP MSS clamping of -t mangle FORWARD chain '-p tc>
#     Use command 'vx' to edit this setting.
#     https://www.linuxtopia.org/Linux_Firewall_iptables/x4700.html
#NOTCPMSS
 
Just from the top of my head of things to try, but could be a long shot (dont put any of the below in any script just execute them manually from the shell, this way a reboot will always clear it):

Give eth0 a proper adress, from your prefix and see if the MASQUARADE rule somehow starts working:

Code:
ip -6 address add dev eth0 2a02:c7f:f0c3:1000::2/128

Or you could try a different approach and use SNAT instead:
Code:
ip6tables -t nat -I POSTROUTING -s fd36:7ef1:2add:aa88::/64 -o eth0 -j SNAT --to-source 2a02:c7f:f0c3:1000::1

there is a risk that you get an error message when executing the last command which means you need to install iptables from entware but it will have to be at your own risk (im running it and it appears fine on ac86u, but cant guarantee for you, but you could always uninstall it after testing)
I am testing the ULA again and can advise the the first method is not working
I have run
Code:
# ip6tables -t nat -I POSTROUTING -s  fd36:7ef1:2add:aa88::1/64 -o eth0 -j MASQUERADE -m comment --comment "WireGuard 'server'"
# ip -6 address add dev eth0 2a02:c7f:f0c3:1000::2/128
directly from the SSH prompt and these look like they have been applied as expected
Code:
admin@RT-AX88U-5050:/tmp/home/root# ip6tables -nvL POSTROUTING -t nat
Chain POSTROUTING (policy ACCEPT 48975 packets, 6918K bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  all      *      eth0    fd36:7ef1:2add:aa88::/64  ::/0                 /* WireGuard 'server' */
Code:
admin@RT-AX88U-5050:/tmp/home/root# ip addr list dev eth0
10: eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc cake state UP group default qlen 1000
    link/ether a8:5e:45:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.2/24 brd 192.168.2.255 scope global eth0:1 #{modem}
       valid_lft forever preferred_lft forever
    inet 51.198.nn.nn/22 brd 51.198.nn.255 scope global eth0  #{WAN}
       valid_lft forever preferred_lft forever
    inet6 2a02:c7f:f0c3:1000::2/128 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::aa5e:45ff:feae:5050/64 scope link
       valid_lft forever preferred_lft forever

I am now reversing these changes out, backing up my settings, waiting for a 'family off' gap and will then install iptables from entware.
 
Just updated and generated a new config. Noticed that #NOTCPMSS appears twice in the new config?

Code:
# Override setting of the TCP MSS clamping of -t mangle FORWARD chain '-p tc>
#     Use command 'vx' to edit this setting.
#     https://www.linuxtopia.org/Linux_Firewall_iptables/x4700.html
#NOTCPMSS

# Override setting of the -t mangle FORWARD/PREROUTING '-j MARK --set-xmark >
# (NOT the user Selective Routing fwmarks for Ports/IPSETs etc.)
#     Use command 'vx' to edit this setting.
#NOSETXMARK

# Override setting of the TCP MSS clamping of -t mangle FORWARD chain '-p tc>
#     Use command 'vx' to edit this setting.
#     https://www.linuxtopia.org/Linux_Firewall_iptables/x4700.html
#NOTCPMSS
:oops::rolleyes:

Well wireguard_manager v4.15 Stable Release was short-lived

Welcome to wireguard manager Beta v4.16b :p
 
I am testing the ULA again and can advise the the first method is not working
Crap! I wonder why this works to wireguard client for me and not to eth0 for you... I was really hoping that would work!

Also I'm still bummed out why your communication from wg21 does not reach your eth0 at all. Did you ever try to remove the rule and check with tcpdump eth0 while pinging? Perhaps its some firewall rule gone iffy?
 
:oops::rolleyes:

Well wireguard_manager v4.15 Stable Release was short-lived

Welcome to wireguard manager Beta v4.16b :p
Great, Also found some cosmetic stuff where the ipv6 goes through some transformation during creation but in the end turns out correct:
Code:
E:Option ==> peer new ip=192.168.100.1/24 ipv6=fdff:a37f:fa75:100::101/120

        Press y to Create (IPv4/IPv6) 'server' Peer (wg21) 192.168.100.1/24,fdff:a37f:fa75:100::101/120:11501 or press [Enter] to SKIP.
y
        Creating WireGuard Private/Public key-pair for (IPv4/IPv6) 'server' P
eer wg21 on RT-AC86U (v386.4_0)
        Press y to Start (IPv4/IPv6) 'server' Peer (wg21) or press [Enter] to SKIP.
y

        Requesting WireGuard VPN Peer start (wg21)

        wireguard-server1: Initialising Wireguard VPN (IPv6) [fdff:a37f:fa75:1::1] 'Server' Peer (wg21) on 100.126.96.1:11501 (# RT-AC86U (IPv4/IPv6) Server 1)

        wireguard-server1: Initialisation complete.

E:Option ==> create myvpn wg21

WireGuard config for device Peer 'myvpn' (192.168.100.2/32,fdff:a37f:fa75:100::2/128) created (Allowed IP's 0.0.0.0/0, ::/0 # ALL Traffic)


admin@RT-AC86U-D7D8:/tmp/home/root# ifconfig wg21
wg21      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00
-00-00
          inet addr:192.168.100.1  P-t-P:192.168.100.1  Mask:255.255.255.0
          inet6 addr: fdff:a37f:fa75:100::101/120 Scope:Global


wg21.conf
#Address = 192.168.100.1/24,fdff:a37f:fa75:100::101/120
AllowedIPs = 192.168.100.2/32,fdff:a37f:fa75:100::2/128

myvpn.conf:
Address = 192.168.100.2/32,fdff:a37f:fa75:100::2/128

I was kind of thinking that the device would turn out ::102 but I guess wgm replaces the last numbers completally. Doesn't matter really.
 
So I finally tried wireguard but encountered the first problem:

E:Option ==> peer new ipv6=2001:XXXX:XXXX:dd20::/64

***ERROR: '2001:XXXX:XXXX:dd20::/64' must be Private IPv6 address

I have a static prefix 2001:XXXX:XXXX::/48

According to ZebMcKayhans manual I can you use global addresses instead of private ones (ULA). Any idea what can be wrong? Running 4.16b
 
Crap! I wonder why this works to wireguard client for me and not to eth0 for you... I was really hoping that would work!

Also I'm still bummed out why your communication from wg21 does not reach your eth0 at all. Did you ever try to remove the rule and check with tcpdump eth0 while pinging? Perhaps its some firewall rule gone iffy?
If you mean #'ing out
Code:
ip6tables -t nat -D POSTROUTING -s  fd36:7ef1:2add:aa88::1/64 -o eth0 -j MASQUERADE -m comment --comment "WireGuard 'server'"
and then pinging 2600: and checking
Code:
tcpdump -i eth0 -vv icmp6
then, sadly, yes the pings are NOT showing
 
So I finally tried wireguard but encountered the first problem:

E:Option ==> peer new ipv6=2001:XXXX:XXXX:dd20::/64

***ERROR: '2001:XXXX:XXXX:dd20::/64' must be Private IPv6 address

I have a static prefix 2001:XXXX:XXXX::/48

According to ZebMcKayhans manual I can you use global addresses instead of private ones (ULA). Any idea what can be wrong? Running 4.16b
It might be worth trying
peer new ipv6=2001:XXXX:XXXX:dd20::1/64
 
Well... for some reason this partially worked:

peer new ip=10.50.1.1/24 ipv6=2001:XXXX:XXXX:ffd4::/64
peer wg21 auto=Y
create iphone wg21

Unfortunately, test-ipv6.com says no ipv6 connectivity. Am I missing something? According to "ifconfig wg21" command there is no inet6 (only inet 10.50.1.0).

I tried peer new ipv6=2001:XXXX:XXXX:dd20::1/64 and still ipv6 connectivity.
 
Last edited:
@pkoci @archiel you both maybee look at you ipv6 forward rules:
Code:
admin@RT-AC86U-D7D8:/tmp/home/root# ip6tables -nvL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destinati
on
    0     0 ACCEPT     all      br0    wg21    ::/0                 ::/0
            /* LAN to WireGuard 'server clients' */
    0     0 ACCEPT     all      wg21   *       ::/0                 ::/0
            /* WireGuard 'server' */

If you check this after having some traffic attempts, check for byte movements...
 
I checked ip6tables -nvL FORWARD and iptables -nvL FORWARD. There are no ip6tables rules related to wg21 network but iptables -nvL FORWARD show this:

pkts bytes target prot opt in out source destination

6 504 ACCEPT all -- br0 wg21 0.0.0.0/0 0.0.0.0/0 /* LAN to WireGuard 'server clients' */

22581 4156K ACCEPT all -- wg21 * 0.0.0.0/0 0.0.0.0/0 /* WireGuard 'server' */

Should I add to ip6tables something like this?:
target prot opt in out source destination

ACCEPT all -- br0 wg21 ::/0 ::/0 /* LAN to WireGuard 'server clients' */

ACCEPT all -- wg21 * ::/0 ::/0 /* WireGuard 'server' */
 
@pkoci @archiel you both maybee look at you ipv6 forward rules:
Code:
admin@RT-AC86U-D7D8:/tmp/home/root# ip6tables -nvL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destinati
on
    0     0 ACCEPT     all      br0    wg21    ::/0                 ::/0
            /* LAN to WireGuard 'server clients' */
    0     0 ACCEPT     all      wg21   *       ::/0                 ::/0
            /* WireGuard 'server' */

If you check this after having some traffic attempts, check for byte movements...
Will do next
I have run
Code:
 ip6tables -t nat -I POSTROUTING -s fd36:7ef1:2add:aa88::/64 -o eth0 -j SNAT --to-source 2a02:c7f:f0c3:1000::1
and checked
Code:
admin@RT-AX88U-5050:/tmp/home/root# ip6tables -nvL POSTROUTING -t nat
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  all      *      br0     fd36:7ef1:2add:aa88::/64  ::/0                 /* WireGuard 'server clients to LAN' */
    0     0 SNAT       all      *      eth0    fd36:7ef1:2add:aa88::/64  ::/0                 to:2a02:c7f:f0c3:1000::1
as wg21-up.sh is
Code:
#!/bin/sh
#Masquarade ipv6 packets from clients to WAN
#ip6tables -t nat -I POSTROUTING -s  fd36:7ef1:2add:aa88::1/64 -o eth0 -j MASQUERADE -m comment --comment "WireGuard 'server'"
#Masquarade ipv6 packets from clients to br0 (is this needed/wanted)?
#ip6tables -t nat -I POSTROUTING -s fd36:7ef1:2add:aa88::1/64 -o br0 -j MASQUERADE -m comment --comment "WireGuard 'server'"
I am not sure where the MASQUERADE response came from.

Still no ipv6 or ping responses on eth0
 
Before Ping
Code:
admin@RT-AX88U-5050:/tmp/home/root# ip6tables -nvL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all      br0    wg21    ::/0                 ::/0                 /* LAN to WireGuard 'server clients' */
    0     0 ACCEPT     all      wg21   *       ::/0                 ::/0                 /* WireGuard 'server' */
    0     0 REJECT     udp      br0    *       ::/0                 ::/0                 udp dpt:123 reject-with icmp6-port-unreachable
    0     0 REJECT     tcp      br0    *       ::/0                 ::/0                 tcp dpt:123 reject-with icmp6-port-unreachable
    0     0 ACCEPT     all      eth0   *       ::/0                 ff00::/8
 124K  128M ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED
  401  130K ACCEPT     all      br0    eth0    ::/0                 ::/0
    0     0 ACCEPT     all      br0    br0     ::/0                 ::/0
   61  5243 logdrop    all      *      *       ::/0                 ::/0                 state INVALID
    0     0 ACCEPT     59       *      *       ::/0                 ::/0                 length 40
    0     0 ICMP_V6    icmpv6    *      *       ::/0                 ::/0
   20  2025 OVPN       all      *      *       ::/0                 ::/0                 state NEW
   20  2025 logdrop    all      *      *       ::/0                 ::/0
After Ping
Code:
admin@RT-AX88U-5050:/tmp/home/root# ip6tables -nvL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all      br0    wg21    ::/0                 ::/0                 /* LAN to WireGuard 'server clients' */
    0     0 ACCEPT     all      wg21   *       ::/0                 ::/0                 /* WireGuard 'server' */
    0     0 REJECT     udp      br0    *       ::/0                 ::/0                 udp dpt:123 reject-with icmp6-port-unreachable
    0     0 REJECT     tcp      br0    *       ::/0                 ::/0                 tcp dpt:123 reject-with icmp6-port-unreachable
    0     0 ACCEPT     all      eth0   *       ::/0                 ff00::/8
 139K  143M ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED
  500  173K ACCEPT     all      br0    eth0    ::/0                 ::/0
    0     0 ACCEPT     all      br0    br0     ::/0                 ::/0
   63  5435 logdrop    all      *      *       ::/0                 ::/0                 state INVALID
    0     0 ACCEPT     59       *      *       ::/0                 ::/0                 length 40
    0     0 ICMP_V6    icmpv6    *      *       ::/0                 ::/0
   20  2025 OVPN       all      *      *       ::/0                 ::/0                 state NEW
   20  2025 logdrop    all      *      *       ::/0                 ::/0
 
Great, Also found some cosmetic stuff where the ipv6 goes through some transformation during creation but in the end turns out correct:
Code:
E:Option ==> peer new ip=192.168.100.1/24 ipv6=fdff:a37f:fa75:100::101/120
wg21.conf
#Address = 192.168.100.1/24,fdff:a37f:fa75:100::101/120
AllowedIPs = 192.168.100.2/32,fdff:a37f:fa75:100::2/128

myvpn.conf:
Address = 192.168.100.2/32,fdff:a37f:fa75:100::2/128[/CODE]

I was kind of thinking that the device would turn out ::102 but I guess wgm replaces the last numbers completally. Doesn't matter really.
I thought it prudent to ensure that IPv6 addresses are stored in the SQL database according to RFC 5952 rather than a variable format 'text' string.

i.e. According to https://datatracker.ietf.org/doc/html/rfc5952#section-1 (Hmmm????) a single IPv6 address can be 'text' string represented in many ways;
All of the following represent the same IPv6 address:

  • 2001:db8:0:0:1:0:0:1

  • 2001:0db8:0:0:1:0:0:1

  • 2001:db8::1:0:0:1

  • 2001:db8::0:1:0:0:1

  • 2001:0db8::1:0:0:1

  • 2001:db8:0:0:1::1

  • 2001:db8:0000:0:1::1

  • 2001:0DB8:0:0:1::1

which makes checking if the IP address was already assigned to a Road-Warrior 'device' difficult - hence despite your dismissive 'cosmetic' statement I perform the useful compression transformation if possible.

To determine which address should be assigned to the new Road-Warrior peer, by default wireguard_manager assumes that the 'server' Peer is assigned '.1', so assigns '.2' to the first 'device' Peer, then '.3' for the next and so on etc.

Originally, wireguard_manager simply issued a single SQL Count(*) request to return the number of 'device' Peers currently defined then simply added '1' to the count and used this for the new IP assignment.

However if 'device' Peers are deleted, wireguard_manager would potentially find the IP already assigned or leave gaps, so I changed to always try and maintain a contiguous range starting @ '.2' with no gaps.

Clearly, providing custom 'server' Peer base addresses > '.1' isn't currently catered for as shown in your 'bug' report.

Perhaps it is indeed prudent to start the search from the base address - in your case '.101' for IPv6, yet '.1' for IPv4 rather than '.101'?

...but being lazy, suppose the IPv6 base was 'FFFF', then it's tedious rolling over the correct subnet, but for IPv6 '.101' it may make sense to start from '.102'

Possibly a candidate for wireguard_manager Beta v4.16b2 ?
 
Well... for some reason this partially worked:

peer new ip=10.50.1.1/24 ipv6=2001:XXXX:XXXX:ffd4::/64
peer wg21 auto=Y
create iphone wg21

Unfortunately, test-ipv6.com says no ipv6 connectivity. Am I missing something? According to "ifconfig wg21" command there is no inet6 (only inet 10.50.1.0).

I tried peer new ipv6=2001:XXXX:XXXX:dd20::1/64 and still ipv6 connectivity.
What router / firmware, other scripts (mine are in the signature apart from WireGuard)?
Also what WAN/IPv6 settings - I am bridged to the modem, WAN set to Automatic IP and using an Option 61 Client Identifier
For IPv6 Native, DHCP-PD, Stateless, OpenDNS servers, Router Advertisement enabled.
 
I thought it prudent to ensure that IPv6 addresses are stored in the SQL database according to RFC 5952 rather than a variable format 'text' string.

i.e. According to https://datatracker.ietf.org/doc/html/rfc5952#section-1 (Hmmm????) a single IPv6 address can be 'text' string represented in many ways;
All of the following represent the same IPv6 address:

  • 2001:db8:0:0:1:0:0:1

  • 2001:0db8:0:0:1:0:0:1

  • 2001:db8::1:0:0:1

  • 2001:db8::0:1:0:0:1

  • 2001:0db8::1:0:0:1

  • 2001:db8:0:0:1::1

  • 2001:db8:0000:0:1::1

  • 2001:0DB8:0:0:1::1

which makes checking if the IP address was already assigned to a Road-Warrior 'device' difficult - hence despite your dismissive 'cosmetic' statement I perform the useful compression transformation if possible.

To determine which address should be assigned to the new Road-Warrior peer, by default wireguard_manager assumes that the 'server' Peer is assigned '.1', so assigns '.2' to the first 'device' Peer, then '.3' for the next and so on etc.

Originally, wireguard_manager simply issued a single SQL Count(*) request to return the number of 'device' Peers currently defined then simply added '1' to the count and used this for the new IP assignment.

However if 'device' Peers are deleted, wireguard_manager would potentially find the IP already assigned or leave gaps, so I changed to always try and maintain a contiguous range starting @ '.2' with no gaps.

Clearly, providing custom 'server' Peer base addresses > '.1' isn't currently catered for as shown in your 'bug' report.

Perhaps it is indeed prudent to start the search from the base address - in your case '.101' for IPv6, yet '.1' for IPv4 rather than '.101'?

...but being lazy, suppose the IPv6 base was 'FFFF', then it's tedious rolling over the correct subnet, but for IPv6 '.101' it may make sense to start from '.102'

Possibly a candidate for wireguard_manager Beta v4.16b2 ?
The device address is not really important, as long as we know, we could work around it. I indeed understand the difficulties for doing this.

The cosmetic part is that wg21 ip requested as
Code:
fdff:a37f:fa75:100::101
Is correct and applied correct to wg21 but when Requesting wg21 to start it display it as
Code:
fdff:a37f:fa75:1::1
But it appears cosmetic since wg21 and wg21.conf contains and uses the right address.
 
Before Ping
Code:
admin@RT-AX88U-5050:/tmp/home/root# ip6tables -nvL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all      br0    wg21    ::/0                 ::/0                 /* LAN to WireGuard 'server clients' */
    0     0 ACCEPT     all      wg21   *       ::/0                 ::/0                 /* WireGuard 'server' */
    0     0 REJECT     udp      br0    *       ::/0                 ::/0                 udp dpt:123 reject-with icmp6-port-unreachable
    0     0 REJECT     tcp      br0    *       ::/0                 ::/0                 tcp dpt:123 reject-with icmp6-port-unreachable
    0     0 ACCEPT     all      eth0   *       ::/0                 ff00::/8
124K  128M ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED
  401  130K ACCEPT     all      br0    eth0    ::/0                 ::/0
    0     0 ACCEPT     all      br0    br0     ::/0                 ::/0
   61  5243 logdrop    all      *      *       ::/0                 ::/0                 state INVALID
    0     0 ACCEPT     59       *      *       ::/0                 ::/0                 length 40
    0     0 ICMP_V6    icmpv6    *      *       ::/0                 ::/0
   20  2025 OVPN       all      *      *       ::/0                 ::/0                 state NEW
   20  2025 logdrop    all      *      *       ::/0                 ::/0
After Ping
Code:
admin@RT-AX88U-5050:/tmp/home/root# ip6tables -nvL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all      br0    wg21    ::/0                 ::/0                 /* LAN to WireGuard 'server clients' */
    0     0 ACCEPT     all      wg21   *       ::/0                 ::/0                 /* WireGuard 'server' */
    0     0 REJECT     udp      br0    *       ::/0                 ::/0                 udp dpt:123 reject-with icmp6-port-unreachable
    0     0 REJECT     tcp      br0    *       ::/0                 ::/0                 tcp dpt:123 reject-with icmp6-port-unreachable
    0     0 ACCEPT     all      eth0   *       ::/0                 ff00::/8
139K  143M ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED
  500  173K ACCEPT     all      br0    eth0    ::/0                 ::/0
    0     0 ACCEPT     all      br0    br0     ::/0                 ::/0
   63  5435 logdrop    all      *      *       ::/0                 ::/0                 state INVALID
    0     0 ACCEPT     59       *      *       ::/0                 ::/0                 length 40
    0     0 ICMP_V6    icmpv6    *      *       ::/0                 ::/0
   20  2025 OVPN       all      *      *       ::/0                 ::/0                 state NEW
   20  2025 logdrop    all      *      *       ::/0                 ::/0
Ok, so the package never gets forwarded through the forward Chain... Thats why nothing is working. Actually the package doesn't even reach the forward chain. This is not a masquarade problem but something else prevents the package from being forwarded.

So, either the interface drops it (ifconfig wg21) or the PREROUTING Chain is dropping it.

These are the tables the package is traversing before:
Code:
ip6tables -nvL PREROUTING -t nat
ip6tables -nvL PREROUTING -t mangle
ip6tables -nvL FORWARD -t mangle

Check if there are any rules there that might block.

Also check dropped package counter on wg21 interface if it increase when you Ping.
 
I have 2x RT-56u with 386.5 (at home and office). The first one has static ipv6 with prefix /48 stateless, Router Advertisement enabled, advertising adguards DNS, no scripts. The second one runs 6in4 he tunnel with /48 prefix, Router Advertisement enabled, advertising adguards DNS, no scripts.

Same problems
 
The device address is not really important, as long as we know, we could work around it. I indeed understand the difficulties for doing this.

The cosmetic part is that wg21 ip requested as
Code:
fdff:a37f:fa75:100::101
Is correct and applied correct to wg21 but when Requesting wg21 to start it display it as
Code:
fdff:a37f:fa75:1::1
But it appears cosmetic since wg21 and wg21.conf contains and uses the right address.
Ahhh, you mean that the message
Code:
wireguard-server1: Initialising Wireguard VPN (IPv6) [fdff:a37f:fa75:1::1] 'Server' Peer (wg21) on 100.126.96.1:11501 (# RT-AC86U (IPv4/IPv6) Server 1)
should actually include the IPv6 'server' Peer tunnel socket together with the IPv4 IP as you have defined a Dual-stack
i.e.
Code:
wireguard-server1: Initialising Wireguard VPN (IPv6) [fdff:a37f:fa75:1::1] 'Server' Peer (wg21) on 100.126.96.1,fdff:a37f:fa75:100::101:11501 (# RT-AC86U (IPv4/IPv6) Server 1)
where the value in between the square brackets '[ ]' is naively o_O assumed to be the IPv6 WAN IP :rolleyes:derived as follows:
Code:
WAN_IPV6=$(ip -6 addr | sed -ne 's|^.* inet6 \([^/]*\)/.* scope global.*$|\1|p' | head -1)
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top