You are not logged in.
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=noand
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=ipv6This 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 foreverRouting 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 mediumThis 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 msroot@vml000210:~# dig AAAA bbs.archlinux.org +short
2a01:4f8:c2c:b1cf::1root@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 1492Evaluating 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:210OK, 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.142and
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/24There 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 foreverRouting 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 mediumDNS works fine:
root@vml000110:~# dig A bbs.archlinux.org +short
116.203.93.142Asking about my official IPv4 address i can see:
root@vml000110:~# curl -4 ip.sb
AAA.BBB.CCC.DDDAsking an external unfriendly DNS server works well:
root@vml000110:~# dig @8.8.8.8 A archlinux.org +short
209.126.35.79But 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.sbWhen 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
^CIf 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'
successThe 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 1492However, 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:210Here, 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
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
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.
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.
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
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=nothis 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 foreverAre you satisfied with me so far? I hope so! ![]()
Last edited by Django [BOfH] (2026-01-20 14:32:28)
Offline
... 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 REACHABLEFirewall 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 STALEFirewall 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 STALEEDMZ 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
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 FAILEDThere seem to be a problem between A and C: Is A aware of the route to C (as I mentioned)?
Offline
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.
From Firewall C:
fd00::3:10:0:0:110 dev eth0 FAILEDThere 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/64Pardon, but I can't see my error.
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
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 REACHABLEfd00::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... ![]()
Offline
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
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! ![]()
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 foreverWhy 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 mediumI 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. ![]()
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
As I promised, I'm back and here I'm with my stupid questions!
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
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
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
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:210IPv4 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::110Yeahhhhhhh \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::/64Your "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!
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!
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 mediumWell - 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::/64As 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
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