Problem route table 220 (strongswan) from a container

[ZW3B (LAB3W.ORJ 🇫🇷 🇪🇺)]

Hello everyone.

I have a routing problem from an LXC container.

After setting up a VPN, StrongSwan, it uses a particular table, routing table 220.

For information, Linux routing tables are configured in this file:

root@pve:~ $ cat /etc/iproute2/rt_tables
#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep

So, as I pointed out, Containers do not query table 220 (strongSwan).

I’ll run the procedure that makes me say this

So I have a Very StongSwan ESTABLISHED in which I declared my local and client networks :

root@bw: # swanctl --list-sas
home_orange-vps_de: #1, ESTABLISHED, IKEv2, 9ce0e73e646f3d4b_i* 366b768b639e3928_r
  local  'bw.home.lab3w.fr' @ 172.16.0.1[4500]
  remote 'vps.de.ipv10.net' @ 135.125.133.51[4500]
  AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5
  established 505s ago, rekeying in 12598s
  home_orange-vps_de: #5, reqid 1, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-256/HMAC_SHA2_256_128/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5
    installed 172s ago, rekeying in 3082s, expires in 3788s
    in  cbe8b4cb,  10316 bytes,    61 packets,     9s ago
    out c6432537,  11748 bytes,    81 packets,    12s ago
    local  fc01::10:126:42:0/112 fc01::172:16:0:0/104 fc01::192:168:0:0/104 fec2::/16
    remote fc00:41d0:701:1100::/64 fc00:41d0:801:2000::/64 fec0::/16 fec1::/16

Below :

root@bw: # ip -6 route show
2a01:cb1d:2d4:8800:1ab3:1000::/84 dev vmbr1 proto kernel metric 256 pref medium
fc01::172:16:0:0/104 dev vmbr2 proto kernel metric 256 pref medium
fe80::/64 dev vmbr2 proto kernel metric 256 pref medium
fe80::/64 dev vmbr1 proto kernel metric 256 pref medium
fec2::/16 dev vmbr2 proto kernel metric 256 pref medium
default via fc01::172:16:0:254 dev vmbr2 metric 1024 onlink pref medium

root@bw: # ip -6 route show table 254
2a01:cb1d:2d4:8800:1ab3:1000::/84 dev vmbr1 proto kernel metric 256 pref medium
fc01::172:16:0:0/104 dev vmbr2 proto kernel metric 256 pref medium
fe80::/64 dev vmbr2 proto kernel metric 256 pref medium
fe80::/64 dev vmbr1 proto kernel metric 256 pref medium
fec2::/16 dev vmbr2 proto kernel metric 256 pref medium
default via fc01::172:16:0:254 dev vmbr2 metric 1024 onlink pref medium

Table 220 for StrongSwan :

root@bw: # ip -6 route show table 220
fc00:41d0:701:1100::/64 dev vmbr2 proto static src fec2::1 metric 1024 pref medium
fc00:41d0:801:2000::/64 dev vmbr2 proto static src fec2::1 metric 1024 pref medium
fec0::/16 dev vmbr2 proto static src fec2::1 metric 1024 pref medium
fec1::/16 dev vmbr2 proto static src fec2::1 metric 1024 pref medium

In this sense I can access my LXC container (quite normal).

root@bw: # ping6 fc00:41d0:701:1100::1
PING fc00:41d0:701:1100::1(fc00:41d0:701:1100::1) 56 data bytes
64 bytes from fc00:41d0:701:1100::1: icmp_seq=1 ttl=63 time=23.5 ms
64 bytes from fc00:41d0:701:1100::1: icmp_seq=2 ttl=63 time=22.6 ms
64 bytes from fc00:41d0:701:1100::1: icmp_seq=3 ttl=63 time=22.9 ms
64 bytes from fc00:41d0:701:1100::1: icmp_seq=4 ttl=63 time=23.7 ms
^C
--- fc00:41d0:701:1100::1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 22.552/23.165/23.700/0.449 ms
lun. sept. 30 05:16:41 root@bw:/var/pro/alibaba #

On the other hand, here is the symptom - on the machine “vps.de.ipv10” where I have a LinuX Containers :

root@vps-de:~ # ifconfig
ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether fa:16:3e:16:c6:f3  txqueuelen 1000  (Ethernet)
        RX packets 302593055  bytes 124617335405 (116.0 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 332860140  bytes 70836308292 (65.9 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Boucle locale)
        RX packets 1154  bytes 130694 (127.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1154  bytes 130694 (127.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vethlQV0nW: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::fc16:1fff:fe91:b2e  prefixlen 64  scopeid 0x20<link>
        ether fe:16:1f:91:0b:2e  txqueuelen 1000  (Ethernet)
        RX packets 97817321  bytes 24554228134 (22.8 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 113376348  bytes 13430510793 (12.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vmbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 135.125.133.51  netmask 255.255.255.0  broadcast 135.125.133.255
        inet6 fec0::1  prefixlen 16  scopeid 0x40<site>
        inet6 fe80::24b2:4ff:fea2:c384  prefixlen 64  scopeid 0x20<link>
        inet6 2001:41d0:701:1100::6530  prefixlen 128  scopeid 0x0<global>
        ether 26:b2:04:a2:c3:84  txqueuelen 1000  (Ethernet)
        RX packets 296876976  bytes 119969634347 (111.7 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 332860140  bytes 70836308292 (65.9 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vmbr1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.133.0.254  netmask 255.255.255.0  broadcast 10.133.0.255
        inet6 fe80::7069:deff:fe53:4683  prefixlen 64  scopeid 0x20<link>
        inet6 fc00:41d0:701:1100::fffe  prefixlen 64  scopeid 0x0<global>
        ether 72:69:de:53:46:83  txqueuelen 1000  (Ethernet)
        RX packets 97817285  bytes 23184783528 (21.5 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 89687774  bytes 12198704545 (11.3 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Routing table 254 (main) :

root@vps-de:~ # ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
2001:41d0:701:1100::6530 dev vmbr0 proto kernel metric 256 pref medium
fc00:41d0:701:1100::/64 dev vmbr1 proto kernel metric 256 pref medium
fe80::/64 dev vmbr0 proto kernel metric 256 pref medium
fe80::/64 dev vethlQV0nW proto kernel metric 256 pref medium
fe80::/64 dev vmbr1 proto kernel metric 256 pref medium
fec0::/16 dev vmbr0 proto kernel metric 256 pref medium
default via 2001:41d0:701:1100::1 dev vmbr0 metric 1024 onlink pref medium

Routing table 220 (strongswan):

root@vps-de:~ # ip -6 route show table 220
fc00:41d0:801:2000::/64 dev vmbr0 proto static src fec0::1 metric 1024 pref medium
fc01::10:6:0:0/104 dev vmbr0 proto static src fec0::1 metric 1024 pref medium
fc01::10:126:42:0/112 dev vmbr0 proto static src fec0::1 metric 1024 pref medium
fc01::10:126:0:0/104 dev vmbr0 proto static src fec0::1 metric 1024 pref medium
fc01::172:16:0:0/104 dev vmbr0 proto static src fec0::1 metric 1024 pref medium
fc01::192:168:0:0/104 dev vmbr0 proto static src fec0::1 metric 1024 pref medium
fc01::/16 dev vmbr0 proto static src fec0::1 metric 1024 pref medium
fec1::/16 dev vmbr0 proto static src fec0::1 metric 1024 pref medium
fec2::/16 dev vmbr0 proto static src fec0::1 metric 1024 pref medium

Let’s check :

root@vps-de:~ # ip -6 route get fc01::172:16:0:1
fc01::172:16:0:1 from :: dev vmbr0 table 220 proto static src fec0::1 metric 1024 pref medium

Ping works from host - OK :

root@vps-de:~ # ping fc01::172:16:0:1
PING fc01::172:16:0:1(fc01::172:16:0:1) 56 data bytes
64 bytes from fc01::172:16:0:1: icmp_seq=1 ttl=64 time=23.0 ms
64 bytes from fc01::172:16:0:1: icmp_seq=2 ttl=64 time=23.4 ms
64 bytes from fc01::172:16:0:1: icmp_seq=3 ttl=64 time=23.6 ms
^C
--- fc01::172:16:0:1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 23.026/23.352/23.648/0.254 ms

Traceroute command :

root@vps-de:~ # traceroute6 fc01::172:16:0:1
traceroute to fc01::172:16:0:1 (fc01::172:16:0:1), 30 hops max, 80 byte packets
 1  fc01::172:16:0:1 (fc01::172:16:0:1)  22.781 ms  22.725 ms  22.688 ms

I connect to the container “fc00:41d0:701:1100::1” (the one that responds well to my pings from home).

root@vps-de:~ # lxc-attach ns3
root@vps-de.nameserver:~ # ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.133.0.1  netmask 255.255.255.0  broadcast 10.133.0.255
        inet6 fe80::216:3eff:fe78:442d  prefixlen 64  scopeid 0x20<link>
        inet6 fc00:41d0:701:1100::1  prefixlen 64  scopeid 0x0<global>
        ether 00:16:3e:78:44:2d  txqueuelen 1000  (Ethernet)
        RX packets 113377105  bytes 13430614954 (12.5 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 97817892  bytes 24554346687 (22.8 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1810  bytes 255582 (249.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1810  bytes 255582 (249.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Now when I ping to “a” machine at home - say “bw.home.lab3w” the container does not query table 220 AND therefore goes out the host’s default route.

root@vps-de.nameserver:~ # ping fc01::172:16:0:1
PING fc01::172:16:0:1(fc01::172:16:0:1) 56 data bytes
From 2001:41d0:701:1100::6530 icmp_seq=1 Destination unreachable: Address unreachable
From 2001:41d0:701:1100::6530 icmp_seq=2 Destination unreachable: Address unreachable
From 2001:41d0:701:1100::6530 icmp_seq=3 Destination unreachable: Address unreachable
^C
--- fc01::172:16:0:1 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3068ms

root@vps-de.nameserver:~ # traceroute6 fc01::172:16:0:1
traceroute to fc01::172:16:0:1 (fc01::172:16:0:1), 30 hops max, 80 byte packets
 1  fc00:41d0:701:1100::fffe (fc00:41d0:701:1100::fffe)  0.095 ms  0.034 ms  0.018 ms
 2  vps.de.ipv10.net (2001:41d0:701:1100::6530)  3069.566 ms !H  3069.365 ms !H  3069.323 ms !H

It seems to me that there is a “forgetting” of questioning of routes since the LXC

I really need it, it’s urgent!!

Thank you.

Warmest regards.

Romain.

PS : And it doesn’t work in IPv4 (class A, B and C addresses) or in IPv6 (ULA addresses).

---

I installed strongSwan 6.0beta Vici Post-Quantum IKEv2 Daemon. Of course you can use today’s official version, version 5.9 without compiling, but you won’t be able to encrypt with OQS algorithms.

Documentation StrongSwan - Modern vici-based Scenarios IPv6 Configuration Examples et la page Usable Examples configurations.
Documentation strongSwan :: Introduction to strongSwan → Routing
Documentation strongSwan :: Route-based VPN

---

Note of me at 06h GMT+1 : It is true that StrongSwan does not write anything to this file (it knows that).

root@vps-de:~ # cat /etc/iproute2/rt_tables
#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep
root@vps-de:~ #

---

Note of me at 6h40 GMT +1 :

root@vps-de:~ # ip -6 route show table 255
local ::1 dev lo proto kernel metric 0 pref medium
local 2001:41d0:701:1100::6530 dev vmbr0 proto kernel metric 0 pref medium
anycast fc00:41d0:701:1100:: dev vmbr1 proto kernel metric 0 pref medium
local fc00:41d0:701:1100::fffe dev vmbr1 proto kernel metric 0 pref medium
anycast fe80:: dev vmbr0 proto kernel metric 0 pref medium
anycast fe80:: dev vethlQV0nW proto kernel metric 0 pref medium
anycast fe80:: dev vmbr1 proto kernel metric 0 pref medium
local fe80::24b2:4ff:fea2:c384 dev vmbr0 proto kernel metric 0 pref medium
local fe80::7069:deff:fe53:4683 dev vmbr1 proto kernel metric 0 pref medium
local fe80::fc16:1fff:fe91:b2e dev vethlQV0nW proto kernel metric 0 pref medium
anycast fec0:: dev vmbr0 proto kernel metric 0 pref medium
local fec0::1 dev vmbr0 proto kernel metric 0 pref medium
multicast ff00::/8 dev vmbr0 proto kernel metric 256 pref medium
multicast ff00::/8 dev vmbr1 proto kernel metric 256 pref medium
multicast ff00::/8 dev vethlQV0nW proto kernel metric 256 pref medium

I tried to add the “table 220” to the “/etc/iproute2/rt_tables” file without positive result:

root@vps-de:~ # cat /etc/iproute2/rt_tables
#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep
#
# strongswan perso
#
220     strongswan

---

For information

I opened the same topic on the forum the other day (my first addition of a request for help on the forum):

Problem with IP network routes from containers - different than from host (StrongSwan)

Hello, I have been using LinuX Container (LXC) for a few years (10 years maybe more) - from Promox or alone. This is the first time I post a discussion topic on your site. Thanks to the developers of the LinuX Container projects, you rock! I see (it seems to me) that there is a problem with the “network routes” of the Containers. The symptom is that I have the impression (sure) that the containers do not read the routing table 220. On Linux, “strongSwan” installs by default the routes in t…

Have a nice day everyone.

[ZW3B (LAB3W.ORJ 🇫🇷 🇪🇺)]

I have a clue – it’s my IPv6 firewall configuration.
Already; by disabling the MASQUERAGE of ULA (Unique Local Address) addresses I can ping; receive the reply. I have a problem catching the services (example SSH); it must be related to the FORWARD on one of the firewalls on the way…

WAN_IF=vmbr0
LXC_IF=vmbr1

function nat_v6()
{
        # LXC LOCAL
        $IP6TABLE -t nat -A POSTROUTING -o $WAN_IF -i $LXC_IF -j MASQUERADE

        echo "   "+ NAT : [OK]
}

MASQUERAGE allows me to protect my containers (or local workstations) so that they do not have a GUA (Global Unicast Address) address, temporary or not, so that they are not visible from the internet - as in IPv4 - All machines exit through the IPv6 address of the router(s).

---

For informations

For the servers (IPv6 on which we can “input” from the Internet) of some containers… it is necessary to activate the forwarding between the cards and the association of the router (accept_ra at 2 – if the forward is active on the interface) and the network discovery for neighbors (containers). Then associate the IPv6 GUA which must go out as a proxying neighbor

# alias ipv6_options = sysctl -r net.ipv6.conf.CARD0.VAR1) && sysctl -r net.ipv6.conf.CARD0.VAR2 etc....)
root@pve.home:~ $ ipv6_options

net.ipv6.conf.vmbr0.forwarding = 1
net.ipv6.conf.vmbr0.accept_redirects = 1
net.ipv6.conf.vmbr0.accept_ra = 2
net.ipv6.conf.vmbr0.autoconf = 0
net.ipv6.conf.vmbr0.proxy_ndp = 1
net.ipv6.conf.vmbr0.use_tempaddr = 0

net.ipv6.conf.vmbr1.forwarding = 1
net.ipv6.conf.vmbr1.accept_redirects = 1
net.ipv6.conf.vmbr1.accept_ra = 2
net.ipv6.conf.vmbr1.autoconf = 0
net.ipv6.conf.vmbr1.proxy_ndp = 1
net.ipv6.conf.vmbr1.use_tempaddr = 0

Example of container IP accessible from the internet (GUA) :

root@pve.home:~ $ ip -6 neigbor show
2a01:cb1d:12:1c00:1ab3:126:42:10 dev vmbr0 proxy 

To add a GUA server IP; we add the container IP on the network interface of the host machine; the one that is connected to the outside.

root@pve.home:~ $ ip -6 neigbor add proxy 2a01:cb1d:12:1c00:1ab3:126:42:1000 dev vmbr0

Romain.

As soon as I find the solution to access the services I will keep you posted Bye.

[ZW3B (LAB3W.ORJ 🇫🇷 🇪🇺)]

A ping from my home LAN to a DE VPS (Germany) <> UK VPS (England) <> LXC container (nameserver)

LAN at Home : HOST (Proxmox) / VM1 (home) / LXC (ww1)

root@pve.home.ww1:~ # ping fc00:41d0:801:2000::1 -c4
PING fc00:41d0:801:2000::1(fc00:41d0:801:2000::1) 56 data bytes
64 bytes from fc00:41d0:801:2000::1: icmp_seq=1 ttl=59 time=37.0 ms
64 bytes from fc00:41d0:801:2000::1: icmp_seq=2 ttl=59 time=36.6 ms
64 bytes from fc00:41d0:801:2000::1: icmp_seq=3 ttl=59 time=37.3 ms
64 bytes from fc00:41d0:801:2000::1: icmp_seq=4 ttl=59 time=37.1 ms

--- fc00:41d0:801:2000::1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 36.570/37.003/37.317/0.275 ms

The traceroute SLAN

root@pve.home.ww1:~ # traceroute6 fc00:41d0:801:2000::1 -I
traceroute to fc00:41d0:801:2000::1 (fc00:41d0:801:2000::1), 30 hops max, 80 byte packets
 1  fc01::10:126:42:ffff (fc01::10:126:42:ffff)  0.036 ms  0.012 ms *
 2  fc01::10:126:0:254 (fc01::10:126:0:254)  0.140 ms * *
 3  fc01::172:16:0:1 (fc01::172:16:0:1)  0.200 ms * *
 4  * * *
 5  fec1::1 (fec1::1)  36.844 ms *  36.829 ms
 6  fc00:41d0:801:2000::1 (fc00:41d0:801:2000::1)  37.081 ms  36.903 ms  36.873 ms

Good evening, good day at all.

Romain

---

I add “iperf” in StrongSWAN IKEv2

root@pve.home.ww1:~ # iperf3 -c fc00:41d0:801:2000::1
root@vps-uk.ns4:~ # iperf3 -s
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from fc01::10:126:42:10, port 38098
[  5] local fc00:41d0:801:2000::1 port 5201 connected to fc01::10:126:42:10 port 38114
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   410 KBytes  3.36 Mbits/sec                  
[  5]   1.00-2.00   sec   882 KBytes  7.23 Mbits/sec                  
[  5]   2.00-3.00   sec  1.25 MBytes  10.5 Mbits/sec                  
[  5]   3.00-4.00   sec  1.67 MBytes  14.0 Mbits/sec                  
[  5]   4.00-5.00   sec  2.14 MBytes  18.0 Mbits/sec                  
[  5]   5.00-6.00   sec  2.58 MBytes  21.6 Mbits/sec                  
[  5]   6.00-7.00   sec  3.08 MBytes  25.8 Mbits/sec                  
[  5]   7.00-8.00   sec  3.42 MBytes  28.7 Mbits/sec                  
[  5]   8.00-9.00   sec  3.91 MBytes  32.8 Mbits/sec                  
[  5]   9.00-10.00  sec  4.84 MBytes  40.6 Mbits/sec                  
[  5]  10.00-10.04  sec   191 KBytes  41.6 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.04  sec  24.3 MBytes  20.3 Mbits/sec                  receiver

Weird IP performance of only 20.3 Mbits/sec: VPS (max 100Mbits/sec) - Home (max 500Mbits/sec)

I did Bandwidth tests with the software, command “iperf3”.

But it’s still better than IPSec + xL2TP in point-2-point (1.19 Mbits/sec).

CF:

-----------------------------------------------------------
# FR.LAB3W.HOME.WIFI.NOMADE -> WIFI5 (72Mb/s) -> FR.LAB3W.HOME.WIFI (Router OpenWrt) -> LAN (100Mb/s) -> FR.LAB3W.HOME.DC.WLAN -> VPN IPSEC+xL2TP -> CA.LAB3W.SRV
-----------------------------------------------------------
Accepted connection from 2607:5300:60:9389:74::50a, port 52212
[  5] local 2607:5300:60:9389::1 port 5201 connected to 2607:5300:60:9389:74::50a port 52214
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  38.9 KBytes   319 Kbits/sec                  
[  5]   1.00-2.00   sec   153 KBytes  1.25 Mbits/sec                  
[  5]   2.00-3.00   sec   121 KBytes   988 Kbits/sec                  
[  5]   3.00-4.00   sec   171 KBytes  1.40 Mbits/sec                  
[  5]   4.00-5.00   sec   178 KBytes  1.46 Mbits/sec                  
[  5]   5.00-6.00   sec   166 KBytes  1.36 Mbits/sec                  
[  5]   6.00-7.00   sec   182 KBytes  1.49 Mbits/sec                  
[  5]   7.00-8.00   sec   165 KBytes  1.35 Mbits/sec                  
[  5]   8.00-9.00   sec   104 KBytes   850 Kbits/sec                  
[  5]   9.00-10.00  sec   152 KBytes  1.24 Mbits/sec                  
[  5]  10.00-10.42  sec  83.0 KBytes  1.62 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.42  sec  1.48 MBytes  1.19 Mbits/sec                  receiver

root@nomade:~ $ traceroute6 zw3b.fr
traceroute to zw3b.fr (2607:5300:60:9389::1) from 2607:5300:60:9389:74::50a, 30 hops max, 16 byte packets
 1  wifi.zw3b.net (2607:5300:60:9389:74::1)  1.167 ms  1.125 ms  1.069 ms
 2  wlan.zw3b.net (2607:5300:60:9389:74:0:ff:ffff)  51.147 ms  59.781 ms  144.917 ms
 3  wan.ipv10.net (2607:5300:60:9389::1)  165.907 ms  429.662 ms  307.214 ms

[ZW3B (LAB3W.ORJ 🇫🇷 🇪🇺)]

I think the problem is with my firewall – I didn’t allow ULA addresses in my IPv6 firewall. I’ll confirm this soon.

I added the ipv6_ula() function to my IPv6 firewall.

Now it’s good !!

function ipv6_ula()
{
        echo "   |";
        echo "   + IPv6 - Addrs Unique Locale Area -----------------------";

        # Allow Link-Local addresses
        # network range : fc00:0000:0000:0000:0000:0000:0000:0000-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

        echo "   |\\";
        $IP6TABLE -A INPUT -s fc00::/7 -j ACCEPT
        $IP6TABLE -A FORWARD -s fc00::/7 -d fc00::/7 -j ACCEPT
        $IP6TABLE -A OUTPUT -d fc00::/7 -j ACCEPT
        echo "   | +--> "fc00::/7 : ACCEPT;
        echo "   | |";
        echo "   |" + IPv6 - Addrs Unique Locale Area : [OK]

}

function ipv6_multicast()
{
        echo "   |";
        echo "   + IPv6 - Addrs Multicast -----------------------";

        # Allow multicast
        # network range : ff00:0000:0000:0000:0000:0000:0000:0000-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

        echo "   |\\";
        $IP6TABLE -A INPUT -d ff00::/8 -j ACCEPT
        $IP6TABLE -A FORWARD -s ff00::/8 -d ff00::/8 -j ACCEPT
        $IP6TABLE -A OUTPUT -d ff00::/8 -j ACCEPT
        echo "   | +--> "ff00::/8 : ACCEPT;
        echo "   | |";
        echo "   |" + IPv6 - Addrs Multicast : [OK]
}

function ipv6_link_local()
{
        echo "   |";
        echo "   + IPv6 - Addrs Link-Local Unicast -----------------------";

        # Allow Link-Local addresses
        # network range : fe80:0000:0000:0000:0000:0000:0000:0000-febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff

        echo "   |\\";
        $IP6TABLE -A INPUT -s fe80::/10 -j ACCEPT
        $IP6TABLE -A FORWARD -s fe80::/10 -d fe80::/10 -j ACCEPT
        $IP6TABLE -A OUTPUT -d fe80::/10 -j ACCEPT
        echo "   | +--> "fe80::/10 : ACCEPT;
        echo "   | |";
        echo "   | "+ IPv6 - Addrs Link-Local : [OK]

}

function ipv6_strongswan()
{
        # Default ------------------
        echo "   |";
        echo "   + IPv6 - Addrs Site-Local Secure Area Network -------------------------";

        # Allow  Secure Area Network addresses
        # network range : fec0:0000:0000:0000:0000:0000:0000:0000-feff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

        echo "   |\\";
        $IP6TABLE -A INPUT -s fec0::/10 -j ACCEPT
        $IP6TABLE -A FORWARD -s fec0::/10 -d fec0::/10 -j ACCEPT
        $IP6TABLE -A OUTPUT -d fec0::/10 -j ACCEPT
        echo "   | +--> "fec0::/10 : ACCEPT;
        echo "   | |";
        echo "   | "+ IPv6 - Addrs Secure Area Network : [OK]

        # Add ------------------

        echo "   |";
        # Allow  Forwarding SLAN (fec0::/10) <> ULA (fc00::/7)
        # network range : fc00:0000:0000:0000:0000:0000:0000:0000-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

        echo "   + IPv6 - Forwarding Addrs SWAN 2 ULA Networks -------------------------";
        echo "   |\\";
        $IP6TABLE -A FORWARD -s fec0::/10 -d fc00::/7 -j ACCEPT
        $IP6TABLE -A FORWARD -d fec0::/10 -s fc00::/7 -j ACCEPT
        echo "   | +--> fec0::/10 <?> fc00::/7 : ACCEPT";
        echo "   | |";
        echo "   | "+ IPv6 - Forwarding Addrs SWAN 2 ULA Networks : [OK]
        echo "   |";

}

Below is the firewall I made for myself

I have a page in French with the Linux ip6tables firewall on ICMPv6 / IPv6.

---

And yet, checking my latest strongSwan tests (conf 4), everything was working fine from my subnets (containers) some time ago. I must have made a mistake.

That was it ! I had not authorized the forward of ULA networks.

Now it works correctly.

SubNetUK (LXC) <> SiteUK <> SiteDE (AC) <> SiteFR <> SubNetFR (LXC) - OK ping
SubNetUK (LXC) <> SiteUK <> SiteDE (AC) <> SiteFR <> SubNetFR (LXC) - OK services

Romain.

---

AND with the MASQUERADE… it’s now good too

For example, to be able to “surf” with the router IP (do ULA NAT as in IPv4 for a network or for 1 machine (-s fc00:41d0:801:2000::1) except for the destination of another ULA network (! -d fc00::/7)) :

ip6tables  -t nat -A POSTROUTING -o vmbr0 -s fc00:41d0:801:2000::1 ! -d fc00::/7 -j MASQUERADE

The function “nat_v6()” becomes :

WAN_IF=vmbr0
LXC_IF=vmbr1

function nat_v6()
{
        # NET FOR LXC EXCEPT TO THE ULA NETWORK
        $IP6TABLE -t nat -A POSTROUTING -o $WAN_IF -i $LXC_IF ! -d fc00::/7 -j MASQUERADE

        echo "   "+ NAT : [OK]
}

Good luck, thanks again to your LinuX Containers developer team.

See you later.

Romain (LAB3W.ORJ)
Founder ZW3B.FR|EU|TV|NET|COM|BLOG