OpenWrt “ships” with some default firewall rules that should handle basic (RFC compliant) functions. Among those is the “Allow-ICMP6-Input” rule.
Surprisingly, this is limited to ICMP6. Shouldn’t there be the same rule for ICMP(4) (without the ICMP6 specific sub-types, of course)? Unless it is buried in the source code, it’s really not there. A `nft list ruleset | grep -i icmp` shows only
Not really (or fully). As it’s name suggests, “Allow-Ping” allows “echo-request” only. It does not allow “destination-unreachable” and “time-exceeded”.
To make that I didn’t accidentally modify it, I’ve checked. “/rom/etc/config/firewall” specifies:
# Allow IPv4 ping
config rule
option name Allow-Ping
option src wan
option proto icmp
option icmp_type echo-request
option family ipv4
option target ACCEPT
With the default firewall rules active, from a wireless LAN client:-
ping -t 2 www.google.com
PING www.google.com (142.251.30.103) 56(84) bytes of data.
From 2.127.238.243 icmp_seq=1 Time to live exceeded
From 2.127.238.243 icmp_seq=2 Time to live exceeded
From 2.127.238.243 icmp_seq=3 Time to live exceeded
From 2.127.238.243 icmp_seq=4 Time to live exceeded
The absence of the specifics in that rule doesn’t stop the ICMP messages that you think are missing.
Yes, it works. I only wanted to understand why it works, as there is no visible rule for it, neither in the configuration nor in what I get from querying with “nft list”. Which only leaves the conclusion that it must be hard coded (“buried”) in the source code after all.
Getting beyond my understanding of the firewall, but the “conntrack“ module, which usually appears in the nftables input chain as “ct state established,related accept“, means that any outbound connection that causes ICMP packets (of many types) to be received will be accepted as related to that request.
If your wan interface is offline these Icmp states are inherent.
If you have global reachable networks behind wan then yeys you need rules to cover that.
But the default OpenWrt config which assumes a natted wan does not need these.
@_bernd: While I was happy with @brada4 ‘s answer (Thanks!) your comment irritates me. With a natted wan all these ICMP packets go to the router. But that’s exactly why the router should receive them, isn’t it? The existing “Allow Ping” rule is about incoming traffic (ICMP echo_request to the router). So ignoring its name, it would have been a good candidate for allowing “destination-unreachable” and “time-exceeded”.
But as @brada4 has pointed out, allowing the ICMP packets is handled by conntrack as ICMP with “destination-unreachable” and “time-exceeded” are related to an existing connection (or not of interest).
So, yes, I need to cover that, and yes, it is covered, however by conntrack instead of by an explicit (nftables) rule.
You can log the packets like (add file in /etc/nftables.d/ghostcatcher.nft)
chain qwerty {
type filter hook prerouting priority -200;
ct state related log
# meta l4proto ne tcp ct protocol tcp log
# meta l4proto ne udp ct protocol udp log
}
ICMP packet includes original tcp/udp header and is matched to state and translated back to the host with connection.....
If it does not match it is dealt with default forward policy, ie reject if not an error (oomph, that is not reachable via ruleset)
Those permitted are matched to existing state, NAT or not. So you do not need to specify each type, just rely on kernel to "know it all"
There is a discrepancy that flat icmp6 topology can be pinged but ip4 not by default rules. But serves all practical ends.