firewall: port forward associated rule help/documentation

[lfitt]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [X] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [X] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

I was playing with crowdsec, and noticed that things that were alerted as being "bounced" were still hitting internal services, causing them to still alert, even when there was a firewall rule in place. I have verified the traffic is still getting to the internal service by looking at the logs on the internal service, and by logging "rdr" rules in the firewall.

I've taken the troubleshooting as far as I can, but I think the issue can best be described as in the title: an incoming IPv4 NAT packet bypass the BLOCK rules that should apply first

Tip: to validate your setup was working with the previous version, use opnsense-revert (https://docs.opnsense.org/manual/opnsense_tools.html#opnsense-revert)

To Reproduce

Steps to reproduce the behavior:

0. port forward IPv4 ports from WAN to some internal host
1. create an alias of either IPs or subnets. (does not need to be crowdsec)
2. create an IN rule to block traffic from that alias on the WAN nic
3. traffic still flows to internal services

Expected behavior

traffic should be BLOCKed instead of NATed

Describe alternatives you considered

Initially I thought it was crowdsec bug. I made a new inbound rule (with logging) on WAN interface duplicating the function of the built-in crowdsec rule. This did not change the outcome. I tried a Floating "in" rule with all interfaces, pointing to the crowdsec_blacklists alias. No change. I duplicated the crowdsec alias table and converted it into /24 subnets, no change. I tried an "out" rule on the internal interface with source being the crowdsec alias, this does work. Some traffic does get caught by the rules on the "in" side of interfaces, but that is all traffic that would have hit the default deny rule anyway (no port open, no NAT in place)

I have verified the IP addresses I want blocked are indeed in the alias tables with "pfctl -t tableName -T show"

In addition to the crowdsec rules, I also have a GeoIP rule called "ActiveWarZones" which contains countries that are currently active warzones. While preparing the information for this bug report, I noticed it only seemed to be triggering for IPv6 addresses, and not for IPv4 addresses. I made matching "out" rules on my internal interfaces, and can confirm that traffic that has been touched by a NAT rule does not seem to apply BLOCK rules.

Screenshots

notes: "Internode" is my WAN interface "LAB" is a VLAN on an internal interface. "LAN" is that same internal interface, with no VLAN.

Firewall log showing the NAT rule forwarding traffic, and the "out" rule actually stopping the traffic:

Firewall log showing inconsistent behavior of inbound drop, as well as an RDR taking place and being dropped on the "out" side of the internal interface:

More notes about this screenshot: "CrowdSec (IPv4)" is the default crowdsec rule, with the crowdsec alias. (on WAN in) "DROP: Crowdsec Blacklist IPv4" is a rule made from the duplicated crowdsec alias with /24 subnets (on WAN in) "BLOCK: Crowdsec to LAB" is the rule on the out side of the internal interface, this is using the default crowdsec alias. (on LAB out)

Firewall log screenshot showing "ActiveWarZones" traffic being blocked on the outbound side of the internal interfaces for NAT'd traffic. this particular traffic is being NAT'd via upnp to a bittorrent client to generate some traffic, so how the NAT rule comes to exists does not seem to make any difference either.

Firewall log

These logs do not match any of the screenshots, but demonstrate a RDR being done, and then a BLOCK OUT on an internal NIC.

1,,,0,pppoe0,match,rdr,in,4,0x0,,37,30697,0,none,17,udp,86,77.138.73.25,59.167.177.52,1024,61597,66 165,,,e3aa523215a8e08179a93493f4e133bd,igb1,match,block,out,4,0x0,,36,3699,0,none,17,udp,86,77.138.73.25,10.1.1.12,1024,61597,66 1,,,0,pppoe0,match,rdr,in,4,0x0,,37,2282,0,none,17,udp,86,77.138.73.25,59.167.177.52,1024,61597,66 165,,,e3aa523215a8e08179a93493f4e133bd,igb1,match,block,out,4,0x0,,36,63881,0,none,17,udp,86,77.138.73.25,10.1.1.12,1024,61597,66 165,,,e3aa523215a8e08179a93493f4e133bd,igb1,match,block,out,4,0x0,,36,33945,0,none,17,udp,86,77.138.73.25,10.1.1.12,1024,61597,66 1,,,0,pppoe0,match,rdr,in,4,0x0,,37,49256,0,none,17,udp,86,77.138.73.25,59.167.177.52,1024,61597,66

If applicable, information from log files supporting your claim.

Additional context

Add any other context about the problem here.

I have updated all software as of last 17/05/2023 I have rebooted.

Software version used and hardware type if relevant, e.g.:

OPNsense 23.1.7_3-amd64 FreeBSD 13.1-RELEASE-p7 OpenSSL 1.1.1t 7 Feb 2023

Hardware: PCEngines apu4d4 AMD GX-412TC SOC (4 cores, 4 threads) 4x Intel i211AT

[fichtner]

Not sure what I'm looking at. NAT rules are evaluated before block rules, but block rules still apply when matching to the post-NAT packet address etc. situation. You have neither shown the NAT port forward nor the (associated?) block rule that is supposed to apply (and the inspect counter to see if it actually not matches any traffic).

[lfitt]

Yep, sorry!

running a mail server inside my network and port-forwarding port 25 to the mail server.

Inbound NAT (Port forwarding) rules:

"Service ports smtp" is an alias with just "port 25" in it, the destination alias is just one IP.

Packet counters:

actual block rule:

I think it's falling over at "block rules still apply when matching to the post-NAT packet address etc" so the inbound NAT is triggering correctly, but the BLOCK rule is never being applied.

[lfitt]

oops, wrong screenshot on the third there.

[lfitt]

full body of the NAT rule too:

[fichtner]

Er, you set "filter rule association" pass which passes traffic without going to rules section ;)

[lfitt]

eyyy! good news! i'm an idiot! hahaha - verifying it does what I expect now.

Feature request: adding a "help" text explicitly stating that is what happens (please!)

[lfitt]

aaannd rules are working as expected, sorry about that!

[fichtner]

No problem, happy to help. The docs are not great either https://docs.opnsense.org/manual/nat.html#port-forwarding -- let me see what I can do.

[lfitt]

Following up, I have a second opnsense machine I decided to check my rules on, and the second one had "Add associated filter rule" set (the default) which creates an allow rule on the WAN interface. (the machine in the start of the ticket was set to pass, there were no extra rules being created)

The extra rule created is basically "allow * to destination" which is (in my mind, at least) the same as just setting "PASS"

Do these extra rules follow the rules above? (ie; if they're a NAT pass, ignore any block that might exist)

[fichtner]

The associated rule does the same thing, but you are able to follow strict rule ordering on the incoming interface this way. If the pass is before a a block the block won't do, but that's basic rule evaluation and reordering helps to get the desired result.

Cheers, Franco

[Monviech]

In this commit I have explained the associated filter rule bit: https://github.com/opnsense/docs/commit/3cc00bfdf51913610fa1343fc7ca1b6e6b562c22

Maybe that closes this issue too? If not, I can add the explanation into the normal NAT document too.

[melroy89]

Any update?