Port forward hitting default deny rule on syn/ack

[crustymonkey]

I feel like I'm an idiot or something.  I have some v4 port forwards setup that seem pretty straightforward here and the associated WAN firewall rules.



The issue that I'm having and is very apparent in the log live view is that packets are getting to the internal host and then when the initial response is returned (syn/ack for the tcp conns), it gets dropped despite the (default) LAN rules of allow anything, specifically hitting the "default deny/state violation" rule.



What am I missing / doing wrong here?

[Patrick M. Hausen]

What is the "Firewall rule association" in that NAT port forwarding set to?

[crustymonkey]

Sorry, that got cut off.  It's set to "Rule" as I had it auto-create the associated rule when I set this.  Everything else is just empty/default.

[Patrick M. Hausen]

And what does that rule look like?

[crustymonkey]

The WAN rule is pretty straightforward.



It's clear that this is working since I do see the packets transit in the WAN interface, out the LAN interface, and to the internal dest. server.  It's the responses from said internal server that are getting dropped by the "automatic" default deny rule.

It really seems like there's a problem here with the maintenance of state in the NAT flows.

[Patrick M. Hausen]

Never seen anything like this. Check that WAN firewall rule, "Advanced features", "State Type".

[crustymonkey]

Never seen anything like this.

That at least makes me feel better.  The "State Type" is set to "keep state", which should be correct.  It's been years, but I used to manage all this directly in pf on a regular old FreeBSD install and even from that perspective, this all looks correct to me.  I have no idea why the catchall allow to anywhere rule on the LAN side is apparently not being applied to the responses as it should be a match (plus it's a "quick" rule).  I'm basically at a loss for why this isn't working.

[Patrick M. Hausen]

The catch all "allow any" on LAN needs a SYN without ACK packet originating on LAN. The port forwarded traffic should be handled by that WAN rule which should also enter the state of the connection into the state table.

[crustymonkey]

Ah, true.  Good point.  The syn should trigger a state table entry.

[Patrick M. Hausen]

You can try

Code Select Expand

pfctl -s rules

to check what the system actually thinks it should be doing independent of the UI. Use the manpage of "pfctl" - you can also view the state table, NAT rules, etc.

[crustymonkey]

Well, not only was I feeling like an idiot, but it turns out that I was one...  My configuration was working just fine, but what wasn't working was the IPv4 path via my work VPN, which I was using to test the home config from an external source.  I did some curl/netcat tests from another external source and lo and behold, everything worked as intended.

Thanks for bearing with me in this Patrick and the reminder to just use good ol'

Code Select Expand

pfctl to dump the raw pf config.  That ended up being a helpful validator, at least for me, that what was configured was actually correct.

[Patrick M. Hausen]

Hooray! \o/