OPT1 can't block traffic to LAN without ruining some connections to WAN
-
I've sent my debug rules to Derelict. But as for "a rule is a rule" . . . well, if software including routing software didn't have bugs, quirks, "features", sketchy something or whatever, we would not have regular patches. That would be a great utopia -- software without bugs! Now back to the real world, I hope we find a config error and that is all this is. In the meantime this morning I have rebooted the pfSense router and tested again with the same results. I have far better things to do with my time than make up stories to cause issues in forums!
Anyway, thanks John for the suggestion to use RFC1918 -- whether it has issues or not it is a great idea.
-
Just a note about the "Advanced Port Scanner" being able to find hosts on a different LAN despite firewall rules. I did a packet capture and found this is all ARP (not DNS), and probably a separate issue from the "ping" issues above. So basically even though there are 2 separate physical network ports with 2 different LAN's, they are returning info from the ARP cache on each other, allowing pretty much full network discovery from 1 LAN to another LAN despite block rules. There seems to be some BSD issues with this as I found something similar here:
https://forums.freebsd.org/threads/arp-table-entries-on-wrong-duplicate-interface.58922/
In that case it was a bridge config issue. While I don't have any interfaces bridged (unless sharing a gateway is somehow bridging), maybe something else triggers the same conditions. I'll maybe open a support ticket on that one. -
@supertechie said in OPT1 can't block traffic to LAN without ruining some connections to WAN:
So basically even though there are 2 separate physical network ports with 2 different LAN's,
If your arping other devices then they are not "separate" but on the same layer 2. It is not possible to arp for something that is not on the same layer 2.
Even a host host firewall doesn't block arps - so while a firewall rule might prevent something from seeing a ping. Its normally not going to stop an answer to an arp. But the only way to see an arp would be if the devices are on the same layer 2.
Sounds like you might be trying to run multiple layer 3 on the same layer 2 - which is just borked out of the gate.
-
Netgate support found my issue with the ping and RFC1918. Had one of the private networks configured as 172.32.x.x which is just outside the private address range of 172.16.0.0/12. I think when I set it up I used an IP calculator somewhere and got the wrong range. Really stupid, I know. Thanks all.
-
hhehe - thanks for the follow up.. Yeah 172.32 is owned by
Organization: T-Mobile USA, Inc. (TMOBI) -
After fixing the private IP range the ARP scan issues went away too! All good now, no leaking
