Bug or undocumented? Floating rule on out ditection not properly applying on final interface unless it is also applied to originating interface

phil80

I pushed further and added these rules to WAN

Why I can still connect to the modem ?
I thought that implicit allow rules can be blocked by explicit block rules on an interface
By implicit, I supposed the stateful reply traffic is part of it
In that case, I expected the reply traffic from modem would be blocked, but it is not

Now after reading, I see that replies are always allowed unless blocked by a floating rule or by disabling the state. So the rule on wan would only apply to new connections. Since any incoming new connection is blocked by default, what's the use of the automatic rule "Block private networks and loopback addresses" (I just manually added it after allowing ping requests from modem as my modem seems to require these pings even if set as static ip)

johnpoz

@phil80 that allow rule? you have it going to pfsense wan IP.. Not your modem IP.. All that allows you to do is go to your pfsense wan IP the 192.168.1.2..

Oh your modem pings pfsense IP?? Really why would it be doing that? But yeah that should work. I see hits on it.. Unless you have some rule in floating that blocks it? Floating is evaluated before interface rules. But if that was the case you wouldn't be seeing hits to it - ie that 523kb

when I get a chance I will fire up my 2.8 VM and try that.

phil80

@johnpoz
My question is not about puing rule.
It is the last block rule I added manually to replace the auto rule "Block private networks and loopback addresses"
If I enable the auto rule, ping requests will be blocked as the auto rule is at the top

My question is: in general, what's the use of the auto rules on WAN (or my manual rule), since:

they don't block stateful valid reply traffic
by default, all incoming requests are blocked

johnpoz

@phil80 great question.. Yeah I personally don't think either of those default rules make a lot of sense any more.. For starters there are very few bogon actually left.. And your isp shouldn't be routing them if they are bogon. So for them to get to your connection they would have to be coming from your ISP network. Or spoofed - what would be the point of spoofing bogon or rfc1918?

Same goes for rfc1918.. It is bogon in that it wouldn't route across the public internet.. So its either your local wan network, or something in your isp network.

And yeah your right without any allow rules they would all be blocked anyway.. So those rules only block stuff you would be wanting to allow in the first place.. Would it matter if a few stray packets from your isp network hit your open ports?

I leave them to just see out of curiosity how much traffic hits them ;)

So you can see my rule counters have been up for a while - my plex rule has passed almost 4TB.. And I have seen a total of 480B on bogon ;) and a whopping 70KB on my rfc1918 rule ..

And since I limit source IPs to my open ports, and not any.. Bogon and Rfc1918 would have be in my allow list.. Which they are not - so even if bogon or rfc1918 source hit my wan towards one of my open ports they wouldn't be allowed anyway.

If I saw the counters on those 2 rules going up - I would be curious to what it is, and start a packet capture, or set them to log.. I currently have logging of them off.

I log what I want to log via log settings on my rules.. I have some rules at end of my wan to log traffic I am interested in. SYN and common UDP ports.. But the default log of default deny doesn't interest me.. I mean it was blocked and is going to be noise.. I would only enable that logging if was troubleshooting something for example

phil80

@johnpoz
Thank you for validating my thoughts and setup
By the way, the best thing I did was moving intervlan routing to pfsense and keep fast 10 Gb servers on same VLAN on the switch. So simpler to maintain and stopped using the asymmetric insecure routing for internet