What's new

Wireguard Session Manager (4th) 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!

Just to make sure wg11 ipv6 works, I tried the following commands:
Yep, looks like wg11 ipv6 is working and you can see packet count increase on lan to wg11 on the masquarade rule.

What happens if you try the same from your server clients that are bypassed, do the packet count go up or stay at 0?
 
Yep, looks like wg11 ipv6 is working and you can see packet count increase on lan to wg11 on the masquarade rule.

What happens if you try the same from your server clients that are bypassed, do the packet count go up or stay at 0?

They stay at 0. From my wireguard client, I receive the following message:

Code:
-- 27 abr. 2023 9:48:45
--- IP (rmnet_data2) 10.114.78.102
--- IP (tun0) aa65:a7b6:23ff:100::2
--- IP (tun0) 10.50.2.2
--- Connection: LTE

PING ipv6.google.com(par10s22-in-x0e.1e100.net) 56 data bytes
From aa65:a7b6:23ff:100::1 icmp_seq=1 Destination unreachable: Address unreachable

--- ipv6.google.com ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

and the counter remains being 0:

Code:
juanantonio@RT-AX86U-6C38:/jffs/addons/wireguard/Scripts# ip6tables -nvL POSTROUTING -t nat
Chain POSTROUTING (policy ACCEPT 293 packets, 31563 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  all      *      ppp0    aa65:a7b6:23ff:100::/120  ::/0                 /* WireGuard 'server' */
    0     0 MASQUERADE  all      *      wg11    2a0c:5a80:4601:e00::/64  ::/0                 /* WireGuard 'client' */
    0     0 MASQUERADE  all      *      br0     aa65:a7b6:23ff:100::/120  ::/0                 /* WireGuard 'server clients to LAN' */
   27  2248 MASQUERADE  all      *      ppp0    fd00:ac68:1::/64     ::/0
    0     0 MASQUERADE  all      *      wg11    aa65:a7b6:23ff:100::2/128  ::/0
    0     0 MASQUERADE  all      *      ppp0    aa65:a7b6:23ff:100::/120  ::/0                 /* WireGuard 'server' */

Edit: I'm in doubt about my phone being able to work under IPv6 on LTE network. Anyway, it works under IPv6 on WiFi network and that made me think that.
Next Saturday (the day after tomorrow), I will be able to try a full IPv6 compliant equipment in another location. I will maintain you informed.

Many thanks.
 
Last edited:
Edit: I'm in doubt about my phone being able to work under IPv6 on LTE network. Anyway, it works under IPv6 on WiFi network and that made me think that.
The tunnel is over ipv4 and should provide ipv4 and ipv6 connection... I have the same on my phone, ipv4 only cell data but I get ipv6 whenever connected to my vpn server, so I should work.


and the counter remains being 0:
yep, so the packets never reaches here... you may need to check the firewall forward chain for what rules are there:
Code:
ip6tables -nvL FORWARD
there should be a similar packet count on the rule that allows wg server to anywhere, see if your request reaches this point.
 
The tunnel is over ipv4 and should provide ipv4 and ipv6 connection... I have the same on my phone, ipv4 only cell data but I get ipv6 whenever connected to my vpn server, so I should work.



yep, so the packets never reaches here... you may need to check the firewall forward chain for what rules are there:
Code:
ip6tables -nvL FORWARD
there should be a similar packet count on the rule that allows wg server to anywhere, see if your request reaches this point.

Well, I've pinged the address my VPN provides me from the phone and I got response:

Code:
--- 27 abr. 2023 12:50:15
--- IP (rmnet_data2) 10.114.78.102
--- IP (tun0) aa65:a7b6:23ff:100::2
--- IP (tun0) 10.50.2.2
--- Connection: LTE

PING fd7d:76ee:e68f:a993:d0c0:1334:273a:628b(fd7d:76ee:e68f:a993:d0c0:1334:273a:628b) 56 data bytes
64 bytes from fd7d:76ee:e68f:a993:d0c0:1334:273a:628b: icmp_seq=1 ttl=64 time=54.5 ms
64 bytes from fd7d:76ee:e68f:a993:d0c0:1334:273a:628b: icmp_seq=2 ttl=64 time=60.4 ms
64 bytes from fd7d:76ee:e68f:a993:d0c0:1334:273a:628b: icmp_seq=3 ttl=64 time=60.3 ms
64 bytes from fd7d:76ee:e68f:a993:d0c0:1334:273a:628b: icmp_seq=4 ttl=64 time=82.8 ms

--- fd7d:76ee:e68f:a993:d0c0:1334:273a:628b ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3056ms
min = 54.515 ms
avg = 64.528 ms
max = 82.838 ms
mdev = 10.841 ms

However, if I want to ping other addresses, even my VPN IPv6 public address, I got no response:

Code:
--- 27 abr. 2023 12:51:43
--- IP (rmnet_data2) 10.114.78.102
--- IP (tun0) aa65:a7b6:23ff:100::2
--- IP (tun0) 10.50.2.2
--- Connection: LTE

PING ipv6.google.com(par10s42-in-x0e.1e100.net) 56 data bytes
From aa65:a7b6:23ff:100::1 icmp_seq=1 Destination unreachable: Address unreachable

--- ipv6.google.com ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms


The counter of forwarded packets is starting to show something different to 0:

Code:
juanantonio@RT-AX86U-6C38:/tmp/mnt/Entware/entware/etc/wireguard.d# ip6tables -nvL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  513 55738 ACCEPT     all      br0    wg22    ::/0                 ::/0                 /* LAN to WireGuard 'server clients' */
   53 16584 ACCEPT     all      wg22   *       ::/0                 ::/0                 /* WireGuard 'server' */
    0     0 ACCEPT     all      br2    wg11    ::/0                 ::/0                 /* WireGuard Guest_VLAN */
    0     0 ACCEPT     all      br1    wg11    ::/0                 ::/0                 /* WireGuard Guest_VLAN */
10233  731K TCPMSS     tcp      *      *       ::/0                 ::/0                 tcpflags: 0x06/0x02 TCPMSS clamp to PMTU
 216K  143M ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED
 6821  623K WGSF       all      *      *       ::/0                 ::/0
 6821  623K OVPNSF     all      *      *       ::/0                 ::/0
    0     0 WGNPControls  all      br1    *       ::/0                 ::/0
    0     0 WGNPControls  all      br1    *       ::/0                 ::/0
  214 22237 ACCEPT     all      br0    ppp0    ::/0                 ::/0
    0     0 ACCEPT     all      br0    br0     ::/0                 ::/0
  165 14569 DROP       all      *      *       ::/0                 ::/0                 state INVALID
  206 15257 ACCEPT     all      br0    wg11    ::/0                 ::/0                 /* LAN to WireGuard 'client' */
   29  2858 ACCEPT     all      br0    *       ::/0                 ::/0                 /* Fix LAN to ANY by Martineau */
    0     0 ACCEPT     59       *      *       ::/0                 ::/0                 length 40
    0     0 ICMP_V6    icmpv6    *      *       ::/0                 ::/0
    4   388 WGCF       all      *      *       ::/0                 ::/0
    4   388 OVPNCF     all      *      *       ::/0                 ::/0
    4   388 DROP       all      *      *       ::/0                 ::/0

But not the one from postrouted packets:
Code:
juanantonio@RT-AX86U-6C38:/tmp/mnt/Entware/entware/etc/wireguard.d# ip6tables -nvL POSTROUTING -t nat
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  215 15929 MASQUERADE  all      *      wg11    2a0c:5a80:4601:e00::/64  ::/0                 /* WireGuard 'client' */
    0     0 MASQUERADE  all      *      wg11    aa65:a7b6:23ff:100::/120  ::/0
   27  2248 MASQUERADE  all      *      ppp0    fd00:ac68:1::/64     ::/0
    0     0 MASQUERADE  all      *      wg11    aa65:a7b6:23ff:100::2/128  ::/0

And, if I want to traceroute whatever IPv6 site outside my router, I have this:

Code:
--- 27 abr. 2023 13:25:31
--- IP (rmnet_data2) 10.114.78.102
--- IP (tun0) aa65:a7b6:23ff:100::2
--- IP (tun0) 10.50.2.2
--- Connection: LTE

Trace to 2a01:4f8:10a:2d59::5

1 - aa65:a7b6:23ff:100::1
2 - aa65:a7b6:23ff:100::1
3 - aa65:a7b6:23ff:100::1
4 - aa65:a7b6:23ff:100::1
5 - aa65:a7b6:23ff:100::1
6 - aa65:a7b6:23ff:100::1
7 - aa65:a7b6:23ff:100::1
8 - aa65:a7b6:23ff:100::1
9 - aa65:a7b6:23ff:100::1
10 - aa65:a7b6:23ff:100::1
11 - aa65:a7b6:23ff:100::1
12 - aa65:a7b6:23ff:100::1
13 - aa65:a7b6:23ff:100::1
14 - aa65:a7b6:23ff:100::1
15 - aa65:a7b6:23ff:100::1
16 - aa65:a7b6:23ff:100::1
17 - aa65:a7b6:23ff:100::1
18 - aa65:a7b6:23ff:100::1
19 - aa65:a7b6:23ff:100::1
20 - aa65:a7b6:23ff:100::1
21 - aa65:a7b6:23ff:100::1
22 - aa65:a7b6:23ff:100::1
23 - aa65:a7b6:23ff:100::1
24 - aa65:a7b6:23ff:100::1
25 - aa65:a7b6:23ff:100::1
26 - aa65:a7b6:23ff:100::1
27 - aa65:a7b6:23ff:100::1
28 - aa65:a7b6:23ff:100::1
29 - aa65:a7b6:23ff:100::1


The only sites I reach are the wg22 server interface or the IPv6 address my VPN provider is giving to me (this in only one hop):

Code:
--- 27 abr. 2023 13:26:46
--- IP (rmnet_data2) 10.114.78.102
--- IP (tun0) aa65:a7b6:23ff:100::2
--- IP (tun0) 10.50.2.2
--- Connection: LTE

Trace to fd7d:76ee:e68f:a993:d0c0:1334:273a:628b

1 - fd7d:76ee:e68f:a993:d0c0:1334:273a:628b
 
Last edited:
Well, I've pinged the address my VPN provides me from the phone and I got response:

Code:
--- 27 abr. 2023 12:50:15
--- IP (rmnet_data2) 10.114.78.102
--- IP (tun0) aa65:a7b6:23ff:100::2
--- IP (tun0) 10.50.2.2
--- Connection: LTE

PING fd7d:76ee:e68f:a993:d0c0:1334:273a:628b(fd7d:76ee:e68f:a993:d0c0:1334:273a:628b) 56 data bytes
64 bytes from fd7d:76ee:e68f:a993:d0c0:1334:273a:628b: icmp_seq=1 ttl=64 time=54.5 ms
64 bytes from fd7d:76ee:e68f:a993:d0c0:1334:273a:628b: icmp_seq=2 ttl=64 time=60.4 ms
64 bytes from fd7d:76ee:e68f:a993:d0c0:1334:273a:628b: icmp_seq=3 ttl=64 time=60.3 ms
64 bytes from fd7d:76ee:e68f:a993:d0c0:1334:273a:628b: icmp_seq=4 ttl=64 time=82.8 ms

--- fd7d:76ee:e68f:a993:d0c0:1334:273a:628b ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3056ms
min = 54.515 ms
avg = 64.528 ms
max = 82.838 ms
mdev = 10.841 ms

However, if I want to ping other addresses, even my VPN IPv6 public address, I got no response:

Code:
--- 27 abr. 2023 12:51:43
--- IP (rmnet_data2) 10.114.78.102
--- IP (tun0) aa65:a7b6:23ff:100::2
--- IP (tun0) 10.50.2.2
--- Connection: LTE

PING ipv6.google.com(par10s42-in-x0e.1e100.net) 56 data bytes
From aa65:a7b6:23ff:100::1 icmp_seq=1 Destination unreachable: Address unreachable

--- ipv6.google.com ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms


The counter of forwarded packets is starting to show something different to 0:

Code:
juanantonio@RT-AX86U-6C38:/tmp/mnt/Entware/entware/etc/wireguard.d# ip6tables -nvL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  513 55738 ACCEPT     all      br0    wg22    ::/0                 ::/0                 /* LAN to WireGuard 'server clients' */
   53 16584 ACCEPT     all      wg22   *       ::/0                 ::/0                 /* WireGuard 'server' */
    0     0 ACCEPT     all      br2    wg11    ::/0                 ::/0                 /* WireGuard Guest_VLAN */
    0     0 ACCEPT     all      br1    wg11    ::/0                 ::/0                 /* WireGuard Guest_VLAN */
10233  731K TCPMSS     tcp      *      *       ::/0                 ::/0                 tcpflags: 0x06/0x02 TCPMSS clamp to PMTU
 216K  143M ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED
 6821  623K WGSF       all      *      *       ::/0                 ::/0
 6821  623K OVPNSF     all      *      *       ::/0                 ::/0
    0     0 WGNPControls  all      br1    *       ::/0                 ::/0
    0     0 WGNPControls  all      br1    *       ::/0                 ::/0
  214 22237 ACCEPT     all      br0    ppp0    ::/0                 ::/0
    0     0 ACCEPT     all      br0    br0     ::/0                 ::/0
  165 14569 DROP       all      *      *       ::/0                 ::/0                 state INVALID
  206 15257 ACCEPT     all      br0    wg11    ::/0                 ::/0                 /* LAN to WireGuard 'client' */
   29  2858 ACCEPT     all      br0    *       ::/0                 ::/0                 /* Fix LAN to ANY by Martineau */
    0     0 ACCEPT     59       *      *       ::/0                 ::/0                 length 40
    0     0 ICMP_V6    icmpv6    *      *       ::/0                 ::/0
    4   388 WGCF       all      *      *       ::/0                 ::/0
    4   388 OVPNCF     all      *      *       ::/0                 ::/0
    4   388 DROP       all      *      *       ::/0                 ::/0

But not the one from postrouted packets:
Code:
juanantonio@RT-AX86U-6C38:/tmp/mnt/Entware/entware/etc/wireguard.d# ip6tables -nvL POSTROUTING -t nat
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  215 15929 MASQUERADE  all      *      wg11    2a0c:5a80:4601:e00::/64  ::/0                 /* WireGuard 'client' */
    0     0 MASQUERADE  all      *      wg11    aa65:a7b6:23ff:100::/120  ::/0
   27  2248 MASQUERADE  all      *      ppp0    fd00:ac68:1::/64     ::/0
    0     0 MASQUERADE  all      *      wg11    aa65:a7b6:23ff:100::2/128  ::/0

And, if I want to traceroute whatever IPv6 site outside my router, I have this:

Code:
--- 27 abr. 2023 13:25:31
--- IP (rmnet_data2) 10.114.78.102
--- IP (tun0) aa65:a7b6:23ff:100::2
--- IP (tun0) 10.50.2.2
--- Connection: LTE

Trace to 2a01:4f8:10a:2d59::5

1 - aa65:a7b6:23ff:100::1
2 - aa65:a7b6:23ff:100::1
3 - aa65:a7b6:23ff:100::1
4 - aa65:a7b6:23ff:100::1
5 - aa65:a7b6:23ff:100::1
6 - aa65:a7b6:23ff:100::1
7 - aa65:a7b6:23ff:100::1
8 - aa65:a7b6:23ff:100::1
9 - aa65:a7b6:23ff:100::1
10 - aa65:a7b6:23ff:100::1
11 - aa65:a7b6:23ff:100::1
12 - aa65:a7b6:23ff:100::1
13 - aa65:a7b6:23ff:100::1
14 - aa65:a7b6:23ff:100::1
15 - aa65:a7b6:23ff:100::1
16 - aa65:a7b6:23ff:100::1
17 - aa65:a7b6:23ff:100::1
18 - aa65:a7b6:23ff:100::1
19 - aa65:a7b6:23ff:100::1
20 - aa65:a7b6:23ff:100::1
21 - aa65:a7b6:23ff:100::1
22 - aa65:a7b6:23ff:100::1
23 - aa65:a7b6:23ff:100::1
24 - aa65:a7b6:23ff:100::1
25 - aa65:a7b6:23ff:100::1
26 - aa65:a7b6:23ff:100::1
27 - aa65:a7b6:23ff:100::1
28 - aa65:a7b6:23ff:100::1
29 - aa65:a7b6:23ff:100::1


The only sites I reach are the wg22 server interface or the IPv6 address my VPN provider is giving to me (this in only one hop):

Code:
--- 27 abr. 2023 13:26:46
--- IP (rmnet_data2) 10.114.78.102
--- IP (tun0) aa65:a7b6:23ff:100::2
--- IP (tun0) 10.50.2.2
--- Connection: LTE

Trace to fd7d:76ee:e68f:a993:d0c0:1334:273a:628b

1 - fd7d:76ee:e68f:a993:d0c0:1334:273a:628b
hmm... feels like it's staring me right in the face, yet I cant see it.... almost like wg22 refuses to forward the packets, wierd....

what if you add a more specific rule in the forward chain, filter table just to monitor the packet count and validate that your pings are actually what we are seing:
(just execute directly from the router ssh prompt, it will be removed at first reboot or firewall reset, but we only need it for our test)
Code:
ip6tables -t filter -I FORWARD -s aa65:17b6:23ff:100::2 -o wg11 -j ACCEPT
this would count packets from address aa65:17b6:23ff:100::2 (your wg22 client) on it's way to wg11.

you could see it from the same command as before, should be right up on the top of the list.

then test again to ping some other internet ipv6, like 2600:: (this is usually ping-able) from your wg22 client and see if the count goes up.
 
hmm... feels like it's staring me right in the face, yet I cant see it.... almost like wg22 refuses to forward the packets, wierd....

what if you add a more specific rule in the forward chain, filter table just to monitor the packet count and validate that your pings are actually what we are seing:
(just execute directly from the router ssh prompt, it will be removed at first reboot or firewall reset, but we only need it for our test)
Code:
ip6tables -t filter -I FORWARD -s aa65:17b6:23ff:100::2 -o wg11 -j ACCEPT
this would count packets from address aa65:17b6:23ff:100::2 (your wg22 client) on it's way to wg11.

you could see it from the same command as before, should be right up on the top of the list.

then test again to ping some other internet ipv6, like 2600:: (this is usually ping-able) from your wg22 client and see if the count goes up.
Very glad to hear from you so soon.

Here is the output of the ip6tables command after pinging it from my wg22 client to 2600::

Code:
juanantonio@RT-AX86U-6C38:/tmp/mnt/Entware/entware/etc/wireguard.d# ip6tables -nvL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all      *      wg11    aa65:17b6:23ff:100::2/128  ::/0
    0     0 ACCEPT     all      br2    wg11    ::/0                 ::/0                 /* WireGuard Guest_VLAN */
    0     0 ACCEPT     all      br1    wg11    ::/0                 ::/0                 /* WireGuard Guest_VLAN */
  699 67614 ACCEPT     all      br0    wg22    ::/0                 ::/0                 /* LAN to WireGuard 'server clients' */
  217 37099 ACCEPT     all      wg22   *       ::/0                 ::/0                 /* WireGuard 'server' */
    0     0 ACCEPT     all      br0    wg21    ::/0                 ::/0                 /* LAN to WireGuard 'server clients' */
    0     0 ACCEPT     all      wg21   *       ::/0                 ::/0                 /* WireGuard 'server' */
13775  983K TCPMSS     tcp      *      *       ::/0                 ::/0                 tcpflags: 0x06/0x02 TCPMSS clamp to PMTU
 275K  169M ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED
 8646  767K WGSF       all      *      *       ::/0                 ::/0
 8646  767K OVPNSF     all      *      *       ::/0                 ::/0
    0     0 WGNPControls  all      br1    *       ::/0                 ::/0
    0     0 WGNPControls  all      br1    *       ::/0                 ::/0
  224 23020 ACCEPT     all      br0    ppp0    ::/0                 ::/0
    0     0 ACCEPT     all      br0    br0     ::/0                 ::/0
  208 17275 DROP       all      *      *       ::/0                 ::/0                 state INVALID
    0     0 ACCEPT     all      br0    wg11    ::/0                 ::/0                 /* LAN to WireGuard 'client' */
   36  3667 ACCEPT     all      br0    *       ::/0                 ::/0                 /* Fix LAN to ANY by Martineau */
    0     0 ACCEPT     59       *      *       ::/0                 ::/0                 length 40
    0     0 ICMP_V6    icmpv6    *      *       ::/0                 ::/0
    4   388 WGCF       all      *      *       ::/0                 ::/0
    4   388 OVPNCF     all      *      *       ::/0                 ::/0
    4   388 DROP       all      *      *       ::/0                 ::/0

As you can see, counter keeps showing zero.

Would it help if I changed the masquerade rule in wg22-up.sh from:

Code:
WanInterface=ppp0

to:

Code:
WanInterface=wg11

?

From my complete ignorance, I can't understand why I have to route my wg22 client to my WAN interface, providing that I want this client to go through Wireguard Client's connection.

Best regards.
 
As you can see, counter keeps showing zero.
Yep, packets are not reaching this far even (postrouting comes after this). So either the packets dissappear during routing (unlikely) or they never leave wg22.

What do you get from:
Code:
ifconfig wg22
?

Would it help if I changed the masquerade rule in wg22-up.sh from:

Code:
WanInterface=ppp0
to:

Code:
WanInterface=wg11
?
Nope, packets are not even reaching this point so this is not your issue.

From my complete ignorance, I can't understand why I have to route my wg22 client to my WAN interface, providing that I want this client to go through Wireguard Client's connection.
Masquarade is not the same as routing. Your wg22 modified ula address cant exist on the global internet and from your vpn you typically only get a single ula address and your vpn supplier only accepts packets with the same source address then the interface. So the masquarade rule changes source address to target interface when it matches.
For your wan you get a prefix and it accepts any ip with the same prefix, but it will not accept your modified ula, so without the masquarade rule its not going to work to talk to wan (and as long as you bypass to wg11 it does not have to work).
Your ip6tables rules confirmes that wgm already handles masquarade rule wg22 to wg11 as a part of passthru, so you dont need to add redundant rules.

I like to set things up so they behave proper to future events. Say a year from now you decide that passtru is not needed and you will completally loose ipv6 and you have to go through this mess again of figuring out what is missing or maybe you think something broke... to avoid this I like to setup system so they dont only work now, but their natural behaviour works even though I may not use it right now. I dont know if it makes sense, but do with it as you wish. The masquarade rule will be needed for ipv6 connectivity of wg22 clients if/when you remove passtru rule.
 
What do you get from:
Code:
ifconfig wg22
?

I got:

Code:
juanantonio@RT-AX86U-6C38:/tmp/mnt/Entware/entware/etc/wireguard.d# ifconfig wg22
wg22      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.50.2.1  P-t-P:10.50.2.1  Mask:255.255.255.0
          inet6 addr: aa65:a7b6:23ff:100::1/120 Scope:Global
          UP POINTOPOINT RUNNING NOARP  MTU:1420  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:174 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

I dont know if it makes sense, but do with it as you wish. The masquarade rule will be needed for ipv6 connectivity of wg22 clients if/when you remove passtru rule.
For me, it makes a lot of sense. Let's do things the more stable possible.


I was wondering if it is possible to change my wg22 server ipv6 even if I need to start it from scratch.

I liked the possibility of assigning it a subnet of my ISP more than the other possibilities.

The only thing is that I don't know much about IPv6 addresses.

I didn't know if mine is static, dynamic or even my own IPv6 subnet range.

Now I know I'm assigned a /56 IPv6 address each time I reboot my router, so I would like to assign this wg22 server a subnet of my own IPv6 address, if possible. Only for giving it a try, just in case it works.

Many thanks again, you are helping me a lot. But for your help, I wouldn't know nothing about IP6.


Edit: I started a new server wg23 from scratch. I assigned it a subnet of my own ISP IP6 adress. I did passthru between it and my wg12 client (I created a new one). And voila!

Basically, these are the steps I've followed.

Code:
peer new ipv6=2a0c:5a80:xxxx:xxxx:1::1/120 ip=10.50.3.1/24 /*ipv6 calculated according to ZebMcKayhan unvaluable tutorial*/
peer XiaomiMiMix2S del
create XiaomiMiMix2S wg23
peer wg23 auto=Y
peer wg23 passthru add wg12 XiaomiMiMix2S
restart wg23

and after that, the counter started to count and I have IP6 connection on my wg client!!!

Code:
juanantonio@RT-AX86U-6C38:/tmp/mnt/Entware/entware/etc/wireguard.d# ip6tables -nvL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
   21  3232 ACCEPT     all      *      wg12    xxxx:5a80:xxxx:e00:1::2  ::/0

@ZebMcKayhan, this really deserves a ton of thanks!

Best regards.
 
Last edited:
Wierd... are you sure your client are connected properly?? Aargh, sure you are, ipv4 work, this does not make any sense, everything looks normal... how does your config looks (wg22.conf and your client .conf, make sure to remove your keys, we dont want them here)?

I liked the possibility of assigning it a subnet of my ISP more than the other possibilities.
Sure, and it would work just fine (to wan) until your prefix changes. It should always work as long as you keep your passthru rule (eeh, atleast I think so, perhaps a reboot to check?)

Edit: I started a new server wg23 from scratch. I assigned it a subnet of my own ISP IP6 adress. I did passthru between it and my wg12 client (I created a new one). And voila!
Thats great, still leaves your problems unrevealed though, pity... maybe just the recretion of everything...

and after that, the counter started to count and I have IP6 connection on my wg client!!!
Thats great, Im really glad for you. You might consider adding the masquarade rule to ppp0, as when your prefix changes wg22 wont work to lan if you ever need to run without passtru.

@ZebMcKayhan, this really deserves a ton of thanks!
Thanks, I do my best.
 
Thats great, Im really glad for you. You might consider adding the masquarade rule to ppp0, as when your prefix changes wg22 wont work to lan if you ever need to run without passtru.
The masquerade rule for ppp0 is there from the beginning. Under no circumstances I'm going to delete it.

Sure, and it would work just fine (to wan) until your prefix changes. It should always work as long as you keep your passthru rule (eeh, atleast I think so, perhaps a reboot to check?)

Well, I did a reboot this morning and the setup keeps working. As long as I maintain the rules (passthru, masquerade, etc.), I think it will last and work in the way it's working now.
 
Is it possible to duplicate rules from wg11 to wgXX?
You will need to manually issue the following SQL command
Code:
sqlite3 /opt/etc/wireguard.d/WireGuard.db "INSERT INTO policy (peer,iface,srcip,dstip,tag) SELECT 'wgXX',iface,srcip,dstip,tag FROM policy WHERE peer='wg11';"
and you should be able to see the raw 'wgXX' records cloned from 'wg11'
Code:
sqlite3 /opt/etc/wireguard.d/WireGuard.db "SELECT * FROM policy ORDER BY iface DESC;"

NOTE: To manually erase the cloned rules for interface 'wgXX'
Code:
sqlite3 /opt/etc/wireguard.d/WireGuard.db "DELETE FROM policy WHERE peer='wgXX';"
 
You will need to manually issue the following SQL command
Code:
sqlite3 /opt/etc/wireguard.d/WireGuard.db "INSERT INTO policy (peer,iface,srcip,dstip,tag) SELECT 'wgXX',iface,srcip,dstip,tag FROM policy WHERE peer='wg11';"
and you should be able to see the raw 'wgXX' records cloned from 'wg11'
Code:
sqlite3 /opt/etc/wireguard.d/WireGuard.db "SELECT * FROM policy ORDER BY iface DESC;"

NOTE: To manually erase the cloned rules for interface 'wgXX'
Code:
sqlite3 /opt/etc/wireguard.d/WireGuard.db "DELETE FROM policy WHERE peer='wgXX';"
Thank you!
 
there is always a way, but this is where the connection-less nature of wireguard makes it more difficult.

@Martineau has made a script for fail-over, which is kind of what you want:
https://github.com/MartineauUK/VPN-Failover
but it is written for Open-VPN so it may take some work to redo it for Wireguard. would probably be easier to throw together something yourself...
PS.

Found this: https://www.snbforums.com/threads/wireguard-client-vpn-failover-script.82333/
 
Hello I am using wgm, it is working pretty well.
Except I have a message "
iptables v1.4.15: mark: bad mark value for option "--mark", or out of range."
Could it be linked to the fact I have disabled ipv6?
 
Hello I am using wgm, it is working pretty well.
Except I have a message "
iptables v1.4.15: mark: bad mark value for option "--mark", or out of range."
Could it be linked to the fact I have disabled ipv6?
Unlikely. What router do you have? Are you using ipsets? Server or client?

What output do you get from starting vpn with debug? I.e start wg11 debug

Note: redact any public ip or keys before posting.
 
Bash:
    Requesting WireGuard® VPN Peer start (wg11)

    wg_manager-clientwg11: Initialising WireGuard® VPN 'client' Peer (wg11) in Policy Mode to xxxxxxx:51820 (# N/A) DNS=
[#] ip link add dev wg11 type wireguard
[#] wg setconf wg11 /tmp/wg11.2661 #(/opt/etc/wireguard.d/wg11.conf)
[#] ip address add dev wg11 xxxxxxxxxx
[#] ip link set up dev wg11
[ ] Auto MTU:1420 determined by WireGuard®
[#] ifconfig wg11 txqueuelen 1000
[#] ip route add xxxxxxxxx via 192.168.0.1
[#] ip route add 0/1 dev wg11 table 121
[#] ip route add 128/1 dev wg11 table 121
[#] ip route add table 121 8.8.4.4 via 192.168.50.1 scope link metric 3 dev br0
[#] ip route add table 121 8.8.8.8 via 192.168.50.1 scope link metric 3 dev br0
[#] ip route add table 121 192.168.50.0/24 proto kernel scope link src 192.168.50.1 dev br0
[#] iptables -t mangle -I FORWARD -o wg11 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu -m comment --comment WireGuard 'client'
[#] iptables -t mangle -I FORWARD -i wg11 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu -m comment --comment WireGuard 'client'
[#] iptables -t mangle -I FORWARD -o wg11 -j MARK --set-xmark 0x01/0x7 -m comment --comment WireGuard 'client'
[#] iptables -t mangle -I PREROUTING -i wg11 -j MARK --set-xmark 0x01/0x7 -m comment --comment WireGuard 'client'
[#] iptables -t nat -I POSTROUTING -s 192.168.50.1/24 -o wg11 -j MASQUERADE -m comment --comment WireGuard 'client'
[>] PostUp
[#] iptables -I OUTPUT ! -o wg11 -m mark ! --mark $(wg show wg11 fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -I OUTPUT ! -o wg11 -m mark ! --mark $(wg show wg11 fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
iptables v1.4.15: mark: bad mark value for option "--mark", or out of range.

Try `iptables -h' or 'iptables --help' for more information.
    wg_manager-clientwg11: Initialisation complete.
 
RT-AX88U.
not using ipset. just using client 1 wg11.
The command that gives that error is not part of WGM. you seem to have "PostUp" commands in your config file (custom shell commands executed by wgm (or wg-quick) upon start or stop). if you did not put these there, it was probably put there by your VPN supplier.

wgm takes care of your firewall rules so you may edit the config file and remove these.
stop wg11 in wgm,
Code:
nano /opt/etc/wireguard.d/wg11.conf

and put a # before any PreUp, PostUp, PreDown and PostUp lines.

save and exit.... then start wg11 again
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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