You are not logged in.

#1 2026-01-19 16:15:45

Django [BOfH]
Member
Registered: 2023-01-23
Posts: 16

[Solved] IPv6 routing issue

I am currently setting up a small but sophisticated test environment in my home lab. In doing so, I have encountered a minor problem.


OK, basically, the whole thing looks like this:

My environment:

 ### Internet ###
        ^
        |
        V
  +-----------+
  |           |
  |    FWA    |
  |           |
  +-----------+
        ^
        |
--EDMZ--+----------------- [special devices]
        |
        V net0
  +-----------+
  |           |
  |    FWB    |  vml000210
  |           |
  +---------net1
        |
--IDMZ--+------------------ [web, mail ...]
        |
        V net0
  +-----------+
  |           |
  |    FWC    |  vml000110
  |           |
  +-----------+
        ^ net1
        |
--------+-----Intranet----- [mobile devices, notebooks, phones ...] 

Both firewalls FWB (vml000210) and FWC (vml000110) are virtual machines in a KVM environment with bridged devices.

Host vml000210 looks like:

/etc/systemd/network/net0.network :
# Ansible generated, do not edit manually!                                                    
 
[Match]
Name=net0
 
[Network]
Address=172.17.2.210/24
Gateway=172.17.2.1
DNS=172.17.2.1
 
Address=fe80::5054:ff:fe41:2101/64
Address=fd00::172:17:2:210/64
Address=XXXX:YYYY:ZZZZ:7600:1720:17:2:210/64
Gateway=fe80::7ac5:7dff:fefd:1c10
DNS=fe80::7ac5:7dff:fefd:1c10
LinkLocalAddressing=no

and

root@vml000210:~# cat /etc/systemd/network/net1.network 
# Ansible generated, do not edit manually!

[Match]
Name=net1

[Network]
Address=10.0.0.210/24
DNS=10.0.0.27

#Address=fe80::5054:ff:fe41:2102/64
Address=fd00::3:10:0:0:210/64
Address=XXXX:YYYY:ZZZZ:10::210/64
#LinkLocalAddressing=no
LinkLocalAddressing=ipv6

This configuration then results in:

2: net0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:41:21:01 brd ff:ff:ff:ff:ff:ff
    altname enp1s0
    altname enx525400412101
    inet 172.17.2.210/24 brd 172.17.2.255 scope global net0
       valid_lft forever preferred_lft forever
    inet6 XXXX:YYYY:ZZZZ:7600:1720:17:2:210/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fd00::172:17:2:210/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe41:2101/64 scope link 
       valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:41:21:02 brd ff:ff:ff:ff:ff:ff
    altname enp2s0
    altname enx525400412102
    inet 10.0.0.210/24 brd 10.0.0.255 scope global net1
       valid_lft forever preferred_lft forever
    inet6 XXXX:YYYY:ZZZZ:7603:10::210/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fd00::3:10:0:0:210/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe41:2102/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

Routing looks like:

root@vml000210:~# ip -6 r
XXXX:YYYY:ZZZZ:7600::/64 dev net0 proto kernel metric 256 pref medium
XXXX:YYYY:ZZZZ:7603::/64 dev net1 proto kernel metric 256 pref medium
XXXX:YYYY:ZZZZ:7607::/64 via XXXX:YYYY:ZZZZ:7603:10::110 dev net1 metric 1024 pref medium
fd00::/64 dev net0 proto kernel metric 256 pref medium
fd00:0:0:3::/64 dev net1 proto kernel metric 256 pref medium
fe80::/64 dev net1 proto kernel metric 256 pref medium
fe80::/64 dev net0 proto kernel metric 256 pref medium
default via fe80::7ac5:7dff:fefd:1c10 dev net0 proto static metric 1024 pref medium

This host/firewall can easily reach hosts in the EDMZ as well as on the Internet:

root@vml000210:~# ping -c4 bbs.archlinux.org
PING bbs.archlinux.org (2a01:4f8:c2c:b1cf::1) 56 data bytes
64 bytes from bbs.archlinux.org (2a01:4f8:c2c:b1cf::1): icmp_seq=1 ttl=53 time=19.0 ms
64 bytes from bbs.archlinux.org (2a01:4f8:c2c:b1cf::1): icmp_seq=2 ttl=53 time=14.2 ms
64 bytes from bbs.archlinux.org (2a01:4f8:c2c:b1cf::1): icmp_seq=3 ttl=53 time=14.5 ms
64 bytes from bbs.archlinux.org (2a01:4f8:c2c:b1cf::1): icmp_seq=4 ttl=53 time=14.5 ms

--- bbs.archlinux.org ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 14.194/15.533/18.986/1.996 ms
root@vml000210:~# dig AAAA bbs.archlinux.org +short
2a01:4f8:c2c:b1cf::1
root@vml000210:~# tracepath 2a01:4f8:c2c:b1cf::1
 1?: [LOCALHOST]                        0.027ms pmtu 1500
 1:  fwa.edmz.example.org                                   1.137ms 
 1:  fwa.edmz.example.org                                   0.811ms 
 2:  fwa.edmz.example.org                                   0.959ms pmtu 1492
 2:  2003:0:1a00:e408::1                                   8.677ms 
 3:  2003:0:1a00:e400::1                                   9.384ms 
 4:  2003:0:f00::a1c                                      12.630ms 
 5:  2003:0:f00::a1d                                      10.935ms 
 6:  core11.nbg1.hetzner.com                              17.610ms 
 7:  no reply
 8:  spine3-rdev1.cloud1.nbg1.hetzner.com                 55.714ms 
 9:  13923.your-cloud.host                                14.074ms asymm 10 
10:  bbs.archlinux.org                                    17.981ms !A
     Resume: pmtu 1492

Evaluating my official IPv4 and IPv6 offers:

root@vml000210:~# curl -4 ip.sb ; curl -6 ip.sb
AAA.BBB.CCC.DDD
XXXX:YYYY:ZZZZ:7600:1720:17:2:210

OK, so far so good, everything is running smoothly here. The host is doing what it should, so let's move on to the second firewall, FWC, on the host vml000110. Let's take a quick look at its configuration here as well:

root@vml000110:~# cat /etc/systemd/network/net0.network 
# Ansible generated, do not edit manually!

[Match]
Name=net0

[Network]
LinkLocalAddressing=ipv6
Address=fe80::5054:ff:fe41:1101/64
Address=fd00::3:10:0:0:110/64
Address=XXXX:YYYY:ZZZZ:7603:10::110/64
Gateway=fe80::5054:ff:fe41:2102
DNS=XXXX:YYYY:ZZZZ:7600:7ac5:7dff:fefd:1c10


Address=10.0.0.110/24
Gateway=10.0.0.210
DNS=217.237.151.142

and

root@vml000110:~# cat /etc/systemd/network/net1.network 
# Ansible generated, do not edit manually!

[Match]
Name=net1

[Network]
LinkLocalAddressing=ipv6
Address=fe80::5054:ff:fe41:1102/64
Address=fd00::7:10:0:10:110/64
Address=XXXX:YYYY:ZZZZ:10:0:10:110/64

Address=10.0.10.110/24

There we have:

2: net0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:41:11:01 brd ff:ff:ff:ff:ff:ff
    altname enp1s0
    altname enx525400411101
    inet 10.0.0.110/24 brd 10.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 XXXX:YYYY:ZZZZ:7603:10::110/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fd00::3:10:0:0:110/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe41:1101/64 scope link 
       valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:41:11:02 brd ff:ff:ff:ff:ff:ff
    altname enp2s0
    altname enx525400411102
    inet 10.0.10.110/24 brd 10.0.10.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 XXXX:YYYY:ZZZZ:7607:10:0:10:110/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fd00::7:10:0:10:110/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe41:1102/64 scope link 
       valid_lft forever preferred_lft forever

Routing on this node looks like:

root@vml000110:~# ip -6 r
XXXX:YYYY:ZZZZ:7603::/64 dev net0 proto kernel metric 256 pref medium
XXXX:YYYY:ZZZZ:7607::/64 dev net1 proto kernel metric 256 pref medium
fd00:0:0:3::/64 dev net0 proto kernel metric 256 pref medium
fd00:0:0:7::/64 dev net1 proto kernel metric 256 pref medium
fe80::/64 dev net0 proto kernel metric 256 pref medium
fe80::/64 dev net1 proto kernel metric 256 pref medium
default via fe80::5054:ff:fe41:2102 dev net0 proto static metric 1024 pref medium

DNS works fine:

root@vml000110:~# dig A bbs.archlinux.org +short
116.203.93.142

Asking about my official IPv4 address i can see:

root@vml000110:~# curl -4 ip.sb
AAA.BBB.CCC.DDD

Asking an external unfriendly DNS server works well:

root@vml000110:~# dig @8.8.8.8 A archlinux.org +short
209.126.35.79

But now let's get to the big BUT:
The attempt to query my official IPv6 address now fails miserably in a timeout!

root@vml000110:~# curl -6 ip.sb

When I use tracepath to check the route to archlinux.org, I see that I can only get as far as the upstream firewall, even though forwarding for IPv4 and IPv6 is enabled there:

root@vml000110:~# tracepath -n 2604:cac0:a104:d::3
 1?: [LOCALHOST]                        0.028ms pmtu 1500
 1:  XXXX:YYYY:ZZZZ:7603:10::210                               0.585ms 
 1:  XXXX:YYYY:ZZZZ:7603:10::210                               0.574ms 
 2:  no reply
 3:  no reply
^C

If I now enable masquerading for IPv6 on the FWB firewall on the upstream host - yes, I am aware that you definitely don't want this - the host vml000110 suddenly also reaches the IPv6 of bbs.archlinux.org!

root@vml000210:~# firewall-cmd --policy=idmz_2_edmz --add-rich-rule='rule family=ipv6 masquerade'
success

The I ask one again:

root@vml000110:~# tracepath -n 2a01:4f8:c2c:b1cf::1
 1?: [LOCALHOST]                        0.028ms pmtu 1500
 1:  XXXX:YYYY:ZZZZ:10::210                               0.575ms 
 1:  XXXX:YYYY:ZZZZ:10::210                               0.646ms 
 2:  XXXX:YYYY:ZZZZ:7600:7ac5:7dff:fefd:1c10                   1.353ms 
 3:  XXXX:YYYY:ZZZZ:7600:7ac5:7dff:fefd:1c10                   1.145ms pmtu 1492
 3:  2003:0:bc00:e408::1                                   8.657ms 
 4:  2003:0:bc00:e400::1                                   9.625ms 
 5:  no reply
 6:  2003:0:f00::a1d                                      11.850ms 
 7:  2a01:4f8:0:3::fd                                     15.553ms 
 8:  no reply
 9:  no reply
10:  2a01:4f8:0:e0c0::2f42                                14.851ms asymm 11 
11:  2a01:4f8:c2c:b1cf::1                                 16.197ms !A
     Resume: pmtu 1492

However, by activating IPv6 masquerading, the following now happens when I obtain the official IP addresses again:

root@vml000110:~# curl -4 ip.sb ; curl -6 ip.sb
AAA.BBB.CCC.DDD
XXXX:YYYY:ZZZZ:7600:1720:17:2:210

Here, we do not see the official IPv6 address of the host vml000110, but rather that of the upstream packet filter on host vml000210!
I am 100% certain that this is a classic case of PEBCAK. Something seems to be wrong with the routing, I think. Isn't it so?

Interestingly, I can access the internet via IPv6 from a host that has the FWC firewall as its next hop on the intranet, but only with the wrong IPv6 address belonging to the host vml000210.

I am grateful for any tips!

Last edited by Django [BOfH] (2026-01-22 11:51:31)

Offline

#2 2026-01-20 07:31:23

-thc
Member
Registered: 2017-03-15
Posts: 1,086

Re: [Solved] IPv6 routing issue

Do you literally use a "2003:a:bcd:7600" prefix? Or is this your form of redaction?

Why is the LLA (fe80::) sometimes specified? Any IPv6 adapter does this on it's own.

Ping every each host in every IPv6 subnet (0,3,7) from every other subnet and check "ip -6 neigh" for the correct neighbor entries.

Routing: Does the main firewall (0) "know" that the innermost firewall (7) can only be reached via the one in the middle (3)?

Last edited by -thc (2026-01-20 07:31:45)

Offline

#3 2026-01-20 12:54:13

Django [BOfH]
Member
Registered: 2023-01-23
Posts: 16

Re: [Solved] IPv6 routing issue

-thc wrote:

Do you literally use a "2003:a:bcd:7600" prefix? Or is this your form of redaction?

2nd one, that was an trial to redact the real one. O.K. I've edited my initial post there are now XXXX:YYYY:ZZZZ used.

-thc wrote:

Why is the LLA (fe80::) sometimes specified? Any IPv6 adapter does this on it's own.

Hmmm, good question. I've had this for quite some time and am only now getting around to looking into it more closely. I can remove them and see what happens.

-thc wrote:

Ping every each host in every IPv6 subnet (0,3,7) from every other subnet and check "ip -6 neigh" for the correct neighbor entries.

O.K. give me a few minutes, I'll try and report, please.

Offline

#4 2026-01-20 13:25:37

Django [BOfH]
Member
Registered: 2023-01-23
Posts: 16

Re: [Solved] IPv6 routing issue

-thc wrote:

Why is the LLA (fe80::) sometimes specified? Any IPv6 adapter does this on it's own.

Now I remember why I set the LLA myself on host vml000210, i.e. firewall B, in the systemd-network configuration file.

If I set this using the option LinkLocalAddressing=ipv6, then firewall B on the network interface of zone EDMZ also gets scope global dynamic addresses. I don't actually need these there, so I tried to set the LLA myself and use the parameter LinkLocalAddressing=no.

I haven't figured out yet how to generate the LLA but ignore the scope global dynamic GUAs. Any ideas? I think IPv6AcceptRA=no should do this job.

Now we have on firewall FWB aka vml000210 on his outgoing NIC to the internet:

# Ansible generated, do not edit manually!                                                                          
 
[Match]
Name=net0
 
[Network]
Address=172.17.2.210/24
Gateway=172.17.2.1
DNS=172.17.2.1
 
Address=fd00::172:17:2:210/64
Address=XXXX:YYYY:ZZZZ:7600:172:17:2:210/64
Gateway=fe80::7ac5:7dff:fefd:1c10
DNS=fe80::7ac5:7dff:fefd:1c10
LinkLocalAddressing=ipv6
IPv6AcceptRA=no

this results to:

2: net0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:41:21:01 brd ff:ff:ff:ff:ff:ff
    altname enp1s0
    altname enx525400412101
    inet 172.17.2.210/24 brd 172.17.2.255 scope global net0
       valid_lft forever preferred_lft forever
    inet6 XXXX:YYYY:ZZZZ:7600:172:17:2:210/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fd00::172:17:2:210/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe41:2101/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

Are you satisfied with me so far? I hope so! wink

Last edited by Django [BOfH] (2026-01-20 14:32:28)

Offline

#5 2026-01-20 14:55:20

Django [BOfH]
Member
Registered: 2023-01-23
Posts: 16

Re: [Solved] IPv6 routing issue

-thc wrote:

... and check "ip -6 neigh" for the correct neighbor entries.

O.K.  Let's take a look at the hosts in the individual zones, starting from the “inside” to out.

[INTERNET]<----[FWA]<---(edmz)--->[FWB]<---(edmz)--->[FWB]--->(intranet)

INTRANET HOST:

[root@pml010074 ~]# ip -6 a
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fd00::7:10:0:10:74/128 scope global dynamic noprefixroute
       valid_lft 3255sec preferred_lft 2655sec
    inet6 XXXX:YYYY:ZZZZ:7607:254f:851e:d1fb:a531/64 scope global temporary dynamic
       valid_lft 5158sec preferred_lft 2458sec
    inet6 2003:a:e0d:7607:32f4:2aac:f2e1:5f72/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 5158sec preferred_lft 2458sec
    inet6 fe80::fa4e:fbee:c806:f070/64 scope link noprefixroute
       valid_lft forever preferred_lft forever 

[root@pml010074 ~]# ip -6 r
XXXX:YYYY:ZZZZ:7607::/64 dev enp0s25 proto ra metric 100 pref medium
XXXX:YYYY:ZZZZ:7607::/64 via fe80::5054:ff:fe41:1102 dev enp0s25 proto ra metric 105 pref medium
fd00::7:10:0:10:74 dev enp0s25 proto kernel metric 100 pref medium
fd00:0:0:7::/64 dev enp0s25 proto ra metric 100 pref medium
fd00:0:0:7::/64 via fe80::5054:ff:fe41:1102 dev enp0s25 proto ra metric 105 pref medium
fe80::/64 dev enp0s25 proto kernel metric 1024 pref medium
default via fe80::5054:ff:fe41:1102 dev enp0s25 proto ra metric 20100 pref medium

[root@pml010074 ~]# ip -6 neigh
fe80::5054:ff:fe41:1102 dev enp0s25 lladdr 52:54:00:41:11:02 router REACHABLE

Firewall C:

root@vml000110:~# ip -6 a
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 XXXX:YYYY:ZZZZ:7603:10::110/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fd00::3:10:0:0:110/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe41:1101/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 XXXX:YYYY:ZZZZ:10:0:10:110/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fd00::7:10:0:10:110/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe41:1102/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

root@vml000110:~# ip -6 r
XXXX:YYYY:ZZZZ:7603::/64 dev eth0 proto kernel metric 256 pref medium
XXXX:YYYY:ZZZZ:7607::/64 dev eth1 proto kernel metric 256 pref medium
fd00:0:0:3::/64 dev eth0 proto kernel metric 256 pref medium
fd00:0:0:7::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
default via fe80::5054:ff:fe41:2102 dev eth0 proto static metric 1024 pref medium

root@vml000110:~# ip -6 neigh
fe80::3c1a:a0ff:fe38:f5f9 dev eth1 lladdr 3e:1a:a0:38:f5:f9 STALE 
fe80::fc54:ff:fe41:1102 dev eth1 FAILED 
fe80::5054:ff:fe41:2102 dev eth0 lladdr 52:54:00:41:21:02 router REACHABLE 
XXXX:YYYY:ZZZZ:7603:10::210 dev eth0 lladdr 52:54:00:41:21:02 router STALE 
fd00::7:10:0:10:74 dev eth1 lladdr 50:7b:9d:91:52:54 REACHABLE 
fe80::fc54:ff:fe41:1101 dev eth0 lladdr fe:54:00:41:11:01 STALE 
fe80::1122:df5b:69d5:9f79 dev eth1 lladdr 00:68:eb:94:21:79 STALE 
fd00::3:10:0:0:110 dev eth0 FAILED 
fe80::2e3a:fdff:fe2e:bd0b dev eth1 lladdr 2c:3a:fd:2e:bd:0b STALE 
fe80::1eed:6fff:febb:f39f dev eth1 lladdr 1c:ed:6f:bb:f3:9f STALE 
fe80::ccdb:d9ff:fe0e:1880 dev eth1 lladdr ce:db:d9:0e:18:80 STALE 
fe80::fa4e:fbee:c806:f070 dev eth1 lladdr 50:7b:9d:91:52:54 STALE 
fd00::3:10:0:0:210 dev eth0 lladdr 52:54:00:41:21:02 router REACHABLE 
XXXX:YYYY:ZZZZ:7607:254f:851e:d1fb:a531 dev eth1 lladdr 50:7b:9d:91:52:54 STALE 
XXXX:YYYY:ZZZZ:7607:6bb3:2653:f1a0:76d2 dev eth1 lladdr 50:7b:9d:91:52:54 STALE 
fe80::5f52:30c8:e23b:71ed dev eth1 lladdr 2c:f0:5d:7b:37:19 STALE 
fe80::b83b:d1ff:fe86:848 dev eth0 lladdr ba:3b:d1:86:08:48 STALE

Firewall B:

root@vml000210:~# ip -6 a
2: net0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 XXXX:YYYY:ZZZZ:7600:172:17:2:210/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fd00::172:17:2:210/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe41:2101/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 XXXX:YYYY:ZZZZ:10::210/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fd00::3:10:0:0:210/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe41:2102/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

root@vml000210:~# ip -6 r
XXXX:YYYY:ZZZZ:7600::/64 dev net0 proto kernel metric 256 pref medium
XXXX:YYYY:ZZZZ:7603::/64 dev net1 proto kernel metric 256 pref medium
XXXX:YYYY:ZZZZ:7607::/64 via XXXX:YYYY:ZZZZ:7603:10::110 dev net1 metric 1024 pref medium
fd00::/64 dev net0 proto kernel metric 256 pref medium
fd00:0:0:3::/64 dev net1 proto kernel metric 256 pref medium
fe80::/64 dev net0 proto kernel metric 256 pref medium
fe80::/64 dev net1 proto kernel metric 256 pref medium
default via fe80::7ac5:7dff:fefd:1c10 dev net0 proto static metric 1024 pref medium

root@vml000210:~# ip -6 neigh
fe80::fc54:ff:fe41:2101 dev net0 lladdr fe:54:00:41:21:01 STALE 
XXXX:YYYY:ZZZZ:7603:10::110 dev net1 lladdr 52:54:00:41:11:01 router STALE 
XXXX:YYYY:ZZZZ:7600:ba97:e11:4f4a:7572 dev net0 lladdr 50:7b:9d:91:52:54 STALE 
fe80::fc54:ff:fe41:2102 dev net1 lladdr fe:54:00:41:21:02 STALE 
fd00::3:10:0:0:110 dev net1 lladdr 52:54:00:41:11:01 router STALE 
XXXX:YYYY:ZZZZ:7600:5985:4277:f167:5274 dev net0 lladdr 00:68:eb:94:21:79 STALE 
fe80::1122:df5b:69d5:9f79 dev net0 lladdr 00:68:eb:94:21:79 STALE 
fe80::5054:ff:fe41:1101 dev net1 lladdr 52:54:00:41:11:01 router STALE 
fe80::b83b:d1ff:fe86:848 dev net1 lladdr ba:3b:d1:86:08:48 STALE 
fe80::7ac5:7dff:fefd:1c10 dev net0 lladdr 78:c5:7d:fd:1c:10 router STALE 
fe80::fa4e:fbee:c806:f070 dev net0 lladdr 50:7b:9d:91:52:54 STALE

EDMZ Host:

root@pml010074:~# ip -6 a
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1492 state UP qlen 1000
    inet6 fd00:172:17:2:5272:5197:59ed:98ee/64 scope global temporary dynamic
       valid_lft 86397sec preferred_lft 14397sec
    inet6 fd00:172:17:2:6c9c:2308:1685:cf0d/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86397sec preferred_lft 14397sec
    inet6 XXXX:YYYY:ZZZZ:7600:a84b:d668:c6dd:b786/64 scope global temporary dynamic
       valid_lft 14372sec preferred_lft 1772sec
    inet6 XXXX:YYYY:ZZZZ:7600:6532:a0f9:d2d6:311c/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 14372sec preferred_lft 1772sec
    inet6 fe80::fa4e:fbee:c806:f070/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

[root@pml010074 ~]# ip -6 r
XXXX:YYYY:ZZZZ:7600::/64 dev enp0s25 proto ra metric 100 pref medium
XXXX:YYYY:ZZZZ:7600::/56 via fe80::7ac5:7dff:fefd:1c10 dev enp0s25 proto ra metric 100 pref medium
fd00:172:17:2::/64 dev enp0s25 proto ra metric 100 pref medium
fd00:172:17:2::/64 via fe80::7ac5:7dff:fefd:1c10 dev enp0s25 proto ra metric 105 pref medium
fe80::/64 dev enp0s25 proto kernel metric 1024 pref medium
default via fe80::7ac5:7dff:fefd:1c10 dev enp0s25 proto ra metric 100 pref medium

[root@pml010074 ~]# ip -6 neigh
fe80::7ac5:7dff:fefd:1c10 dev enp0s25 lladdr 78:c5:7d:fd:1c:10 router REACHABLE 

Offline

#6 2026-01-20 16:20:27

-thc
Member
Registered: 2017-03-15
Posts: 1,086

Re: [Solved] IPv6 routing issue

Django [BOfH] wrote:

If I set this using the option LinkLocalAddressing=ipv6, then firewall B on the network interface of zone EDMZ also gets scope global dynamic addresses. I don't actually need these there, so I tried to set the LLA myself and use the parameter LinkLocalAddressing=no.

I haven't figured out yet how to generate the LLA but ignore the scope global dynamic GUAs. Any ideas? I think IPv6AcceptRA=no should do this job.

IF you don't want the IPv6 prefixes (presumably advertised by FWA via RA) that's correct.

From Firewall C:

fd00::3:10:0:0:110 dev eth0 FAILED

There seem to be a problem between A and C: Is A aware of the route to C (as I mentioned)?

Offline

#7 2026-01-20 17:04:07

Django [BOfH]
Member
Registered: 2023-01-23
Posts: 16

Re: [Solved] IPv6 routing issue

-thc wrote:

IF you don't want the IPv6 prefixes (presumably advertised by FWA via RA) that's correct.

I fixed this with Option IPv6AcceptRA=no on firewall FWB. So far so good, I think this is O.K. now.

-thc wrote:

From Firewall C:

fd00::3:10:0:0:110 dev eth0 FAILED

There seem to be a problem between A and C: Is A aware of the route to C (as I mentioned)?

We have an old saying here: You can't see the forest for the trees. And that's exactly where I am right now.

On firewall FWC i can see a fd00::3:10:0:0:110 dev net0 FAILED idf I ask with ip -6 neigh. fd00::3:10:0:0:110 is the ULA of it's own NIC net0:

root@vml000110:~# ip -6 neigh | grep fd00::3:10:0:0:110 && ip -6 -br addr
fd00::3:10:0:0:110 dev eth0 FAILED 
lo               UNKNOWN        ::1/128 
net0             UP             XXXX:YYYY:ZZZZ:7603:10::110/64 fd00::3:10:0:0:110/64 fe80::5054:ff:fe41:1101/64 
net1             UP             XXXX:YYYY:ZZZZ:7607:10:0:10:110/64 fd00::7:10:0:10:110/64 fe80::5054:ff:fe41:1102/64

Pardon, but I can't see my error. hmm I apologize for my stupid, naive question, but I don't understand this at all right now.

AND: on firewall FWB i can see this address fd00::3:10:0:0:110, the ULA of firewall FWC NIC net0!

root@vml000210:~# ip -6 neigh | grep fd00::3:10:0:0:110
fd00::3:10:0:0:110 dev net1 lladdr 52:54:00:41:11:01 router REACHABLE 

Last edited by Django [BOfH] (2026-01-20 17:23:12)

Offline

#8 2026-01-20 18:21:37

Django [BOfH]
Member
Registered: 2023-01-23
Posts: 16

Re: [Solved] IPv6 routing issue

After rebooting the virtual machine vml000110 I can see:

root@vml000110:~# ip -6 neighbor 
fe80::5054:ff:fe41:2102 dev eth0 lladdr 52:54:00:41:21:02 router REACHABLE 
fd00::3:10:0:0:110 dev eth0 FAILED 
fd00::3:10:0:0:210 dev eth0 lladdr 52:54:00:41:21:02 router REACHABLE 
XXXX:YYYY:ZZZZ:7603:10::210 dev eth0 lladdr 52:54:00:41:21:02 router REACHABLE

fd00::3:10:0:0:110 is the own IP on net0 on vml000110
fd00::3:10:0:0:210 is the next hop, aka vml000210

I can't wrap my head around this. Why can't I see the IP/MAC address of the remote station in the ARP table of the host vml000110, but I can see that of my own interface? Is this a problem on my own host vml000110 or on the remote station vml000210? I think I'm too stupid... sad

Offline

#9 2026-01-21 06:25:35

-thc
Member
Registered: 2017-03-15
Posts: 1,086

Re: [Solved] IPv6 routing issue

Somehow I presumed fd00::3:10:0:0:110 belonging to FWA - even though you've written otherwise. Sorry for that.

Did you realize the adapter name mismatches (eth0/net0 and eth1/net1) between FWB and FWC? Where's that coming from?

Why are you not mentioning the routing question about FWA <-> FWC?

Offline

#10 2026-01-21 12:18:25

Django [BOfH]
Member
Registered: 2023-01-23
Posts: 16

Re: [Solved] IPv6 routing issue

-thc wrote:

Somehow I presumed fd00::3:10:0:0:110 belonging to FWA - even though you've written otherwise. Sorry for that.

Don't panic - everything is fine! wink

-thc wrote:

Did you realize the adapter name mismatches (eth0/net0 and eth1/net1) between FWB and FWC? Where's that coming from?

The reason was historically due to incorrect naming of the interfaces in my Ansible inventory.


I've fixed this, 'cause it bothered me a lot and often made me feel insecure. Now all hosts are configured the same way:
FWC:

root@vml000110:~# ip -6 a
2: net0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 XXXX:YYYY:ZZZZ:7603:10::110/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fd00::3:10:0:0:110/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe41:1101/64 scope link 
       valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 XXXX:YYYY:ZZZZ:10:0:10:110/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fd00::7:10:0:10:110/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe41:1102/64 scope link 
       valid_lft forever preferred_lft forever
-thc wrote:

Why are you not mentioning the routing question about FWA <-> FWC?

My apologies, I haven't forgotten your question. I will address it in detail when I return from the hospital, I promise!

Do you mean the routing on the FWB, the host vml000210, or the routing on the FWA itself? I can only influence the FWA itself to a very limited extent; it's a black box from the ISP.

FWB currently knows the following routes:

root@vml000210:~# ip r
default via 172.17.2.1 dev net0 proto static 
10.0.0.0/24 dev net1 proto kernel scope link src 10.0.0.210 
172.17.2.0/24 dev net0 proto kernel scope link src 172.17.2.210 

root@vml000210:~# ip -6 r
XXXX:YYYY:ZZZZ:7600::/64 dev net0 proto kernel metric 256 pref medium
XXXX:YYYY:ZZZZ:7603::/64 dev net1 proto kernel metric 256 pref medium
XXXX:YYYY:ZZZZ:7607::/64 via XXXX:YYYY:ZZZZ:7603:10::110 dev net1 metric 1024 pref medium
fd00::/64 dev net0 proto kernel metric 256 pref medium
fd00:0:0:3::/64 dev net1 proto kernel metric 256 pref medium
fe80::/64 dev net0 proto kernel metric 256 pref medium
fe80::/64 dev net1 proto kernel metric 256 pref medium
default via fe80::7ac5:7dff:fefd:1c10 dev net0 proto static metric 1024 pref medium

I have already created a separate route for GUAs of intranet on the FWB:
XXXX:YYYY:ZZZZ:7607::/64 via XXXX:YYYY:ZZZZ:7603:10::110 dev net1 metric 1024 pref medium

If I try to do the same for the ULAs I#m running against a wall. hmm

root@vml000210:~# ip route add fd00:0:0:7::/64 via fd00:0:0:3::/64
Error: inet6 address is expected rather than "fd00:0:0:3::/64".

Or would setting “special routes” with the help of radvd on the FWC be the better option for the FWB?

Last edited by Django [BOfH] (2026-01-21 12:27:20)

Offline

#11 2026-01-21 16:50:03

Django [BOfH]
Member
Registered: 2023-01-23
Posts: 16

Re: [Solved] IPv6 routing issue

As I promised, I'm back and here I'm with my stupid questions! wink

-thc wrote:

Why are you not mentioning the routing question about FWA <-> FWC?

For the sake of completeness, I would like to ask for clarification:

  1) The default gateway of a host always points to the LLA of the upstream unit, correct?
  2) I need separate routing definitions for both the GUA and the ULA. In my case, the FWB needs to know where to send traffic with the ULA addresses of the downstream FWC or the intranet addresses behind the FWC?

Have I understood this correctly, or am I making a fundamental error in my thinking?

Offline

#12 2026-01-21 18:29:55

-thc
Member
Registered: 2017-03-15
Posts: 1,086

Re: [Solved] IPv6 routing issue

Django [BOfH] wrote:

I can only influence the FWA itself to a very limited extent; it's a black box from the ISP.

I thought so.

Your "fd00" route command will not work. Have you tried

ip route add fd00:0:0:7::/64 via fd00::3:10:0:0:110

? You probably need to specify the device.

Let's simplify your setup for the sake of the discussion:

Downstream: Internet -> FWA -> 0 -> FWB -> 3 -> FWC -> 7
Upstream: 7 -> FWC -> 3 -> FWB -> 0 -> FWA -> Internet

The numbers refer to your IPv6 subnets.

The simple task is the upstream one: Just specify via default route where to put packets outside of the known networks.

But: Every point in the path has to know where to send packets back too. You are obviously aware of that because you have specified a downstream rule for 7 on FWB. Well - FWA needs two rules: Where to send packets destined for 3 and for 7.

Offline

#13 2026-01-21 19:31:54

Django [BOfH]
Member
Registered: 2023-01-23
Posts: 16

Re: [Solved] IPv6 routing issue

-thc wrote:
Django [BOfH] wrote:

I can only influence the FWA itself to a very limited extent; it's a black box from the ISP.

I thought so.

1: Never give up is my motto - nothing is impossible!
2: PEBCAK

Django [BOfH] wrote:

I am 100% certain that this is a classic case of PEBCAK.

It's not for nothing that my imaginary virtual business card says “Specialist for Competence and Work Simulation.”

O.K. what's the status:
IPv4 and IPv6 host address verification on FWB:

root@vml000210:~# curl -4 ip.sb ; curl -6 ip.sb
217.aaa.bbb.ccc
2003:YYYY:ZZZZ:7600:1720:17:2:210

IPv4 and IPv6 host address verification on FWC:

root@vml000110:~# curl -4 ip.sb ; curl -6 ip.sb
217.aaa.bbb.ccc
2003:YYYY:ZZZZ:7603:10::110

Yeahhhhhhh \o/

O.K. what I've done?
ULA Routes on FWA: I found all the hidden configuration options on this Digitalisierungsbox PREMIUM 2 and an option where I had set the routes for the GUAs of the two zones, IDMZ and Intranet, a long time ago. True to the motto, “What could possibly go wrong?”, I simply added the two ULAs:

List of configured static routes
Here you can see the list of configured static routes created for your LAN interfaces.
Name 	Destination  Network
IDMZ    GUA 	     2003:a:e0d:7603::/64 	
IDMZ    ULA 	     fd00:0:0:3::/64 	
INTRA   GUA 	     2003:a:e0d:7607::/64 	
INTRA   ULA 	     fd00:0:0:7::/64
-thc wrote:

Your "fd00" route command will not work. Have you tried

ip route add fd00:0:0:7::/64 via fd00::3:10:0:0:110

Yes, that works, thanx!

-thc wrote:

The simple task is the upstream one: Just specify via default route where to put packets outside of the known networks.

That's exactly it, you explained it perfectly. As soon as you do it right, it works!

-thc wrote:

But: Every point in the path has to know where to send packets back too. You are obviously aware of that because you have specified a downstream rule for 7 on FWB.

Right, now I've on FWB:

root@vml000210:~# ip -6 ro
2003:YYYY:ZZZZ:7600::/64 dev net0 proto kernel metric 256 pref medium
2003:YYYY:ZZZZ:7603::/64 dev net1 proto kernel metric 256 pref medium
2003:YYYY:ZZZZ::/64 via 2003:YYYY:ZZZZ:7603:10::110 dev net1 metric 1024 pref medium
fd00::/64 dev net0 proto kernel metric 256 pref medium
fd00:0:0:3::/64 dev net1 proto kernel metric 256 pref medium
fd00:0:0:7::/64 via fd00::3:10:0:0:110 dev net1 metric 1024 pref medium
fe80::/64 dev net0 proto kernel metric 256 pref medium
fe80::/64 dev net1 proto kernel metric 256 pref medium
default via fe80::7ac5:7dff:fefd:1c10 dev net0 proto static metric 1024 pref medium
-thc wrote:

Well - FWA needs two rules: Where to send packets destined for 3 and for 7.

List of configured static routes
Here you can see the list of configured static routes created for your LAN interfaces.
Name 	Destination  Network
IDMZ    GUA 	     2003:a:e0d:7603::/64 	
IDMZ    ULA 	     fd00:0:0:3::/64 	
INTRA   GUA 	     2003:a:e0d:7607::/64 	
INTRA   ULA 	     fd00:0:0:7::/64

As I mentioned above, I added the two routes to the FWA via its web UI. Interestingly, I can see the routes I defined under the SETTINGS menu item. However, the routes to the ULAs are not displayed under the SHOW ROUTES menu item. Regardless, the main thing is that it works now!

-thc, I would like to express my sincere thanks for your invaluable help and persistence, which helped me tremendously with my PEBCAK!

Offline

#14 2026-01-21 22:48:11

-thc
Member
Registered: 2017-03-15
Posts: 1,086

Re: [Solved] IPv6 routing issue

Very nice. \o/

Please mark your post "[Solved]" (by editing the first posts subject).

Last edited by -thc (2026-01-21 22:49:34)

Offline

Board footer

Powered by FluxBB