understanding firewall rules

Inxsible

From what I understand pfSense has a default deny applied to incoming traffic on a network. I saw a video where the user put in these 2 rules

My question is that if pfSense denies by default, why do we specifically need the Block Firewall Web Access rule to be defined? Wouldn't it be denied by default? What am I missing?

Gertjan

Hi,

GUEST users should be able to connect to the pfSense IP of the GUEST interface.
Like DNS on port 53, TCP and UDP, and may NTP be port 123, UDP.
Upfront, port 10443, TCP is blocked, as this is (probably) the GUI interface - and guests shouldn't admin your pfSense.

This is what I use on my 'guest' network :

pfSense has no FTP service but ports 22 and 23 could be served.

Netbios ports (not served) are also 'grounded'.

I just realized that a rule before the rule showe above :

already blocks all pfSense ports, except the DNS allowed above.

The image you showed : the answer depends on what the alias "PrivateNetworks" is.
Probably all -other ? - local networks like 192.168.x.0/24 so this rules allows guest to visit the net.
If "PrivateNetworks" doesn't include the GUEST network then the first rule makes sense.
If it includes the GUEST network, then users couldn't use pfSense's DNS facilities (probably ok for pure DoH fans).

JKnott

@Inxsible

The 2nd line allows guests to do anything, anywhere, which would include the firewall. I did a bit more than that. I allow ping only to the guest network, then block everything else on my home network and also my WAN interface, before allowing access to the rest of the world.

Bob.Dig

@Inxsible said in understanding firewall rules:

What am I missing?

Good question.
I don't know but it could be the case, that "this firewall" is not blocked by default, because it is on the same network. As far as I know, you can't block any host on the same network other then the firewall itself and that might not be the default in pfSense, so you have to do it manually.

JKnott

@Bob-Dig

On my firewall, I had to specifically allow ping to the guest interface. Without that I couldn't ping it. Of course, as you mention, that doesn't stop guests from seeing others, unless blocked by the AP.

johnpoz

Well his rule below that allows anything that is not rfc1918, or that is what I am guessing from his privatenetworks alias.. Maybe he has multiple Ips on the firewall that are not rfc1918?

Say his wan.. If he only had the one, would prob be better/clearer to use wan address vs the every IP on the firewall alias?

Where did you see that? Also keep in mind many users post up guides and images of how they do stuff without really understand what they are doing ;)

Bob.Dig

So I tested it myself and I was wrong. But I thought having seen it this way often.
So the first rule is not needed if the alias contains all rfc1918, which it looks like.

johnpoz

Also pfsense out of the box wouldn't even be listening on port 10443, guessing he is using that as his webui port? Would be my guess.

edit: d'oh he even calls out block web access ;) Unless he has multiple IPs on his firewall that do not fall within his private alias, no reason to use the this firewall alias. Then again it is a way to make sure you block access to any IP the firewall might have.

JKnott

@Bob-Dig said in understanding firewall rules:

But I thought have seeing it this way often.

One thing I've often noticed over the years is someone stating something that indicates they don't really understand the situation and so pass on nonsense. It's not limited to pfSense or even networks. I've even had a few occasions where I had to correct or teach an instructor, even at college level.

JKnott

@Bob-Dig

In my rules I used 172.16.0.0 /16 to block the entire range. I could have done that, but didn't see RFC1918 in the available selection.

Bob.Dig

@JKnott I have crafted an even slicker rule for my IoT known this now.

johnpoz

@JKnott said in understanding firewall rules:

didn't see RFC1918 in the available selection.

You have to create your own alias for this.. Its a one time set it and always have it sort of thing..

JKnott

@johnpoz

I guess I'll have to set up that alias, though in my application I don't need anything beyond the 172.16.0.0 block. Does having the 3 ranges affect filter performance?

johnpoz

Not sure how have a couple extra networks in aliases would affect anything to be honest.. Other than the table that stores them would be bigger ;)

If your not using the other networks, not really going to matter.. But this way if you do happen to throw up a vlan using some other rfc1918 space, you wouldn't need to alter your rules blocking your vlans ;)

To be honest, might not be a nice built in addition.. but then again it takes all of 5 seconds to create - and if built in, users would prob use it wrong anyway ;) heheheh

JKnott

@johnpoz

I have created the alias and see I can add it to rules. However, I'm surprised it wasn't already there, given it's a default rule on the WAN interface. However, adding 172.16.0.0 /16 was easy enough.

Inxsible

Thank you all for your responses. Let me answer any questions that were directed to me.
@Gertjan said in understanding firewall rules:

The image you showed : the answer depends on what the alias "PrivateNetworks" is.
Probably all -other ? - local networks like 192.168.x.0/24 so this rules allows guest to visit the net.
If "PrivateNetworks" doesn't include the GUEST network then the first rule makes sense.
If it includes the GUEST network, then users couldn't use pfSense's DNS facilities (probably ok for pure DoH fans).
Yes the PrivateNetworks did not include GUEST & IOTCRAP. It included all the other networks that are listed on top -- ie LAN, OFFICE, CAMERA & PHONE

@JKnott Thanks for your rules. They make sense. Was the Allow ICMP rule only to make sure that you can connect to the GUEST network in case the internet is not working for the Guest device?

@johnpoz said in understanding firewall rules:

Well his rule below that allows anything that is not rfc1918, or that is what I am guessing from his privatenetworks alias.. Maybe he has multiple Ips on the firewall that are not rfc1918?
No privatenetworks were just his other networks as I mentioned above. I don't think he included the RFC1918 networks. If we include RFC1918 -- would it mean that 2 guest devices won't be able to see each other either?

@johnpoz said in understanding firewall rules:

Where did you see that? Also keep in mind many users post up guides and images of how they do stuff without really understand what they are doing ;)

This was a youtube video by Lawrence Systems. Here's the link: https://www.youtube.com/watch?v=ouARr-4chJ8

So from all the replies, I understand that if you include the RFC1918 networks, then you don't need to explicitly create the Block rule for the Web Admin to pfSense. But if the RFC1918 is not included in the alias, then that rule is required in order to explicitly block Guest devices from accessing the pfSense admin.

Thank you all again -- you guys gave me some good tips regarding firewall rules. Much appreciated.

Inxsible

Trying to edit my previous post to separate my answers which kind of got included in the quotes. But the forum keeps giving me this error:

ERROR
Post content was flagged as spam by Akismet.com

Is post editing not allowed?

JKnott

@Inxsible said in understanding firewall rules:

@JKnott Thanks for your rules. They make sense. Was the Allow ICMP rule only to make sure that you can connect to the GUEST network in case the internet is not working for the Guest device?

That is correct. I like to be able to test things. With my rules it is possible to ping elsewhere on the Internet, but if that fails, where's the problem? With pinging the interface available, I know at least WiFi is working properly and pfSense is up.

johnpoz

So that have that same rule on all of their interfaces they were showing.. But if they are only going to have allow rules to specific - like the camera vlan where he only allows access to camera server on 192.168.5.5 it serves no real purpose..

Inxsible

@johnpoz said in understanding firewall rules:

So that have that same rule on all of their interfaces they were showing.. But if they are only going to have allow rules to specific - like the camera vlan where he only allows access to camera server on 192.168.5.5 it serves no real purpose..

So I guess the reason they didn't block the RFC1918 address is so that they could allow the CAMERA net to have access to their NVR which was on their internal LAN.