How to block WAN ping?

I'd like to disable ping on WAN. How to do this? I tried to disable the default accept rule

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'
        option enabled '0'

and changing to drop

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option family 'ipv4'
        list icmp_type 'echo-request'
        option target 'DROP'

But I can still ping the router from the Internet.
OpenWrt 22.03

Restart the firewall service to apply the changes and be sure to run tests from outside.
If the issue persists, you are likely behind CGNAT and the ping responses are coming from your ISP router.

3 Likes

I restarted the router and pinged from the LTE mobile network. I have a public IPv4 address from my ISP (PPPoE). When I power off the router, ping timeouts.

Let’s see your compete firewall file.

Sure

config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        list network 'wan'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option family 'ipv4'
        list icmp_type 'echo-request'
        option target 'DROP'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

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'

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'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        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'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config include 'miniupnpd'
        option type 'script'
        option path '/usr/share/miniupnpd/firewall.include'

config redirect
        option name 'cam'
        option src 'wan'
        option dest 'lan'
        option src_dport '50000'
        option dest_ip '192.168.1.20'
        list proto 'tcp'
        option target 'DNAT'

Do you have upnp enabled? That could be part of the reason that your wan is responding ot pings.

1 Like

I did. But I've just disabled upnp and WAN is still pingable.

root@OpenWrt:~# cat /etc/config/upnpd 

config upnpd 'config'
        option enabled '0'
        option download '1024'
        option upload '512'
        option internal_iface 'lan'
        option port '5000'
        option upnp_lease_file '/var/run/miniupnpd.leases'
        option igdv1 '1'
        option uuid '86b93048-2959-44c0-ba76-2b254bf474d0'

config perm_rule
        option action 'allow'
        option ext_ports '1024-65535'
        option int_addr '0.0.0.0/0'
        option int_ports '1024-65535'
        option comment 'Allow high ports'

config perm_rule
        option action 'deny'
        option ext_ports '0-65535'
        option int_addr '0.0.0.0/0'
        option int_ports '0-65535'
        option comment 'Default deny'
root@OpenWrt:~# reboot

Still pingable.

btw the output

root@OpenWrt:~# service firewall restart
Automatically including '/usr/share/nftables.d/table-post/20-miniupnpd.nft'
Automatically including '/usr/share/nftables.d/chain-post/dstnat/20-miniupnpd.nft'
Automatically including '/usr/share/nftables.d/chain-post/forward/20-miniupnpd.nft'
Automatically including '/usr/share/nftables.d/chain-post/srcnat/20-miniupnpd.nft'

I suspect that there is something that we're not seeing (i.e. some other service or config file that we haven't asked for, or as @vgaetera said, maybe miniupnpd in general) which is responsible for the issue you're describing. I'm not sure what it is, though.

It may be worth making a backup of your current config and then resetting your device to defaults. From there, make only the minimum necessary changes such that your configuration is usable, and then try disabling the wan ping rule and test again.

Removed miniupnpd, WAN still pingable.

At this point, I'm just curious why it's still responding to ping.

There is nothing that we can see that would explain this behavior... but there may be things we can't see (and wouldn't know to ask about).

I'll point back here:

1 Like

But what is ultimately controlling this behaviour? nftables? Maybe there is a problem?

How are you testing the ping response?

2 Likes

So the firewall rule that you initially described would the one standard and expected rule that would control ping responses. However, any number of packages or custom firewall/nftables type rules could potentially introduce additional variables and make it hard to find why this isn't working.

Therefore, if you want to identify the culrpirt (and determine if there is a problem), we need to go back to first principles. By resetting your device to defaults, it will clear all user-configured/user-added items and should get us back to a known/default state for OpenWrt. Then you can test... if the problem still manifests, it should be easy enough for others to replicate and then we can conclude that it is a problem/bug. However, if (as I suspect will be the case), the problem resolves, you can then try restoring your configuration and/or user-installed packages and see if it re-appears. If tested methodically, you can identify what is causing the ping response and from there we can begin to disect if it is expected behavior (based on some rules or requirements of a package or config item) or if there is a bug somewhere else.

1 Like

Using Termux on my phone, I ping my WAN address over the LTE mobile network.

root@OpenWrt:~# ip addr show pppoe-wan
19: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc cake state UNKNOWN qlen 3
    link/ppp 
    inet HEREMYIPv4 peer HEREGATEWAY scope global pppoe-wan
       valid_lft forever preferred_lft forever

If I had a spare router to play I would test that, but I don't have one at the moment.

And you're sure it's definitely not still connected to wifi when doing the test?

What are the first two octets of your WAN IP address?

3 Likes

I'm sure, wifi disabled, RTT ~100ms.

77.253.x.x

I have just run a test and I can confirm that the Allow-Ping rule that exists in the OpenWrt default firewall does indeed function properly.

However, some detail in my obsevaations:

  • If a continuous ping had been started prior to the deactivation of the rule (followed by a save & apply or firewall restart operation), the pings would continue to be returned succesfully, uninterrupted.
  • If the pings were stopped before the fireall rule was deactivated, the pings responses would fail (thus indicating that the rule does indeed work as expected).

Therefore, @maksz - I would recommend that you stop any continuous pings, disable the rule, save and apply, then test again.

2 Likes

Can you try a different app (e.g. Network Analyzer App (techet.net))?

I saw the same when using Termux. Network Analyzer on the other hand immediately showed ping responses failing as soon as the rule was disabled.

1 Like

I was using the standard terminal in Mac OS. I suspect that the firewall is treating this as an established/related connection and keeping it in the tables (conjecture). Flushing the firewall could possibly stop the ping responses in that situation, but I didn't go that far.