Messages

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.

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

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.

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.

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.

[are]

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?