Hello,
here I am again and I hope you can help me as you did in January this year and give me THE crucial tip.
My environment:
### Internet ### ^ | V +-----------+ | | | FWA | | | +-----------+ ^ | --EDMZ--+----------------- [special devices] | V eth0 +-----------+ | | | FWB | vml000210 | | +-----------+ ^ eth1 | --IDMZ--+------------------ [web, mail ...] | V eth0 +-----------+ | | | FWC | vml000110 | | +-----------+ ^ eth1 | --------+-----Intranet----- [mobile devices, notebooks, phones ...]
Okay, so far so good, the diagram roughly shows my infrastructure at home. The two firewalls/routers FWB and FWC are virtual Archlinux hosts in a KVM environment.
The good thing is that I can access the internet from both VMs (FWB and FWC) and reach all services, such as DNS, WEB, MAIL, without any problems. I can also access services/daemons (ssh, smtp, http...) from the outside that are offered on these two VMs, for example!
But now comes the big BUT and my problems begin! If I connect my laptop to the interface eth1 of my internal firewall, I can access it via ICMP or SSH, for example. But everything else “behind” it, i.e. the FWB or even out to the internet, is starved across the board or blocked and not routed through by something or someone. But I currently have absolutely no other explanation than PEBCAK for my problem!
So now we come to the configuration:
======================================================================= First, let's take a look at the external firewall (EDMZ ← → IDMZ) Virtual KVM Host vml000210
firewall FWB: -----------------------------------------------------------------------
I: IP Forwarding root@vml000210:~# sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding net.ipv4.ip_forward = 1 net.ipv6.conf.all.forwarding = 1 -----------------------------------------------------------------------
II: NETWORK root@vml000210:~# ip -6 -br addr lo UNKNOWN ::1/128 eth0 UP 2003:a:bcd:ef00:1720:17:2:210/64 fd00::172:17:2:210/64 fe80::1720:17ff:fe02:210/64 eth1 UP 2003:a:bcd:ef03:10::210/64 fd00::3:10:0:0:210/64 fe80::5054:ff:fe41:2102/64 -----------------------------------------------------------------------
III: ROUTING root@vml000210:~# ip -6 route 2003:a:bcd:ef00::/64 dev eth0 proto kernel metric 256 pref medium 2003:a:bcd:ef03::/64 dev eth1 proto kernel metric 256 pref medium fd00::/64 dev eth0 proto kernel metric 256 pref medium fd00:0:0:3::/64 dev eth1 proto kernel metric 256 pref medium fe80::/64 dev eth1 proto kernel metric 256 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium default via fe80::7ac5:7dff:fefd:1c10 dev eth0 proto static metric 1024 pref medium
The default gateway with the address fe80::7ac5:7dff:fefd:1c10 that is entered here is the LLA of the external FWA! -----------------------------------------------------------------------
IV: FIREWALL-DAEMON root@vml000210:~# firewall-cmd --zone=edmz --list-all edmz (default, active) target: default ingress-priority: 0 egress-priority: 0 icmp-block-inversion: no interfaces: eth0 sources: services: ports: protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv4" forward-port port="25" protocol="tcp" to-port="25" to-addr="10.0.0.110" rule family="ipv6" source address="2003:a:bcd:ef00::/64" service name="ssh" accept rule family="ipv6" forward-port port="465" protocol="tcp" to-port="465" to-addr="2003:a:bcd:ef03:10::110" rule family="ipv4" forward-port port="587" protocol="tcp" to-port="587" to-addr="10.0.0.110" rule family="ipv4" forward-port port="41022" protocol="tcp" to-port="22" rule family="ipv6" forward-port port="41022" protocol="tcp" to-port="22" rule family="ipv6" forward-port port="587" protocol="tcp" to-port="587" to-addr="2003:a:bcd:ef03:10::110" rule family="ipv4" source address="172.17.2.0/24" service name="ssh" accept rule family="ipv6" forward-port port="25" protocol="tcp" to-port="25" to-addr="2003:a:bcd:ef03:10::110" rule family="ipv4" forward-port port="465" protocol="tcp" to-port="465" to-addr="10.0.0.110" rule family="ipv6" icmp-type name="echo-request" accept
root@vml000210:~# firewall-cmd --policy=edmz_2_idmz --list-all edmz_2_idmz (active) priority: -1 target: REJECT ingress-zones: edmz egress-zones: idmz services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv6" destination address="2003:a:bcd:ef03:10::110" icmp-type name="echo-request" accept rule family="ipv4" destination address="10.0.0.110" port port="25" protocol="tcp" accept rule family="ipv6" destination address="2003:a:bcd:ef03:10::110" port port="25" protocol="tcp" accept rule family="ipv4" destination address="10.0.0.110" port port="465" protocol="tcp" accept rule family="ipv6" destination address="2003:a:bcd:ef03:10::110" port port="465" protocol="tcp" accept rule family="ipv4" destination address="10.0.0.110" port port="587" protocol="tcp" accept rule family="ipv6" destination address="2003:a:bcd:ef03:10::110" port port="587" protocol="tcp" accept
root@vml000210:~# firewall-cmd --zone=idmz --list-all idmz (active) target: default ingress-priority: 0 egress-priority: 0 icmp-block-inversion: no interfaces: eth1 sources: services: ssh ports: protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv6" forward-port port="41022" protocol="tcp" to-port="22" rule family="ipv4" forward-port port="41022" protocol="tcp" to-port="22"
root@vml000210:~# firewall-cmd --policy=idmz_2_edmz --list-all idmz_2_edmz (active) priority: -1 target: ACCEPT ingress-zones: idmz egress-zones: edmz services: ports: protocols: masquerade: yes forward-ports: source-ports: icmp-blocks: rich rules:
======================================================================= And here we have the configuration details for the internal firewall. (IDMZ ←→ INTRANET) Virtual KVM Host vml000110
firewall FWC: -----------------------------------------------------------------------
I: IP Forwarding root@vml000110:~# sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding net.ipv4.ip_forward = 1 net.ipv6.conf.all.forwarding = 1 -----------------------------------------------------------------------
II: NETWORK root@vml000110:~# ip -6 -br addr lo UNKNOWN ::1/128 eth0 UP 2003:a:bcd:ef03:10::110/64 fd00::3:10:0:0:110/64 fe80::5054:ff:fe41:1101/64 eth1 UP 2003:a:bcd:ef07:10:0:10:110/64 fd00::7:10:0:10:110/64 fe80::5054:ff:fe41:1102/64 -----------------------------------------------------------------------
III: ROUTING root@vml000110:~# ip -6 route 2003:a:bcd:ef03::/64 dev eth0 proto kernel metric 256 pref medium 2003:a:bcd:ef07::/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 fd00::3:10:0:0:210 dev eth0 proto static metric 1024 pref medium
The default gateway with the address fd00::3:10:0:0:210 is here the ULA of firewall FWB! -----------------------------------------------------------------------
IV: FIREWALL-DAEMON root@vml000110:~# firewall-cmd --zone=idmz --list-all idmz (default, active) target: default ingress-priority: 0 egress-priority: 0 icmp-block-inversion: no interfaces: eth0 sources: services: ssh ports: 25/tcp 465/tcp 587/tcp protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv4" source address="10.0.0.0/24" destination address="10.0.0.110/32" port port="123" protocol="udp" accept rule family="ipv6" source address="2003:a:bcd:ef03::/64" destination address="2003:a:bcd:ef03:10::110/64" port port="123" protocol="udp" accept rule family="ipv6" source address="fd00::/10" destination address="fd00::3:10:0:0:110/64" port port="123" protocol="udp" accept rule family="ipv6" icmp-type name="echo-request" accept
root@vml000110:~# firewall-cmd --policy=idmz_2_intra --list-all idmz_2_intra (active) priority: -1 target: REJECT ingress-zones: idmz egress-zones: intra services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
root@vml000110:~# firewall-cmd --zone=intra --list-all intra (active) target: default ingress-priority: 0 egress-priority: 0 icmp-block-inversion: no interfaces: eth1 sources: services: dhcp dhcpv6 smtp ssh ports: protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv6" source address="2003:a:bcd:ef07::/64" destination address="2003:a:bcd:ef07:10:0:10:110/64" port port="123" protocol="udp" accept rule family="ipv4" source address="10.0.10.0/24" service name="ssh" accept rule family="ipv6" source address="fd00::/10" destination address="fd00::7:10:0:0:110/64" port port="123" protocol="udp" accept rule family="ipv6" source address="2003:a:bcd:ef07::/64" service name="ssh" accept rule family="ipv4" source address="10.0.10.0/24" destination address="10.0.10.110/32" port port="123" protocol="udp" accept rule family="ipv6" icmp-type name="echo-request" accept
root@vml000110:~# firewall-cmd --policy=intra_2_idmz --list-all intra_2_idmz (active) priority: -1 target: ACCEPT ingress-zones: intra egress-zones: idmz services: ports: protocols: masquerade: yes forward-ports: source-ports: icmp-blocks: rich rules:
======================================================================= TRAFFIC: IDMZ-FW (FWC) → EDMZ-FW (FWB) "outgoing"
1) ping to LLA (eth1) root@vml000110:~# ping -6 -c4 fe80::5054:ff:fe41:2102%eth0 PING fe80::5054:ff:fe41:2102%eth0 (fe80::5054:ff:fe41:2102%eth0) 56 data bytes 64 bytes from fe80::5054:ff:fe41:2102%eth0: icmp_seq=1 ttl=64 time=0.554 ms 64 bytes from fe80::5054:ff:fe41:2102%eth0: icmp_seq=2 ttl=64 time=0.435 ms 64 bytes from fe80::5054:ff:fe41:2102%eth0: icmp_seq=3 ttl=64 time=0.430 ms 64 bytes from fe80::5054:ff:fe41:2102%eth0: icmp_seq=4 ttl=64 time=0.434 ms
--- fe80::5054:ff:fe41:2102%eth0 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3036ms rtt min/avg/max/mdev = 0.430/0.463/0.554/0.052 ms
2) ping to ULA (eth1) root@vml000110:~# ping -6 -c4 fd00::3:10:0:0:210 PING fd00::3:10:0:0:210 (fd00::3:10:0:0:210) 56 data bytes 64 bytes from fd00::3:10:0:0:210: icmp_seq=1 ttl=64 time=0.443 ms 64 bytes from fd00::3:10:0:0:210: icmp_seq=2 ttl=64 time=0.433 ms 64 bytes from fd00::3:10:0:0:210: icmp_seq=3 ttl=64 time=0.461 ms 64 bytes from fd00::3:10:0:0:210: icmp_seq=4 ttl=64 time=0.476 ms
--- fd00::3:10:0:0:210 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3040ms rtt min/avg/max/mdev = 0.433/0.453/0.476/0.016 ms
3) ping to GUA (eth1) root@vml000110:~# ping -6 -c4 2003:a:bcd:ef03:10::210 PING 2003:a:bcd:ef03:10::210 (2003:a:bcd:ef03:10::210) 56 data bytes 64 bytes from 2003:a:bcd:ef03:10::210: icmp_seq=1 ttl=64 time=0.448 ms 64 bytes from 2003:a:bcd:ef03:10::210: icmp_seq=2 ttl=64 time=0.424 ms 64 bytes from 2003:a:bcd:ef03:10::210: icmp_seq=3 ttl=64 time=0.424 ms 64 bytes from 2003:a:bcd:ef03:10::210: icmp_seq=4 ttl=64 time=0.417 ms
--- 2003:a:bcd:ef03:10::210 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3033ms rtt min/avg/max/mdev = 0.417/0.428/0.448/0.011 ms
4) ping to ULA (eth0) root@vml000110:~# ping -6 -c4 fd00::172:17:2:210 PING fd00::172:17:2:210 (fd00::172:17:2:210) 56 data bytes 64 bytes from fd00::172:17:2:210: icmp_seq=1 ttl=64 time=0.488 ms 64 bytes from fd00::172:17:2:210: icmp_seq=2 ttl=64 time=0.390 ms 64 bytes from fd00::172:17:2:210: icmp_seq=3 ttl=64 time=0.518 ms 64 bytes from fd00::172:17:2:210: icmp_seq=4 ttl=64 time=0.341 ms
--- fd00::172:17:2:210 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3038ms rtt min/avg/max/mdev = 0.341/0.434/0.518/0.071 ms
5) ping to GUA (eth0) root@vml000110:~# ping -6 -c4 2003:a:bcd:ef00:1720:17:2:210 PING 2003:a:bcd:ef00:1720:17:2:210 (2003:a:bcd:ef00:1720:17:2:210) 56 data bytes 64 bytes from 2003:a:bcd:ef00:1720:17:2:210: icmp_seq=1 ttl=64 time=0.434 ms 64 bytes from 2003:a:bcd:ef00:1720:17:2:210: icmp_seq=2 ttl=64 time=0.254 ms 64 bytes from 2003:a:bcd:ef00:1720:17:2:210: icmp_seq=3 ttl=64 time=0.410 ms 64 bytes from 2003:a:bcd:ef00:1720:17:2:210: icmp_seq=4 ttl=64 time=0.518 ms
--- 2003:a:bcd:ef00:1720:17:2:210 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3032ms rtt min/avg/max/mdev = 0.254/0.404/0.518/0.095 ms
======================================================================= TRAFFIC: IDMZ-FW (FWC) → Internet
1) DNS root@vml000110:~# host -t AAAA heise.de heise.de has IPv6 address 2a02:2e0:3fe:1001:302::
2) ping to heise.de root@vml000110:~# ping -6 -c4 2a02:2e0:3fe:1001:302:: PING 2a02:2e0:3fe:1001:302:: (2a02:2e0:3fe:1001:302::) 56 data bytes 64 bytes from 2a02:2e0:3fe:1001:302::: icmp_seq=1 ttl=56 time=13.0 ms 64 bytes from 2a02:2e0:3fe:1001:302::: icmp_seq=2 ttl=56 time=13.6 ms 64 bytes from 2a02:2e0:3fe:1001:302::: icmp_seq=3 ttl=56 time=13.3 ms 64 bytes from 2a02:2e0:3fe:1001:302::: icmp_seq=4 ttl=56 time=13.2 ms
--- 2a02:2e0:3fe:1001:302:: ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3005ms rtt min/avg/max/mdev = 12.952/13.245/13.606/0.237 ms
======================================================================= TRAFFIC: EMZ-FW (FWB) → IDMZ-FW (FWC) "incoming"
1) ping to LLA eth0 root@vml000210:~# ping -6c4 fe80::5054:ff:fe41:1101%eth1 PING fe80::5054:ff:fe41:1101%eth1 (fe80::5054:ff:fe41:1101%eth1) 56 data bytes 64 bytes from fe80::5054:ff:fe41:1101%eth1: icmp_seq=1 ttl=64 time=0.637 ms 64 bytes from fe80::5054:ff:fe41:1101%eth1: icmp_seq=2 ttl=64 time=0.593 ms 64 bytes from fe80::5054:ff:fe41:1101%eth1: icmp_seq=3 ttl=64 time=0.502 ms 64 bytes from fe80::5054:ff:fe41:1101%eth1: icmp_seq=4 ttl=64 time=0.505 ms
--- fe80::5054:ff:fe41:1101%eth1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3040ms rtt min/avg/max/mdev = 0.502/0.559/0.637/0.057 ms
2) ping to ULA eth0 root@vml000210:~# ping -6c4 fd00::3:10:0:0:110 PING fd00::3:10:0:0:110 (fd00::3:10:0:0:110) 56 data bytes 64 bytes from fd00::3:10:0:0:110: icmp_seq=1 ttl=64 time=0.438 ms 64 bytes from fd00::3:10:0:0:110: icmp_seq=2 ttl=64 time=0.406 ms 64 bytes from fd00::3:10:0:0:110: icmp_seq=3 ttl=64 time=0.430 ms 64 bytes from fd00::3:10:0:0:110: icmp_seq=4 ttl=64 time=0.434 ms
--- fd00::3:10:0:0:110 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3046ms rtt min/avg/max/mdev = 0.406/0.427/0.438/0.012 ms
3) ping to GUA eth0 root@vml000210:~# ping -6c4 2003:a:bcd:ef03:10::110 PING 2003:a:bcd:ef03:10::110 (2003:a:bcd:ef03:10::110) 56 data bytes 64 bytes from 2003:a:bcd:ef03:10::110: icmp_seq=1 ttl=64 time=0.522 ms 64 bytes from 2003:a:bcd:ef03:10::110: icmp_seq=2 ttl=64 time=0.601 ms 64 bytes from 2003:a:bcd:ef03:10::110: icmp_seq=3 ttl=64 time=0.387 ms 64 bytes from 2003:a:bcd:ef03:10::110: icmp_seq=4 ttl=64 time=0.507 ms
--- 2003:a:bcd:ef03:10::110 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3051ms rtt min/avg/max/mdev = 0.387/0.504/0.601/0.076 ms
4) ping to ULA eth1 (interface whos shows to the intranet!) root@vml000210:~# ping -6c4 fd00::7:10:0:10:110 PING fd00::7:10:0:10:110 (fd00::7:10:0:10:110) 56 data bytes
--- fd00::7:10:0:10:110 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3035ms
Route to the ULA from eth1 of the IDMZ firewall (FWC): root@vml000210:~# ip route get fd00::7:10:0:10:110 fd00::7:10:0:10:110 from :: via fe80::7ac5:7dff:fefd:1c10 dev eth0 proto static src fd00::172:17:2:210 metric 1024 pref medium
5) ping to GUA eth1 root@vml000210:~# ping -6c4 2003:a:bcd:ef07:10:0:10:110 PING 2003:a:bcd:ef07:10:0:10:110 (2003:a:bcd:ef07:10:0:10:110) 56 data bytes
--- 2003:a:bcd:ef07:10:0:10:110 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3035ms
Route to the GUA from eth1 of the IDMZ firewall (FWC): root@vml000210:~# ip route get 2003:a:bcd:ef07:10:0:10:110 2003:a:bcd:ef07:10:0:10:110 from :: via fe80::7ac5:7dff:fefd:1c10 dev eth0 proto static src 2003:a:bcd:ef00:1720:17:2:210 metric 1024 pref medium
In both cases, fe80::7ac5:7dff:fefd:1c10 is the default gateway of the EDMZ firewall in the direction of the DSL router, i.e. the ULA of the DSL router!
======================================================================= TRAFFIC: EDMZ-FW (FWB) → Internet
1) DNS root@vml000210:~# host -t AAAA heise.de heise.de has IPv6 address 2a02:2e0:3fe:1001:302::
2) ping to heise.de root@vml000210:~# ping -6 -c4 2a02:2e0:3fe:1001:302:: PING 2a02:2e0:3fe:1001:302:: (2a02:2e0:3fe:1001:302::) 56 data bytes 64 bytes from 2a02:2e0:3fe:1001:302::: icmp_seq=1 ttl=56 time=13.0 ms 64 bytes from 2a02:2e0:3fe:1001:302::: icmp_seq=2 ttl=56 time=13.6 ms 64 bytes from 2a02:2e0:3fe:1001:302::: icmp_seq=3 ttl=56 time=13.3 ms 64 bytes from 2a02:2e0:3fe:1001:302::: icmp_seq=4 ttl=56 time=13.2 ms
--- 2a02:2e0:3fe:1001:302:: ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3005ms rtt min/avg/max/mdev = 12.952/13.245/13.606/0.237 ms
=======================================================================
However, if I now connect my laptop directly to the network interface, which is connected directly from the KVM host to the virtual machine vml000110 using a bridge, I get the following configuration parameters from the host vml000110's radvd and kea-dhcp6:
----------------------------------------------------------------------- I) NETWORK
root@nitropad:~# ip -6 -br addr lo UNKNOWN ::1/128 enp0s25 UP fd00::7:10:0:10:73/64 2003:a:bcd:ef07:10:0:10:73/64 fe80::9f6c:de76:b191:9938/64 -----------------------------------------------------------------------
II) ROUTING
root@nitropad:~# ip -6 route ::1 dev lo proto kernel metric 256 pref medium 2003:a:bcd:ef07::/64 dev enp0s25 proto kernel metric 100 pref medium fd00:0:0:7::/64 dev enp0s25 proto kernel metric 100 pref medium fe80::/64 dev enp0s25 proto kernel metric 1024 pref medium default via fe80::5054:ff:fe41:1102 dev enp0s25 proto static metric 20100 pref medium
The default gateway with the address fe80::5054:ff:fe41:1102 is the LLA of the internal firewall FBC with the network interface eth1, i.e. the direct partner to which the laptop is connected!
======================================================================= TRAFFIC: Laptop → IDMZ-FW (FWC) "outgoing"
I can access the internal firewall FWC from my laptop without any problems:
1) ping to LLA eth1 of FWC: root@nitropad:~# ping -6c4 fe80::5054:ff:fe41:1102%enp0s25 PING fe80::5054:ff:fe41:1102%enp0s25(fe80::5054:ff:fe41:1102%enp0s25) 56 data bytes 64 bytes from fe80::5054:ff:fe41:1102%enp0s25: icmp_seq=1 ttl=64 time=0.511 ms 64 bytes from fe80::5054:ff:fe41:1102%enp0s25: icmp_seq=2 ttl=64 time=0.491 ms 64 bytes from fe80::5054:ff:fe41:1102%enp0s25: icmp_seq=3 ttl=64 time=0.490 ms 64 bytes from fe80::5054:ff:fe41:1102%enp0s25: icmp_seq=4 ttl=64 time=0.574 ms
--- fe80::5054:ff:fe41:1102%enp0s25 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3068ms rtt min/avg/max/mdev = 0.490/0.516/0.574/0.034 ms
2) ping to ULA of FWC - eth1: root@nitropad:~# ping -6c4 fd00::7:10:0:10:110 PING fd00::7:10:0:10:110(fd00::7:10:0:10:110) 56 data bytes 64 bytes from fd00::7:10:0:10:110: icmp_seq=1 ttl=64 time=1.01 ms 64 bytes from fd00::7:10:0:10:110: icmp_seq=2 ttl=64 time=0.533 ms 64 bytes from fd00::7:10:0:10:110: icmp_seq=3 ttl=64 time=0.576 ms 64 bytes from fd00::7:10:0:10:110: icmp_seq=4 ttl=64 time=0.543 ms
--- fd00::7:10:0:10:110 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3031ms rtt min/avg/max/mdev = 0.533/0.666/1.012/0.200 ms
3) ping to GUA of FWC - eth1: root@nitropad:~# ping -6c4 2003:a:bcd:ef07:10:0:10:110 PING 2003:a:bcd:ef07:10:0:10:110(2003:a:bcd:ef:07:10:0:10:110) 56 data bytes 64 bytes from 2003:a:bcd:ef07:10:0:10:110: icmp_seq=1 ttl=64 time=0.816 ms 64 bytes from 2003:a:bcd:ef07:10:0:10:110: icmp_seq=2 ttl=64 time=0.485 ms 64 bytes from 2003:a:bcd:ef07:10:0:10:110: icmp_seq=3 ttl=64 time=0.496 ms 64 bytes from 2003:a:bcd:ef07:10:0:10:110: icmp_seq=4 ttl=64 time=0.450 ms
--- 2003:a:bcd:ef07:10:0:10:110 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3054ms rtt min/avg/max/mdev = 0.450/0.561/0.816/0.147 ms
4) ping to GUA of FWC - eth0 (this is the connection to external firewall EDMZ FWB): root@nitropad:~# ping -6c4 2003:a:bcd:ef03:10:0:0:110 PING 2003:a:bcd:ef03:10:0:0:110(2003:a:bcd:ef03:10::110) 56 data bytes 64 bytes from 2003:a:bcd:ef03:10::110: icmp_seq=1 ttl=64 time=0.458 ms 64 bytes from 2003:a:bcd:ef03:10::110: icmp_seq=2 ttl=64 time=0.373 ms 64 bytes from 2003:a:bcd:ef03:10::110: icmp_seq=3 ttl=64 time=0.462 ms 64 bytes from 2003:a:bcd:ef03:10::110: icmp_seq=4 ttl=64 time=0.506 ms
--- 2003:a:bcd:ef03:10:0:0:110 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3055ms rtt min/avg/max/mdev = 0.373/0.449/0.506/0.048 ms
5) But now comes the real HOLY SHIT: When I try to ping the interface eth1 of the EDMZ firewall (FWB) from my laptop, unfortunately only this happens: root@nitropad:~# ping -6c4 2003:a:bcd:ef:03:10:0:0:210 PING 2003:a:bcd:ef03:10:0:0:210(2003:a:bcd:ef03:10::210) 56 data bytes
--- 2003:a:bcd:ef:03:10:0:0:210 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3071ms
6) I see the same crap when I try to ping heise.de, for example: root@nitropad:~# ping -6c4 2a02:2e0:3fe:1001:302:: PING 2a02:2e0:3fe:1001:302::(2a02:2e0:3fe:1001:302::) 56 data bytes
--- 2a02:2e0:3fe:1001:302:: ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3055ms
=======================================================================
I just don't understand it. I can access the internet without any problems from both VMs. But as soon as I try to access FWB or the internet in front of it from the intranet, I mercilessly starve to death somewhere at the internal firewall FWC. I don't even think that the firewall is causing problems here, because the configuration of the same corresponds to that on the FWB (EDMZ-Firewall) My biggest guess is more in the direction of routing, but only where exactly have I made a mistake in my thinking and configuration. I just don't understand it.
That's why I'm hoping that someone here can help me out or point me in the right direction. I'd like to say a huge thank you in advance for even the tiniest hint!
Best regards Django
27.09.2024 17:55, Bastard Operator from Hell aka Django via firewalld-users wrote:
Hello,
here I am again and I hope you can help me as you did in January this year and give me THE crucial tip.
My environment:
### Internet ### ^ | V +-----------+ | | | FWA | | | +-----------+ ^ | --EDMZ--+----------------- [special devices] | V eth0 +-----------+ | | | FWB | vml000210 | | +-----------+ ^ eth1 | --IDMZ--+------------------ [web, mail ...] | V eth0 +-----------+ | | | FWC | vml000110 | | +-----------+ ^ eth1 | --------+-----Intranet----- [mobile devices, notebooks, phones ...]
Okay, so far so good, the diagram roughly shows my infrastructure at home. The two firewalls/routers FWB and FWC are virtual Archlinux hosts in a KVM environment.
The good thing is that I can access the internet from both VMs (FWB and FWC) and reach all services, such as DNS, WEB, MAIL, without any problems. I can also access services/daemons (ssh, smtp, http...) from the outside that are offered on these two VMs, for example!
But now comes the big BUT and my problems begin! If I connect my laptop to the interface eth1 of my internal firewall, I can access it via ICMP or SSH, for example. But everything else “behind” it, i.e. the FWB or even out to the internet, is starved across the board or blocked and not routed through by something or someone.
Does it start to work if you stop firewalld?
Hello Andrei,
Am 27.09.24 um 8:30 PM schrieb Andrei Borzenkov via firewalld-users:
Does it start to work if you stop firewalld?
If I stop firewalld on vml000210 (FWB) then no traffic from vml000110 (FWC) will be routet through FWB to the internet!
Stopping the firewald daemon on host vml000110 (FWC) does not change the fact that I can only ping the interfaces of the FWC eth0 and eth1 from the laptop, but I cannot reach the FWB or the internet!
Best regards
Hello Andrei, hello mailinglist,
If I tray to ping GUA of my external FW (FWB - vml000210) I see this here: django@nitropad:~$ ping -c4 2003:a:bcd:ef00:1720:17:2:210 PING 2003:a:bcd:ef00:1720:17:2:210(2003:a:bcd:ef00:1720:17:2:210) 56 data bytes
--- 2003:a:bcd:ef00:1720:17:2:210 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3055ms
So the already familiar “error” message.
If I now try to determine the route to this host from the intranet using my laptop, I see this:
django@nitropad:~$ tracepath 2003:a:bcd:ef00:1720:17:2:210 1?: [LOCALHOST] 0.021ms pmtu 1500 1: 2003:a:bcd:ef07:10:0:10:110 0.566ms 1: 2003:a:bcd:ef07:10:0:10:110 0.525ms 2: 2003:a:bcd:ef07:10:0:10:110 0.418ms !A Resume: pmtu 1500
2003:a:e0d:7607:10:0:10:110 is the network interface of my internal firewall that points towards the intranet.
In the journal, I see that the intra_2_idmz policy caused a REJECT here.
Sep 29 17:29:10 vml000110 kernel: filter_FWD_policy_intra_2_idmz_REJECT: IN=eth1 OUT=eth0 MAC=52:54:00:41:11:02:33:99:00:88:ee:dd:88:dd SRC=2003:000a:0bcd:ef07:73a8:1abc:5f72:d33a DST=2003:000a:0bcd:ef00:1720:0017:0002:0210 LEN=1500 TC=0 HOPLIMIT=1 FLOWLBL=734845 PROTO=UDP SPT=55854 DPT=44446 LEN=1460
In the case of tracepath, the firewall is giving me a hard time, or, to be more precise, my guess as to where the problem lies is correct: PEBCAK!
Okay, so now the question is, which ICMP types should be enabled in terms of best practice with regard to tracepath?
Best regards
On Sun, Sep 29, 2024 at 05:51:55PM +0200, Bastard Operator from Hell aka Django via firewalld-users wrote:
Hello Andrei, hello mailinglist,
If I tray to ping GUA of my external FW (FWB - vml000210) I see this here: django@nitropad:~$ ping -c4 2003:a:bcd:ef00:1720:17:2:210 PING 2003:a:bcd:ef00:1720:17:2:210(2003:a:bcd:ef00:1720:17:2:210) 56 data bytes
--- 2003:a:bcd:ef00:1720:17:2:210 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3055ms
So the already familiar “error” message.
If I now try to determine the route to this host from the intranet using my laptop, I see this:
django@nitropad:~$ tracepath 2003:a:bcd:ef00:1720:17:2:210 1?: [LOCALHOST] 0.021ms pmtu 1500 1: 2003:a:bcd:ef07:10:0:10:110 0.566ms 1: 2003:a:bcd:ef07:10:0:10:110 0.525ms 2: 2003:a:bcd:ef07:10:0:10:110 0.418ms !A Resume: pmtu 1500
2003:a:e0d:7607:10:0:10:110 is the network interface of my internal firewall that points towards the intranet.
In the journal, I see that the intra_2_idmz policy caused a REJECT here.
Sep 29 17:29:10 vml000110 kernel: filter_FWD_policy_intra_2_idmz_REJECT: IN=eth1 OUT=eth0 MAC=52:54:00:41:11:02:33:99:00:88:ee:dd:88:dd SRC=2003:000a:0bcd:ef07:73a8:1abc:5f72:d33a DST=2003:000a:0bcd:ef00:1720:0017:0002:0210 LEN=1500 TC=0 HOPLIMIT=1 FLOWLBL=734845 PROTO=UDP SPT=55854 DPT=44446 LEN=1460
In the case of tracepath, the firewall is giving me a hard time, or, to be more precise, my guess as to where the problem lies is correct: PEBCAK!
Okay, so now the question is, which ICMP types should be enabled in terms of best practice with regard to tracepath?
Why not allow all ICMP? IPv6 especially heavily relies upon it.
tracepath/traceroute typically use UDP, not ICMP. That jibes with your dropped packet above; it's UDP.
HI Eric!
Am 30.09.24 um 7:59 PM schrieb Eric Garver via firewalld-users:
Why not allow all ICMP? IPv6 especially heavily relies upon it.
' cause I'm a little bit paranoid and stupid, as you know! ;)
I currently have the following ICMMP types released: echo-reply echo-request fragmentation-needed neighbour-advertisement neighbour-solicitation packet-too-big port-unreachable router-advertisement router-solicitation time-exceeded
As you can see here:
root@vml000110:~# firewall-cmd --zone=intra --list-all intra (active) target: default ingress-priority: 0 egress-priority: 0 icmp-block-inversion: yes interfaces: eth1 sources: services: dhcp dhcpv6 smtp ssh ports: protocols: forward: no masquerade: no forward-ports: source-ports: icmp-blocks: echo-reply echo-request fragmentation-needed neighbour-advertisement neighbour-solicitation packet-too-big port-unreachable router-advertisement router-solicitation time-exceeded rich rules: rule family="ipv6" source address="2003:a:bcd:ef07::/64" service name="ssh" accept rule family="ipv4" source address="10.0.10.0/24" destination address="10.0.10.110/32" port port="123" protocol="udp" accept rule family="ipv4" source address="10.0.10.0/24" service name="ssh" accept rule family="ipv6" source address="fd00::/10" destination address="fd00::7:10:0:0:110/64" port port="123" protocol="udp" accept rule family="ipv6" source address="2003:a:bcd:ef07::/64" destination address="2003:a:bcd:ef07:10:0:10:110/64" port port="123" protocol="udp" accept
*BUT*: The mistake in reasoning and probably the deviously hidden configuration error that I made there, IMHO, is not with the firewall but deeper, perhaps routing or something, I would boldly want to claim. Why, today I took another closer look at my test lab network.
Here once again my SOHO-LAB-NETWORK: ### Internet ### ^ | V +-----------+ | | | FWA | | | +-----------+ ^ | ----EDMZ----+----------------- [special devices] | V eth0 +-----------+ | | | FWB | vml000210 | | +-----------+ ^ eth1 | ----IDMZ----+------------------ [web, mail ...] | V eth0 +-----------+ | | | FWC | vml000110 | | +-----------+ ^ eth1 +----------+ | | | --INTRANET--+---------->| Laptop | nitropad | | +----------+
I can access the internet from host FWB (virtual machine vml000210) without any problems. The same applies to host FWC (virtual machine vml000110). From there, I can access host FWB and the internet without any problems!
But if I now connect directly to my laptop (host nitropad), then I can: 1) Ping from host FWC to host nitropad, whether on its LLA, its ULA or the GUA! 2) From host nitropad, I can ping the LLA, ULA and GUA of eth1 of host FWC. Likewise, I can ping the eth0 interface of the FWC host on its ULA and GUA without any problems! From the nitropad host, I can access the SSH daemon on the FWC host, regardless of whether I address the LLA, ULA or GUA of the eth1 or, alternatively, the ULA or GUA of the eth0 interface of my FWC host.
BUT where I run into problems is the following: If I try to ping the GUA 2003:a:bcd:ef03:10:0:0:210 (IDMZ interface = eth1) of FWB via transit accounts FWC from my laptop, I crash and burn. :(
root@nitropad:~# ping -c4 2003:a:bcd:ef03:10:0:0:210 PING 2003:a:bcd:ef03:10:0:0:210(2003:a:bcd:ef03:10::210) 56 data bytes --- 2003:a:bcd:ef03:10:0:0:210 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3072ms
The following traffic is running on the internal interface eth1 of the FWC:
root@vml000110:~# tcpdump -ni eth1 | grep IP6 16:27:59.651554 IP6 2003:a:bcd:ef07:759:b95d:a140:3801 > 2003:a:bcd:ef03:10::210: ICMP6, echo request, id 59, seq 1, length 64 16:28:00.675598 IP6 2003:a:bcd:ef07:759:b95d:a140:3801 > 2003:a:bcd:ef03:10::210: ICMP6, echo request, id 59, seq 2, length 64
The following traffic is running on the IDMZ interface eth0of the FWC:
root@vml000110:~# tcpdump -ni eth0 | grep IP6 16:27:59.651575 IP6 2003:a:bcd:ef07:759:b95d:a140:3801 > 2003:a:bcd:ef03:10::210: ICMP6, echo request, id 59, seq 1, length 64 16:28:00.675636 IP6 2003:a:bcd:ef07:759:b95d:a140:3801 > 2003:a:bcd:ef03:10::210: ICMP6, echo request, id 59, seq 2, length 64
The following traffic is running on the IDMZ interface eth1 of the FWB:
root@vml000210:~# tcpdump -ni eth2 | grep IP6
16:27:59.651328 IP6 2003:a:bcd:ef07:759:b95d:a140:3801 > 2003:a:bcd:ef03:10::210: ICMP6, echo request, id 59, seq 1, length 64 16:28:00.675405 IP6 2003:a:bcd:ef07:759:b95d:a140:3801 > 2003:a:bcd:ef03:10::210: ICMP6, echo request, id 59, seq 2, length 64
It doesn't matter whether the firewalld is running on the FWC and/or FWB or not!
So Eric, now we need your wise expertise. Do you have any idea why the traffic from the intranet can't get past the intranet firewall/router host FWC? I just don't understand it. I'm starting to think I'm either too old or too ddof for IPv6. ;(
Best regards
HI Eric,
Am 30.09.24 um 7:59 PM schrieb Eric Garver via firewalld-users:
Why not allow all ICMP? IPv6 especially heavily relies upon it.
Of course I completely agree with you that blocking ICMP is generally not a particularly good idea, especially with IPv6. So for outgoing, an
icmp-type name=“echo-request” accept
would certainly be expedient. Isn't it?
But when it comes to incoming external traffic, you should differentiate a little. Or what do you say, specialist?
Best regards
HI Eric
Am 30.09.24 um 7:59 PM schrieb Eric Garver via firewalld-users:
Why not allow all ICMP?
Why? Well, I love good documentation like this one:
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/con...
And I may quote briefly: ICMP filtering helps, for example, in the following areas:
° Security enhancement - Block potentially harmful ICMP types and codes to reduce your attack surface. ° Network performance - Permit only necessary ICMP types to optimize network performance and prevent potential network congestion caused by excessive ICMP traffic. ° Troubleshooting control - Maintain essential ICMP functionality for network troubleshooting and block ICMP types that represent potential security risk.
Why not allow all ICMP? IPv6 especially heavily relies upon it.
But what is the best approach in terms of best practice? Generally allowing everything would work, but would contradict the advice in the Red Hat documentation. Outgoing traffic from the intranet zones or a DMZ does not speak against it, does it? But what about external traffic from the Internet? Allowing all ICMP traffic through unfiltered and responding to it may not be the best solution after all.
Eric, what do you think is the best way to proceed here?
Best regards
On 02.10.2024 11:32 Bastard Operator from Hell aka Django via firewalld-users wrote:
° Security enhancement - Block potentially harmful ICMP types and codes to reduce your attack surface. ° Network performance - Permit only necessary ICMP types to optimize network performance and prevent potential network congestion caused by excessive ICMP traffic. ° Troubleshooting control - Maintain essential ICMP functionality for network troubleshooting and block ICMP types that represent potential security risk.
There are no potential harmful ICMP packages that can come from outside the ethernet link. ND types will be discarded if they have a hop count of less than 255 (which means that they were processed by a router, which shouldn't be the case).
Echo request isn't a security risk and the other stuff like destination unreachable is very important to avoid timeouts - the machine knows that the packet can't be delivered and presents an error message to the application trying to connect - instead of letting it run into a timeout. The fragmentation and packet too big stuff is mandatory to enable communication to destinations with other MTU values, so don't block that at all, it will just cause a PITA when diagnosing strange timeout issues.
HI Marco!
Am 02.10.24 um 3:20 PM schrieb Marco Moock via firewalld-users:
There are no potential harmful ICMP packages that can come from outside the ethernet link.
ICMP packets are certainly not harmful, but there is a fundamental danger of using ICMP packets to find out the number and addresses of my hosts and devices in the intranet 2003:a:bcd:ef07::/64. OK, pinging them individually is admittedly a bit time-consuming, but it wouldn't be impossible. Or how do you see it?
The fragmentation and packet too big stuff is mandatory to enable communication to destinations with other MTU values, so don't block that at all, it will just cause a PITA when diagnosing strange timeout issues.
Oh yes I fully agree!
Best regards
Once upon a time, Bastard Operator from Hell aka Django django@nausch.org said:
my hosts and devices in the intranet 2003:a:bcd:ef07::/64. OK, pinging them individually is admittedly a bit time-consuming, but it wouldn't be impossible. Or how do you see it?
It's impractical, unless you're just numbering them from 1 or something. If you have gigabit ethernet, it would take almost 300,000 years to scan a single /64.
Am 02.10.2024 um 21:05:46 Uhr schrieb Bastard Operator from Hell aka Django via firewalld-users:
HI Marco!
Am 02.10.24 um 3:20 PM schrieb Marco Moock via firewalld-users:
There are no potential harmful ICMP packages that can come from outside the ethernet link.
ICMP packets are certainly not harmful, but there is a fundamental danger of using ICMP packets to find out the number and addresses of my hosts and devices in the intranet 2003:a:bcd:ef07::/64. OK, pinging them individually is admittedly a bit time-consuming, but it wouldn't be impossible. Or how do you see it?
If knowing the existence of a host is a security problem, you have another big security problem. :-) If you don't want that people can ping your hosts, reject the echo requests, but nothing else.
Those messages could be used to create a neighbor unreachable cache exhaust (an attacker will send ICMP echo requests (or other packets that are allowed to pass the firewall without being "related") by sending to many, many IPv6 addresses which don't exist, so no reply to the neighbor solicitation. The router will then keep them for some seconds and retry. Then it will create an entry in the ND cache. This cache can be exhausted and the RAM of the router because it keeps the packages until it sends the ICMP host unreachable message.
With IPv6 this is possible, but not limited to ICMP. TCP or UDP can also be used if allowed for all IP addresses in a net.
HI Marco,
Am 02.10.24 um 9:28 PM schrieb Marco Moock via firewalld-users:
If knowing the existence of a host is a security problem, you have another big security problem. :-)
That's right - as I always say, by far the biggest security problem is the supposed friend. These are thoughtless users or even admins who think they can do everything better and usually just make it worse. I personally don't exclude myself from this, I just want to do it as well as possible, safely and, above all, correctly; that is my aim.
If you don't want that people can ping your hosts, reject the echo requests, but nothing else.
OK, I completely agree with you on this. You shouldn't completely block ICMP requests, nor should you allow them completely everywhere. Instead, you should only block echo requests or only allow them where you consider it appropriate and correct.
Those messages could be used to create a neighbor unreachable cache exhaust (an attacker will send ICMP echo requests (or other packets that are allowed to pass the firewall without being "related") by sending to many, many IPv6 addresses which don't exist, so no reply to the neighbor solicitation. The router will then keep them for some seconds and retry. Then it will create an entry in the ND cache. This cache can be exhausted and the RAM of the router because it keeps the packages until it sends the ICMP host unreachable message.
Thank you, I think that's a very good explanation, thank you!
With IPv6 this is possible, but not limited to ICMP. TCP or UDP can also be used if allowed for all IP addresses in a net.
Don't panic, in the past, with IPv4, only the traffic that was desired, needed and permitted was allowed here as well. For each service or host, there were dedicated activations for UDP and TCP, based on destination IP addresses and, to some extent, on source IP addresses. I will implement it exactly the same way in the new dual-stack IPv4|6 environment.
On that note... Pfiade
On Wed, Oct 02, 2024 at 11:32:13AM +0200, Bastard Operator from Hell aka Django wrote:
HI Eric
Am 30.09.24 um 7:59 PM schrieb Eric Garver via firewalld-users:
Why not allow all ICMP?
Why? Well, I love good documentation like this one:
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/con...
And I may quote briefly: ICMP filtering helps, for example, in the following areas:
° Security enhancement - Block potentially harmful ICMP types and codes to reduce your attack surface. ° Network performance - Permit only necessary ICMP types to optimize network performance and prevent potential network congestion caused by excessive ICMP traffic.
Linux itself has some rate limiting and masking for ICMP.
[root@rhel ~]# sysctl -a |grep icmp net.ipv4.icmp_echo_enable_probe = 0 net.ipv4.icmp_echo_ignore_all = 0 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_errors_use_inbound_ifaddr = 0 net.ipv4.icmp_ignore_bogus_error_responses = 1 net.ipv4.icmp_msgs_burst = 50 net.ipv4.icmp_msgs_per_sec = 1000 net.ipv4.icmp_ratelimit = 1000 net.ipv4.icmp_ratemask = 6168 net.ipv6.icmp.echo_ignore_all = 0 net.ipv6.icmp.echo_ignore_anycast = 0 net.ipv6.icmp.echo_ignore_multicast = 0 net.ipv6.icmp.error_anycast_as_unicast = 0 net.ipv6.icmp.ratelimit = 1000 net.ipv6.icmp.ratemask = 0-1,3-127
° Troubleshooting control - Maintain essential ICMP functionality for network troubleshooting and block ICMP types that represent potential security risk.
Why not allow all ICMP? IPv6 especially heavily relies upon it.
But what is the best approach in terms of best practice? Generally allowing everything would work, but would contradict the advice in the Red Hat documentation. Outgoing traffic from the intranet zones or a DMZ does not speak against it, does it? But what about external traffic from the Internet? Allowing all ICMP traffic through unfiltered and responding to it may not be the best solution after all.
Eric, what do you think is the best way to proceed here?
There are a few categories of ICMP to consider.
1. ICMP related to connections, e.g. packet-too-big, pmtu - these must be allowed, luckily most of these are considered "related" to the connection and thus allowed by firewalld
2. ICMPv6 Neighbor Discovery - firewalld allows these by default, see policy "allow-host-ipv6" - essential for IPv6
3. ICMP diagnostic, e.g. echo-request - useful, mostly harmless to respond to "strangers"
4. ICMP control, e.g. redirects - could be used for malicious intent
Perhaps there are some ICMP types worth blocking. I don't have good advice on which to block and which to allow. I am not a network administrator.
FWIW, I personally don't block ICMP.
Hope that helps. E.
Am 02.10.2024 um 13:23:05 Uhr schrieb Eric Garver via firewalld-users:
- ICMP control, e.g. redirects
- could be used for malicious intent
Must have a hop-limit of 255 and can therefore only be abused on the same link, not from other people in the internet.
Same applies for other ND stuff.
HI Eric,
Am 02.10.24 um 7:23 PM schrieb Eric Garver via firewalld-users:
FWIW, I personally don't block ICMP.
The more I think about it, the more I almost agree with you that ICMP blocking should be avoided. Let's see what my network colleague has to say and whether he has any objections or tips in store.
Hope that helps.
But yes, your comments are very helpful!
Best regards and BTW best wishes to Bryson! ;)
On Tue, Oct 01, 2024 at 09:00:29PM +0200, Bastard Operator from Hell aka Django wrote:
HI Eric,
Am 30.09.24 um 7:59 PM schrieb Eric Garver via firewalld-users:
Why not allow all ICMP? IPv6 especially heavily relies upon it.
Of course I completely agree with you that blocking ICMP is generally not a particularly good idea, especially with IPv6. So for outgoing, an
icmp-type name=“echo-request” accept
would certainly be expedient. Isn't it?
By "outgoing" do you mean from you LAN or do you mean from the router/firewalld node?
For the LAN, allowing only echo-request may be okay. Some ICMP will be "related" to existing connections and thus be allowed.
For the node running firewalld, you don't want to block a lot of outgoing ICMPv6 because some are needed for IPv6 to function, e.g. neighbor discovery.
But when it comes to incoming external traffic, you should differentiate a little. Or what do you say, specialist?
You certainly can if you want.
HI Eric,
Am 02.10.24 um 7:09 PM schrieb Eric Garver via firewalld-users:
By "outgoing" do you mean from you LAN or do you mean from the router/firewalld node?
I meant outgoing here primarily in relation to the direction of traffic, so the definition is to be made in the associated zone or the corresponding policy. For example: Zone: EDMZ Policy EDMZ_2_IDMZ
For the node running firewalld, you don't want to block a lot of outgoing ICMPv6 because some are needed for IPv6 to function, e.g. neighbor discovery.
O.K. good to know!
But when it comes to incoming external traffic, you should differentiate a little. Or what do you say, specialist?
You certainly can if you want.
I'll think carefully about whether the effort is really worth the benefit, or whether I'm just wasting a lot of time here that I could put to better use elsewhere!
Best regards
Hello!
Am 27.09.24 um 4:55 PM schrieb Bastard Operator from Hell aka Django via firewalld-users:
... But everything else “behind” it, i.e. the FWB or even out to the internet, is starved across the board or blocked and not routed through by something or someone. But I currently have absolutely no other explanation than PEBCAK for my problem!
... I don't even think that the firewall is causing problems here, because the configuration of the same corresponds to that on the FWB (EDMZ-Firewall) My biggest guess is more in the direction of routing, but only where exactly have I made a mistake in my thinking and configuration. I just don't understand it.
Now I Know it and I understand my made configuration problem!
Did I mention PEBCAK? Well, you can call me Leipelt! m( As I suspected, it wasn't the firewall that was the problem, but a missing route!
firewall FWB:
III: ROUTING root@vml000210:~# ip -6 route 2003:a:bcd:ef00::/64 dev eth0 proto kernel metric 256 pref medium 2003:a:bcd:ef03::/64 dev eth1 proto kernel metric 256 pref medium fd00::/64 dev eth0 proto kernel metric 256 pref medium fd00:0:0:3::/64 dev eth1 proto kernel metric 256 pref medium fe80::/64 dev eth1 proto kernel metric 256 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium default via fe80::7ac5:7dff:fefd:1c10 dev eth0 proto static metric 1024 pref medium
The default gateway with the address fe80::7ac5:7dff:fefd:1c10 that is entered here is the LLA of the external FWA!
My Intranet has 2003:a:bcd:ef07::/64 as IPv6 network prefix. And here as you can see is no special routing entry for that network. So no IP packets could find their way back to the firmwall FWC and the laptop behind it!
After I manually added the missing route, I can also reach the Internet from my laptop via FWC → FWB → FWA → Internet: # ip route add 2003:a:bcd:ef07::/64 via 2003:a:bcd:ef03:10:0:0:110
Hurray hurray, I'm not too old and too stupid after all, okay, I might be a little stupid ... ;)
Best regards
firewalld-users@lists.fedorahosted.org