OPT1 can't block traffic to LAN without ruining some connections to WAN
-
Yeah. Not a fan of blocking traffic with pass rules. Experience says that the technical term for that is "bad" m'kay?
-
I like using the RFC1918 alias, but for my LAN networks used a block rule above the allow all rule with it. Perhaps that would satisfy both John's way and Derelict's?
At any rate 1 thing that does not seem to be affected by the block rule is ICMP/Ping. In my testing, I can still ping from one LAN to another despite the RFC1918 block of "all". Other ports are blocked, just not ICMP. I can get ICMP blocked using a floating rule -- just curious why it doesn't work in the LAN rules.
-
your going to have to show your rules.. And keep in mind pinging something and then putting in a rule and then pinging again - there is prob a state there so you would have to clear that..
-
The other LAN network looks the same except of course with a different source name and different IP's. I have found pinging the LAN address of the pfSense local gateway for each LAN network from the other LAN network always works with this config, even though it should be rejected with the RFC1918 rule which includes ping/ICMP. Pinging other devices is inconsistent -- sometimes works, sometimes not. For example I looked up an IP in the DHCP status, used the pfSense diagnostic ping to verify it responded to a ping, then pinged from the other LAN. It responded for a few pings and stopped. Tried another the same way and got no response. But again I can always ping the gateway address from LAN1 to LAN2 (or Guest to OtherLAN and vice versa).
I did another test and found if I change the destination of the RFC1918 to the specific LAN, simple ping no longer works between the LAN's. I found this was why the floating rule worked before. After that discovery I eliminated the floating rule. It appears pfSense does not like the RFC1918 rule but prefers a specific network. Here is my RFC Alias:
Last, if I use a port scanner -- in this case "Advanced Port Scanner"
https://www.advanced-port-scanner.com/
it finds every host on the opposite LAN network no matter what rules I set.
As it does not show in the rules, the "Guest" LAN network is a 172.x.x.x network/20, and the other LAN is a 10.x.x.x network/16. -
What is in you rfc1918 alias - I use such an alias myself.. Works just fine..
192.168/16
10/8
172.16/12are in my alias
-
I posted a pic of my RFC1918 Alias above -- matches yours I think!
A few more notes:
- I checked the states table was cleared and reran the tests; same result.
- However I found watching it while running a port scan the only state that appears to be open is port 53 DNS on the LAN from where I run the port scanner. It appears pfSense is giving up all the info from DNS. I am not sure what techniques the "Advanced Port Scanner" uses but it finds things some others don't. I have verified that my DNS Resolver settings for "Register DHCP leases in the DNS Resolver" is not checked. Any ideas of what else to check?
-
Keep in mind that by using a reject rule, the port scanner will get a response in the negative (a RST) for every attempted TCP connection to any port. Accessing anything in RFC1918 will not be what is commonly called "stealth." It should also receive an ICMP unreachable in response to any UDP packets.
This is the proper way to treat connections from the inside, in my opinion, but be sure you are not misreading that port scanner's results.
-
Also, post your floating rules, since you mentioned them.
Look at /tmp/rules.debug down in the user rules section and see if there is a pass rule that matches for the traffic you think is errant.
-
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
