Trying to make some sense of the ipv6 icmp firewall settings and appreciate feedback whether my assumptions are correct or missing something:
MLD - management of downstream broadcast listeners/subscribers
config rule
option name Allow-MLD
option src wan
option proto icmp
option src_ip fe80::/10
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family ipv6
option target ACCEPT
Hence, if there are no listeners/subscribers client nodes downstream (that wish to receive multicast packets from upstream (W)WAN) the rule can be disabled for (W)WAN without any caveats/disturbance on the general ipv6 connectivity?
essential incoming IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Input
option src wan
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
list icmp_type router-solicitation
list icmp_type neighbour-solicitation
list icmp_type router-advertisement
list icmp_type neighbour-advertisement
option limit 1000/sec
option family ipv6
option target ACCEPT
All the below listed are supposedly a response from a remote node to a connection attempt initiated the local router and thus seems non-essential in the fw (W)WAN context as already covered by conntrack (established) - as opposed to unsolicited ingress?
config rule
option name 'New_Allow-ICMPv6-Forward'
option src '*'
option dest '*'
option proto 'icmp'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
They seem to match your list. While I still have the MLD rule in place, I agree that it shouldn't be needed on a non-multicast tunnel.
I have read the RFC and what I asked does not seem to be detrimental because those packets types are traversing the fw uninhibited when the connection is solicited/initiated by the router due to conntrack (established).
But what is the purpose to allowing such packets when being unsolicited from a remote/foreign WAN source, unless running some server side service on the router that is exposed to WAN, which most CPE/SOHO routers are likely not, contrary to servers that provide content/service on public domains?
I might not remember properly but as far as I recall, an ICMP error reply to a connection established from within does not necessarily count as conntrack related.
Another consideration when adding the default rules was that conntrack might be disabled (e.g. through NOTRACK), which might happen when neither of the involved zones uses NAT.
Certain versions of firewall3 added automatic NOTRACK rules for traffic between zones when neither the source, nor the destination zone had either option masq 1 or option conntrack 1 set.
I suppose its very easy to reach that limit with some bittorrent traffic, but I have no strong opinion on the limit.
With that background the aforementioned rules make sense. Though I do not understand the benefit of conntrack being disabled by default on the WAN, weak hardware where conntrack is too costly on the CPU?
On all Linux nodes I operate conntrack is utilized by default, makes for less fw rules to be implemented (and thus to be processed by kernel-nf/CPU).
I will disable the aforementioned rules on this router node, enable conntrack and see how it goes, i.e. whether it causes any drawback in ipv6 connectivity/throughput/latency.
option masq 1 applies only to ipv4 and not ipv6?
I am not familiar with the intricacy of that protocol and to which extent/volume it utilizes icmp6 and whether 1000/s is needed indeed. It just seems an awful lot considering unsolicited traffic being accepted (packet flood/storm).
With a VDSL | PPPoE | dhcp6 | ds-lite ipv4 upstream connection and having set
config zone
option name 'wan'
option input 'DROP'
option output 'ACCEPT'
option forward 'DROP'
option masq '1'
option network 'wan'
option log '1'
option log_limit '5/second'
option mtu_fix '1'
option conntrack '1'
config rule
option name 'wan icmp ipv6'
option family 'ipv6'
option proto 'icmp'
option src 'wan'
list icmp_type 'echo-request'
list icmp_type 'router-advertisement'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-advertisement'
list icmp_type 'neighbour-solicitation'
option limit '50/sec'
option limit_burst '10'
option target 'ACCEPT'
config rule
option name 'wan icmp ipv6 forward'
option enabled '0'
there does not appear to be any inclement impact. Ran bandwidth/throughput tests from the router cli as well as from a client's browsers (green across all boards, no latency/throughput issue) on
Have been mulling over the IPCMPv6 forwarding rules that ship with vanilla FW3 and those do not seem to make sense, notwithstanding wondering whether the downstream clients are at all subjected to the IPv6 firewall part, considering/reasoning:
once a downstream client has established an IPv6 GUA (through odhcpd) it got its own publicly route-able IPV6 address which is different from the router's GUA (least by the suffix (IID)), contrary to IPv4 where commonly only the router gets a single GUA (/32) and clients only an ULA
with an IPv6 GUA for the downstream client in place it does not require the router to translate ULA <> GUA (NAT) but the client communicates directly with WAN via its GUA
FW3 protects the router's WAN interface but not the entire GUA address space, or does it?
by default inbound packets from the WAN do not forward... the LAN device must initiate a connection outbound to allow the return packets to forward via conntrack.
also multicast is an integral part of ipv6, MLD is needed for neighbor Discovery and router adverts and etc.
I personally think a hashlimit would be appropriate but filtering is not a good idea. hashlimit of 10/s per ip burst 100 for example
Forwarding ICMPv6 packets from WAN does not appear necessary with the CPE's downstream client (LAN) having an IPv6 GUA and thus being in WAN IPv6 address space (contrary to ULA IPv4 behind NAT) - the downstream client's interface with the IPv6 GUA being subjected to the ISP's firewall ingress rules and the client's own firewall ingress rules but not the CPE's.
MLD would not appear to be required at all for ND | RA but provides its own purpose [1]
Any traffic not terminating on the router itself is forwarded traffic from iptables pov. Traffic towards IP addresses not assigned to any of the routers local interfaces is covered by FORWARD rules, not INPUT (ingress) ones.
Sure, that makes sense for IPv4 where the LAN client is commonly only having a ULA behind a NAT of single GUA that covers the CPE and all its clients and thus the CPE's firewall takes an active role in the packet routing decision (translate/forward from GUA to ULA).
But for IPv6, save for NAT6 | NAT64, the CPE's client has it is own GUA, different from any other client and the CPE itself and routing is already provided by routers' routing tables and the IPv6 prefix in the IPv6 header. Forwarding ICMPv6 via firewall thus seems not only superfluous but may unnecessarily consume CPU cycles and confuse networking.
It is simple to test - disable the forwarding rule and enable packet logging on the WAN for ICMPv6 and check whether any such packets for downstream client being actually dropped/rejected.
Sorry, I am not following. Inbound forwarded ICMPv6 is rejected by default unless it is classified as related, so made in response to a connection initiated from within, therefore it is needed to establish explicit rules allowing inbound ICMPv6. These rules are in accordance with RFC 4890, section 4.3 "Recommendations for ICMPv6 Transit Traffic"
Indeed. Ping from a remote IPv6 enabled host to my local desktop with the default rules in place:
jow@srv:~$ ping6 2001:470:527e:0:5a04:824c:5588:16d4
PING 2001:470:527e:0:5a04:824c:5588:16d4(2001:470:527e:0:5a04:824c:5588:16d4) 56 data bytes
64 bytes from 2001:470:527e:0:5a04:824c:5588:16d4: icmp_seq=1 ttl=57 time=85.3 ms
64 bytes from 2001:470:527e:0:5a04:824c:5588:16d4: icmp_seq=2 ttl=57 time=79.0 ms
^C
--- 2001:470:527e:0:5a04:824c:5588:16d4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 79.097/82.225/85.353/3.128 ms
After deleting the IPv6 ICMP forward accept rules:
You absolutely can NOT drop ICMPv6 at the router. For example, there is no router fragmentation in IPv6, if a packet is too big to go through one of the many hops along its journey, the router at that hop sends an ICMP message to the origin saying "the max MTU is x" and the client device behind your router NEEDS to get that packet or it will not be able to talk ipv6. I've seen this cause all sorts of problems.. People with strong ipv4 security backgrounds always want to drop ICMP6 but you really should allow all ICMP6 traffic, and at best rate limit it.
That is not what I am implied in general, it is about the forwarding rules.
That I find curious, considering
(1) packet ingress directed at client's GUA in WAN space
|_ (2) packet hits ISP ingress interface
|_ (3) ISP's GUA routing table routes the packet to CPE
|_ (4) packet egress from ISP
|_ (5) packet hits CPE ingress interface
|_ (6) CPE's GUA routing table routes the packet to next downstream interface (bridge or lan)
|_ (7) ingress/egress of CPE's downstream interface
|_ (8) packet hits downstream client's ingress interface
Is the firewall actually aware of the CPE's IPv6 GUA and concludes that any packet with a different destination IPv6 as forward? If that is the case it all makes sense and I might have missed that bit (IPv6 address space awareness) when looking into FW3 source code.
I assume you mean CPE is the OpenWrt router. In that case, the router absolutely knows that a packet that hits its WAN interface destined to a GUA on its LAN is supposed to be forwarded... that's what it does, it's a router.