OPT1 can't block traffic to LAN without ruining some connections to WAN
-
@derelict said in OPT1 can't block traffic to LAN without ruining some connections to WAN:
A firewall rule on OPT1 will never see traffic sourced from LAN because LAN addresses will not be connecting into OPT1.
You generally do not "forward" ports from a server to WAN. You forward connections into WAN to a server on the inside. You might pass only specific ports from a server but that's not "forwarding ports."
I think you need to read and understand these:
https://www.netgate.com/docs/pfsense/firewall/firewall-rule-basics.html
https://www.netgate.com/docs/pfsense/firewall/firewall-rule-troubleshooting.html
That was poor wording on my part, that's what I did for my forwarding. My issue isn't port forwarding though, that's fine. What's ultimately happening is if I do a simple allow all from the OPT1 network to WAN, I can't do any sort of communication to WAN unless I also say my OPT network has communication to the LAN. In addition to that, my explicit denies fail even though it's before my allow * from OPT1 to LAN
-
That makes no sense. Post screen shots of your rules, let us know what specific subnets are on each inside interface, and say whaen hose "IP ADDRESS" tries to connect to host/service X, this happens.
-
I JUST got it to work with these configs. Which is very strange, because I know I tried these at one point. LAN is very boring, just some pfBlockerNG rules and the default alloyw from LAN to any.
Another thing that I tried but didn't work is instead of having an allow OPT1 to any, I tried an allow OPT1 to !LAN. My assumption was it would do a pass to any but !LAN. However, I was still allowed to LAN. So that must be an incorrect assumption
-
Allow ! lan works just fine - as long as you don't have some odd configuration with VIPs etc.. I use a ! rfc1918 (alias) at end of my rules vs the any..
Derelict is not a fan of doing it that way.. And I admit it can have some issues depending on your config.. But it a valid more explicit allow.
Keep in mind when your messing with rules - you have to validate that any existing states are removed when you start wanting to prevent something from going somewhere.. If you change your rules and something should not be able to talk to something else now - make sure you check for any states that might be still open.
Your 4 rules allowing to http/https could be done in 1 rule with aliases.
-
Thank you for all the information, I'll take a look at aliases. It's been quite a while since I've done very specific firewall rules so I'm spending a lot of time trying to remember what I knew at one point in time!
-
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.
