Hello Team,
My understanding off a reject rule is, that it will send an icmp administrative Prohibit, or similar.
e.g. I do have a Rule that Denies all traffic leaving my WAN interface Destination RFC1918 IP range to REJECT.
If I ping from a host towards e.g. 10.100.1.1 I expect to receive an ICMP Reply with admin-prohibit, but I do not see a reply at all.
Having a look at the Firewall-Logs it only shows as a 'BLOCK'.
Is my understanding right? Did I miss a change?
TIA Feelx
DROP would be better I think...
But NULL Route seems to be the new trend :
- https://forum.opnsense.org/index.php?topic=52244.msg269362#msg269362
- https://forum.opnsense.org/index.php?topic=50678.msg259031#msg259031
I want the Notification!
dropping traffic is one thing, and it works. I like the >/dev/null route approach, which may facilitate your hardware better, but thats not what I want to achieve.
I do have an application which probes first for a Private IP, If that is not possible it falls back to Public IP. In Order to fail to Public IP Faster, an icmp unreachable or admin-prohibit would be required, and this is my understanding of the "REJECT" action.
By the Way, on the Interfaces I did deactivate "Block [privat|bogon]networks"; I also checked nat rules and hit logging on each ruleset.
But changing the rule from "REJECT" to "BLOCK", either incoming on lan or outgoing on WAN does not give me an icmp-reply.
Quote from: feelx on September 17, 2026, 03:53:40 PMMy understanding off a reject rule is, that it will send an icmp administrative Prohibit, or similar.
Here is the information in the OPNsense documentation - https://docs.opnsense.org/manual/firewall.html#action
May be you're thinking of IPF as I recall using it at the turn of the century for ping requests arriving from the Internet. I don't believe PF ever could and I can't say I ever missed it after transitioning. Even back then, the best approach was to simply block such connections. At least your REJECT rule will let TCP & UDP connections know they are not welcome. When a reject rule is logged, it is recorded as blocked.
As @nero355 has suggested, you would use Null Routes to sink traffic to RFC-1918 addresses not known by your firewall - see https://forum.opnsense.org/index.php?msg=259031
Quote from: feelx on September 17, 2026, 04:19:42 PMBut changing the rule from "REJECT" to "BLOCK", either incoming on lan or outgoing on WAN does not give me an icmp-reply
man page for pf.conf(5) - https://man.freebsd.org/cgi/man.cgi?query=pf.conf&apropos=0&sektion=0&manpath=FreeBSD+15.1-RELEASE+and+Ports.quarterly&format=html#PACKET_FILTERING
It appears to be a pf issue. I don't have a convenient way to test UDP (e.g. traceroute, where the application will report unreachables clearly), but TCP returns RST. I'm too lazy to run a capture. ICMP, as you noted, appears to return nothing. I do not know offhand if the "blackhole" sysctls affect this, as I have them... unholed; I don't see an ICMP sysctl offhand that would affect unreachables (other than net.inet.icmp.icmplim).
A search turned up a couple forum posts on the issue (other than this forum); I didn't try to dig into bug reports.
Edit: Ha! lmoore's post - I use bridges, so that appears to be my issue at least. Interesting.
Firewall logs will show block even when a reject is occurring. https://github.com/opnsense/core/issues/9737 (https://github.com/opnsense/core/issues/9737)
Quote from: pfry on September 17, 2026, 05:23:26 PMIt appears to be a pf issue. I don't have a convenient way to test UDP (e.g. traceroute, where the application will report unreachables clearly), but TCP returns RST. I'm too lazy to run a capture. ICMP, as you noted, appears to return nothing. I do not know offhand if the "blackhole" sysctls affect this, as I have them... unholed; I don't see an ICMP sysctl offhand that would affect unreachables (other than net.inet.icmp.icmplim).
A search turned up a couple forum posts on the issue (other than this forum); I didn't try to dig into bug reports.
Edit: Ha! lmoore's post - I use bridges, so that appears to be my issue at least. Interesting.
I stand corrected with my assertion about this not being in PF.
I found an old IPF ruleset which included;
block return-icmp(host-prohib) in quick proto icmp all icmp-type echo group 210
Applying this to pf on an OpenBSD boxen as;
block return-icmp(host-prohib) in quick inet proto icmp all icmp-type echoreq
We see the expected reply.
00:22:30.237183 10.200.128.22 > 10.200.128.20: icmp: echo request
00:22:30.237271 10.200.128.20 > 10.200.128.22: icmp: host 10.200.128.20 unreachable - admin prohibited
00:22:31.245814 10.200.128.22 > 10.200.128.20: icmp: echo request
00:22:31.245863 10.200.128.20 > 10.200.128.22: icmp: host 10.200.128.20 unreachable - admin prohibited
00:22:32.245857 10.200.128.22 > 10.200.128.20: icmp: echo request
00:22:32.245904 10.200.128.20 > 10.200.128.22: icmp: host 10.200.128.20 unreachable - admin prohibited
Changing the rule to;
block return in quick inet proto icmp all icmp-type echoreq
00:25:40.316392 10.200.128.22 > 10.200.128.20: icmp: echo request
00:25:40.316483 10.200.128.20 > 10.200.128.22: icmp: 10.200.128.20 protocol 1 port 15632 unreachable
00:25:41.325803 10.200.128.22 > 10.200.128.20: icmp: echo request
00:25:41.325888 10.200.128.20 > 10.200.128.22: icmp: 10.200.128.20 protocol 1 port 28145 unreachable
00:25:42.325833 10.200.128.22 > 10.200.128.20: icmp: echo request
00:25:42.325922 10.200.128.20 > 10.200.128.22: icmp: 10.200.128.20 protocol 1 port 10076 unreachable
In OPNsense the rule appears as;
block return in log quick inet proto icmp all icmp-type echoreq label "<id>"
tcpdump does not show any form of reply.
A little more digging around and testing is required.
I have a HDD with FreeBSD 15.1 installed on it. It will be interesting to see how it behaves.
[Edit] The same is observed with a generic installation of FreeBSD 15.1 - seems like an upstream issue.
Rule:
@1 block return-icmp(host-prohib) in log quick inet proto icmp all icmp-type echoreq
pflog:
2026-09-18 02:14:51.779906 rule 1/0(match): block in on em0: 10.200.128.22 > 10.200.128.2: ICMP echo request, id 18879, seq 0, length 64
2026-09-18 02:14:52.785960 rule 1/0(match): block in on em0: 10.200.128.22 > 10.200.128.2: ICMP echo request, id 18879, seq 1, length 64
2026-09-18 02:14:53.785920 rule 1/0(match): block in on em0: 10.200.128.22 > 10.200.128.2: ICMP echo request, id 18879, seq 2, length 64
tcpdump:
02:16:23.919342 IP 10.200.128.22 > 10.200.128.2: ICMP echo request, id 53324, seq 0, length 64
02:16:24.925840 IP 10.200.128.22 > 10.200.128.2: ICMP echo request, id 53324, seq 1, length 64
02:16:25.925842 IP 10.200.128.22 > 10.200.128.2: ICMP echo request, id 53324, seq 2, length 64
ok, thanks for digging into this so deeply.
so to summarise
* Upstream issue with PF for icmp-reply
* "BLOCK" instead of Reject is also a know upstream issue
Thanks for the explanation. I just need to live with this I Guess.
Quoting the man page here for further reference:
block
The packet is blocked. There are a number of ways in which a block
rule can behave when blocking a packet. The default behaviour is to
drop packets silently, however this can be overridden or made ex-
plicit either globally, by setting the block-policy option, or on a
per-rule basis with one of the following options:
drop The packet is silently dropped.
return-rst
This applies only to tcp(4) packets, and issues a TCP RST which
closes the connection.
return-icmp
return-icmp6
This causes ICMP messages to be returned for packets which
match the rule. By default this is an ICMP UNREACHABLE mes-
sage, however this can be overridden by specifying a message as
a code or number.
return
This causes a TCP RST to be returned for tcp(4) packets, an
SCTP ABORT for SCTP and an ICMP UNREACHABLE for UDP and other
packets.
Options returning ICMP packets currently have no effect if pf(4) op-
erates on a if_bridge(4), as the code to support this feature has not
yet been implemented.
Currently we only do "block return" in the sense that it is documented, with the caveat that if it's not working as documented it would be a FreeBSD issue.
One could try the other options if they work more reliably (e.g. return-icmp) here:
https://github.com/opnsense/core/blob/dc5fdc67f08ab2247bb1936014972def2f7a8a33/src/opnsense/mvc/app/library/OPNsense/Firewall/FilterRule.php#L85
Cheers,
Franco
So a "Reject" is translated to "Block Return@:
This causes a TCP RST to be returned for tcp(4) packets, an
SCTP ABORT for SCTP and an ICMP UNREACHABLE for UDP and other
packets.
Thanks for the info, But for me ( and I may have done it wrong), a tcpdump did not reveal any ICMP Unreachable ( in case of my icmp Ping) but as mentioned, that could be an upstream issue.
Thanks all