This Firewall (self) = pfsense management - is that a reasonable statement?
-
So I managed to misunderstand The Firewall (self) even after have read that it equals "every address on the firewall". I thought it would include everything connected to the firewall, e.g. my LAN devices. Not so. Blocking access to This Firewall (self) on a vlan sharing physical port/interface with LAN I could still ping devices in LAN. I had to create a blocking rule for LAN as well to stop the ping succeeding.
So is it reasonable to say that This Firewall (self) is what I use if I want to block/manage access to pfSense itself (either GUI or via SSH or something else)?
-
@pastic said in This Firewall (self) = pfsense management - is that a reasonable statement?:
The Firewall (self) even after have read that it equals "every address on the firewall"
It is.
It does not include anything that is connected to pfSense.
See for example This Firewall (self) - What does it do?Example :
Forget about the first rule, its for some of my LAN devices that connect to NUT.
The second rules is my temporary anti lock out rule (my PC is called gauche, its an alias that contains its IPv4 and IPv6) - very needed because :
The third rule : IPv4 and IPv6 traffic directed to pfSense (== "This firewall") is now blocked.I tried from another PC. A ping to pfsense, 192.168.1.1, did not answer.
Neither using IPv6.
pfSense DNS was now unreachable, so even when I could visit forum.netgate.com using the IP, 208.231.73.71, my other PC would face certificate errors, as forum.netgate.com uses https.
Etc.IMHO : Your issue is more classic. You use VLANs. Stop using VLANs and the issue is gone ;)
( or solve the VLAN issue
).edit :
If you want to block pfSense management from being accessed from an interface, use this :
"PORTAL subnets" = all the IPs possible on the interface called "PORTAL".
You have to create the port alias "ThisFirewallPorts", and it contains the ports "21,22,23,80,443".
Take note : port 53 (DNS) and 123 (NTP), are still possible.
pfSense doesn't have a FTP server (21) neither a telnet server (23), but I've added them anyway. -
@pastic said in This Firewall (self) = pfsense management - is that a reasonable statement?:
LAN I could still ping devices in LAN. I had to create a blocking rule for LAN as well to stop the ping succeeding.
What could ping something on your lan? Devices on the same network talking to each other has nothing to do with pfsense. There is no rule you could put on pfsense that would stop lan device A from pinging device B
Not unless you had a bridge on pfsense and device A was on one side of the bridge and B was on the other.
What exactly are you wanting to stop from pinging what?
-
@johnpoz The pinging is just me trying to verify if I succeed in blocking connections or not. :-) In this case from a VLAN that is sharing the firewall port with LAN.
-
@pastic so your pinging something in lan from vlan. Yeah "this firewall" wouldn't match such a rule.
Your rule to stop whatever from talking to something lan should be on the vlan interface, in the right order and destination should be either lan subnets or the specific IP you want to block access to from vlan.
Keep in mind, common thing users run into.. If if say you ping device B in lan from A in vlan then put in a block, you have to make sure the state has timed out or been removed or your block wont take place.
While icmp should really be stateless, pfsense does create a state.. It has a very short life.. But you could run into an issue where even after you put in the block rule you can still ping if you had a constant ping going or did test ping fast after you put in the rule and state hadn't gone away.
-
@johnpoz This is how I think I have succeeded in isolating devices in I****VLAN from all other subnets in my network as well as from reaching pfsense itself.
-
@pastic yeah those should work.. Common practice has been to create an alias with all the rfc1918 space in it.. So if you don't wan a specific vlan to get to any of your other networks vs creating rules for each network you can just block them with 1 rule blocking access to rfc1918, this helps in blocking access to new networks you might add, etc.
Also unless this a transit network, its also good practice to set the source to the network, ie if you making the rules on vlanX the source would be vlanX subnets, because there should never be any non vlanX source IPs hitting this interface.
