OPT1 can't block traffic to LAN without ruining some connections to WAN
-
Thanks for the tip. I changed the reject rule to block and retested. The results were the same for the "Advanced Port Scanner" anyway. I did not post the floating rules as I removed the floating rule after finding that the difference in some of my testing at least for pinging the LAN local gateway was in using the exact networks in the rules instead of the RFC1918. I think at this point I can conclude:
- pfSense's firewall is doing what it is supposed to do -- it is blocking/rejecting traffic.
- The firewall blocking/rejecting for ping is a little sketchy at least for the LAN local gateway unless the network in the block/reject exactly matches -- i.e. local LAN#xxx blocked works a little better than RFC1918. I have seen similar issues with other brands of firewalls I have used in the past.
- pfSense DNS when queried appears to give up info on all LAN's -- that appears to be how the "Advanced Network Scanner" is getting it's info. Still looking into this and am open to suggestions! I am considering using separate DNS servers for my more sensitive networks.
-
@supertechie said in OPT1 can't block traffic to LAN without ruining some connections to WAN:
The firewall blocking/rejecting for ping is a little sketchy at least for the LAN local gateway unless the network in the block/reject exactly matches – i.e. local LAN#xxx blocked works a little better than RFC1918.
Well yeah a rule has to match - but would not use the term sketchy ;) That seems to state that it works or doesn't work because the moon is full or something.
Firewalls and computers just do what they are told, if a rule matches then it triggers.. There is nothing sketchy about it, what for sure might be sketchy is the users understanding of how the rules are evaluated or the order, etc.
-
Well I don't care what you call it! But in a controlled environment I can reproduce these results, except #3 below:
- Using RFC1918 as a block rule, I can always still ping the blocked private LAN's local gateway from another LAN/OPT.
- Using the same block rule but the named network instead of RFC1918, I can always not ping the blocked LAN's gateway.
- I observed a few anomalies using the above 2 tests pinging different hosts other than the gateway. Sometimes I could ping another host, sometimes not using the RFC1918 block rule. This I may not be able to reproduce but I did observe at least once.
- Using either block method, the firewall seems to do its job for all other traffic/ports other than ICMP, at least in my limited testing. But the results of #1 & #2 make me want to be a bit cautious using RFC1918 for blocking traffic between 2 LAN's.
In theory there should be no difference, but the results are what they are. If you see a config error in what I have posted please let me know!
-
You are doing something wrong because that is not possible with the rule you have in place OR there are existing states open from before the rules were active.
You are going to have to post more information such as specific source and destination addresses, the firewall rules for both of those interfaces, etc.
Feel free to DM me your /tmp/rules.debug file instead but I will still need the specific source and destination addresses.
-
Sorry but nonsense.
If 1 was true then the firewall is POS... Rule is a Rule is a Rule - be it tcp/udp/other/icmp..
If I have a rule that says you can not ping, then your not going to be able to ping.. Unless there is a state already. Or you have a rule that is superseding the rule you think you put into play.
There is no such thing as "sketchy" in computer business.. The one thing I love about computers is its so black and white. Its binary - it is a yes or a no.. You don't get "sketchy" or maybes in IT..
-
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
