This Firewall (self) not working
-
My physical LAN interface address is 192.168.10.200. My VLAN interface address is 192.168.113.200. In my VLAN firewall rules I have this:
I disable the 2nd rule and I attempt to ping 192.168.10.200 from 192.168.113.4. The first rule (destination This Firewall (self)) does not block the ping (as I would expect it to). It always passes. The ping succeeds.
When I enable the second rule (specific destination 192.168.10.200), it blocks the ping.
So, (since 192.168.10.200 is a firewall interface) as far as I can tell, "This Firewall (self))" is not working.
Not that I think it matters, but the only other twist here is that the source (as pfSense see it) is a wifi router (192.168.113.4) that does its own NATing. It establishes its own LAN interface at 192.168.213.200 and doles out IP addresses in the 213 subnet to wifi users. And for what it's worth, the actual source of the ping was the Net Analyzer iPhone app:
Any help would be much appreciated.
Thank you. -
Is the pfSense box up against the internet with a public IP address?
What is your LAN subnet(s)
But if I read right.. "This Firewall" should only block 192.168.113.200. Of coarse you would still be able to "route" to another address that exists on the LAN network.
If your LAN network is 192.168.10.0/24 then you should have that whole subnet blocked if you are trying to protect your LAN from your VLAN as it appears you are trying to do.
What is your public IP address? (don't print it here) Try hitting that from your VLAN. You might need to block that also.
-
@fullauto Hm, pretty sure we have allow This Firewall rules working in places. You can check the rules, though: https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html, e.g. "pfctl -sr"
-
@chpalmer said in This Firewall (self) not working:
So, I wrote a bunch of stuff that seemed relevant at the time, but now seems like a waste to delete - but you can skip to the "--- I found something ---" section at the bottom for the latest revelation (or just read from top to bottom to share in my early frustration.
Is the pfSense box up against the internet with a public IP address?
Yes. It's a working box. WAN, LAN and four VLANs.
What is your LAN subnet(s)
LAN network is 192.168.10.0/24
1 LAN interface is 192.168.10.200
VLAN networks are 192.168.[11|12|13|14].0/24
4 VLAN interfaces are 192.168.[111|112|113|114].200
1 WAN interface gets is public IP via DHCP from my ISP. Let's call it 52.6.111.61 (not the real value).So, I count six interfaces. According the the doc, This firewall (self) "Matches all IP addresses on all firewall interfaces."
But if I read right.. "This Firewall" should only block 192.168.113.200. Of coarse you would still be able to "route" to another address that exists on the LAN network.
That's the 64 thousand dollar question. Does "This Firewall (self)" imply ALL of the interfaces (as the Netgate doc might lead one to believe) or only the interface of the VLAN that I'm on?
If your LAN network is 192.168.10.0/24 then you should have that whole subnet blocked if you are trying to protect your LAN from your VLAN as it appears you are trying to do.
I'm perfectly willing to block specific entire (or partial) subnets as needed, but if I choose to not block general inter-subnet traffic, I would still like to be able block access to the firewall from any interface with a single "This Firewall (self)" rule.
The question is: Is the doc correct (about matching on ALL firewall interfaces) or not. My testing says no. Either the doc is wrong or misleading or there's a bug or I'm completely missing something.
What is your public IP address? (don't print it here) Try hitting that from your VLAN. You might need to block that also.
I don't want to block access to the public IP. That's my egress point to the internet. It would be nice if "This Firewall (self)" blocked access to pfSense from that interface as well.
--- I found something ---
I took a long break before finishing this response. I tried a few other things and discovered something that I don't have time to investigate fully at the moment. Ping specifically (maybe icmp generally) is not reliably blocked by "This Firewall (self)". (But, https is reliably blocked.)
It depends on whether or not you have a series of pings running or not before you start blocking or passing (and what state your firewall was in when you started the stream). And it seems to have nothing to do with "This Firewall (self)". These odd behaviors occur with single host destination.
If pings are running (maybe 1 per second), before you block, the stream doesn't block when you set the block rule. If you stop the stream and then wait long enough before you starting pinging again against a blocking rule, things block as expected. If you don't wait long, the pings continue with responses against a blocking rule.
If blocked, they even start responding again if you unblock. But, if you block again, they don't block. It feels like some unintended statefulness is at play here.
I don't know all the nuances of this behavior yet, but until I dust off my Wireshark skills and figure this out, I won't count on ping streams to confirm my firewall rules.
-
@fullauto said in This Firewall (self) not working:
whether or not you have a series of pings running or not before you start blocking or passing
This sounds like a state issue...if there is an open state the traffic is allowed.
https://docs.netgate.com/pfsense/en/latest/troubleshooting/firewall.html#check-the-state-table
"If the rule is a block rule and there is a state table entry, the open connection will not be cut off. To see an immediate effect from a new block rule, the states must be reset."re: This Firewall, the quote I saved years ago for our internal docs was this. IIRC it was from someone at Netgate. Sorry I don't have the post link, perhaps Google will:
"When you set up your internal block rules make sure to use rules like this:
Pass from <management addresses> to This Firewall (self) on <management ports>
Reject from any to This Firewall (self) on <management ports>
...the key is you should be using This Firewall (self) as the target to make sure that any addressable interface on the firewall is covered.Otherwise if you have a rule like:
Block from LAN subnet to LAN address
Pass from LAN subnet to any (for the Internet)
You'll find that local clients can reach the firewall GUI and SSH using the external address or addresses on other connected interfaces." -
@steveits Thank you very much. One final question (I hope).
So correct specification of management ports seems to be the key to correct use of This Firewall (self).
Correct me if I'm wrong, but I think this page of doc is where I need to start to learn about management ports and related matters: https://docs.netgate.com/pfsense/en/latest/config/advanced-admin.html
It looks like 80 and 443 exclusively (unless I change them).
Are there any other resources you recommend on these topics?
Thanks in advance.
-
@fullauto re: management ports, many people create a port alias to group them, with 80, 443, and 22 if SSH is enabled. Then it can be one firewall rule instead of 3.
This Firewall should function as an alias on its own. I double checked and we for instance do have a rule for "from my home" to the office "this firewall" without any ports specified just so I can get to it if something happens to the network in the office.
-
Yep.. I was wrong above.
https://docs.netgate.com/pfsense/en/latest/firewall/configure.html
Look under "Destinations"..
