Not understanding firewall rules
-
pfSense+ 22.05 Release (amd64)
TP-Link 3428X switchVlan 1 named SYSTEM 10.50.0.91/24
Vlan 10 named GENERAL 10.50.10.1/24
Vlan 20 named IOT 10.50.20.1/24
Vlan 30 named PHONES 10.50.30.1/24The router is on SYSTEM at 10.50.0.91:10443
The switch is on GENERAL at 10.50.0.90
The TP-Link Controller is on Phones at 10.50.30.89The firewall rules for GENERAL consist as follows:
1 - An allow rule for two specific computers to allow access to the router, switch and Controller using TCP/UDP
2 - An allow rule for two specific computers to allow access to the router, switch and Controller using ICMP3 - A restrict rule for GENERAL for TCP to 10.50.0.91 at port 10443
4 - A restrict rule for GENERAL to 10.50.0.90
5 - A restrict rule for GENERAL for TCP to 10.50.30.89
These prevent all other devices from accessing the login page of the control devices.6 - A restrict rule from GENERAL to IOT
7 - A restrict rule from GENERAL to PHONES
These prevent access from the GENERAL Vlan to the others.8 - An allow rule from GENERAL to *
The system works as desired but I feel I should not need rules 6 and 7. But because of the rule 8, I can ping any device on any Vlan if they are disabled.
So, I disabled rule 8 and added a rule that will allow access from GENERAL to SYSTEM. But, I lose internet access. I tried making the rule from GENERAL to the specific IP of the router (10.50.0.91) and still no internet access. I tried just about all the choices in the pulldown list without success.
I am obviously missing some information I need. My question is why do I need the make the destination any in order to have internet access?
-
@barth It’s rather simple if you look at it like this:
1: The firewall only applies a rule on traffic where it starts from. So a rule needs to apply to the interface where traffic begins/initiates.
2: The firewall only passes traffic to and from IP addresses you specifically allow.
Number one means you need to create rules on each interface to allow any trafic from clients on those interfaces to anything (both internet and other interfaces)
Number two means you need a rule like your number 8. The internet consists of millions and millions of public ip addresses that you consider the internet, and to access them you need a rule.
TIP: ANY (or *) means ALL IP addresses, thus your rule number 8 needs rules before number 8 to block access to your other VLANs/Interfaces if that is not desired. If you would like a rule that only allows access to the internet, you could:
1: Create a ALIAS/Group with the all the networks you have on your different interfaces - fx: Internal_Network: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
2: Create your “internet access” rule like this:
Souce: GENERAL, Port ANY
Destination: Host or Alias: !Internal_Networks, Port ANY
(The exclamation mark means your selected NOT in destination).Then the rule only passes traffic to IPadresses NOT in your Internal_Networks Alias.
But remember you then need to create allow rules for access to DNS, NTP, PING on the firewall itself (and what ever else you need). This is needed because the firewalls own IP on GENERAL is also included in “Internal_Networks”.
But I use this model because it clearly indicates what traffic is actually allowed - as opposed to the “forgotten” access that ANY rules include. -
Thank you. I'll review the rules on all the interfaces and get back.
Bart
-
I'm trying this on my IOT network just so I don't lock myself out of my system! :-)
As my entire system runs on 10.50.x.x, I made an alias named Internal which is 10.50.0.0/19. This should include everything in the range of 10.50.00xx.xxxx as I understand it.
I then made disabled everything in IOT and added a rule in IOT that says Source: IOT net
Port: ANY
Destination: !Internal
Port: ANYAnd below that a rule that says
Source: IOT net
Port: ANY
Destination: ANY
Port: ANYThose are the only rules in IOT
I plugged a laptop into a port on my switch that is part of IOT and verified that it got an IP of 10.50.20.200. I then pinged a device that was on IOT and got a reply. I then pinged 10.50.30.20 and got a reply. I pinged 10.50.10.21 and get a reply.
From what you posted, my understanding is that the first rule should prevent me from getting a reply from anything other than 10.50.20.x
What am I missing?
-
@barth said in Not understanding firewall rules:
I then made disabled everything in IOT and added a rule in IOT that says Source: IOT net
Port: ANY
Destination: !Internal
Port: ANYWhat is the definition of the "internal" alias?
-
@rcoleman-netgate said in Not understanding firewall rules:
What is the definition of the "internal" alias?
"alias named Internal which is 10.50.0.0/19" ;)
Bart you may want to block access to the pfSense IPs notably the WAN IP. Use "This Firewall", see the last picture in https://docs.netgate.com/pfsense/en/latest/recipes/remote-firewall-administration.html#strict-management.
Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
Upvote 👍 helpful posts! -
@steveits said in Not understanding firewall rules:
"alias named Internal which is 10.50.0.0/19" ;)
oooooooooo i seeeeeeeeeee :D
-
@SteveITS
My intention with this rule is to block access from IOT to all devices and or Vlans on this network Except for the internet. That's why I used that address in the alias InternalBart
-
This post is deleted! -
Sorry for the screwed up post above this:
Well, let's try this:
10.50.0.0/19 would include any IP between 10.50.0.0 and 10.50.99.255
and would exclude any IP between 10.50.100.0 and 10.50.255.255Is this correct?
And, if so, if my alias Internal is 10.50.0.0/19 and my rule says to pass anything to NOT Internal, shouldn't it block anything in the first group of IPs?
And, if this is correct then, from a computer plugged into a port on my switch that is assigned to IOT, and has an IP address of 10.50.20.200, I should be able to ping anything on the IOT Vlan, and nothing else.
Is this correct?
But, I can!
-
@barth No.
The firewall evaluates rules from top down to se if it can match traffic to a rule. A match is when the rule specifically matches both the source and destination of the packet. If no rules match (passed the last visual rule), the traffic is dropped by the firewall.
In your case the ping against IPs on you other VLANs does not match the first rule (destination: !internal).
So it passes on to the next rule which is any/any. It matches, and thus you can ping anything. If you ONLY want internet access, you need to delete your second rule. Then you have achieved what you are looking for.Rememeber though:
1: Clients will get a IP from Firewall DHCP even though no rules visually pass DHCP traffic. That’s a build in feature.
2: If you only have a rule to allow access to the Internet, you need to setup the DHCP server to provide internet based DNS servers instead of the Firewall itself. Otherwise they cannot resolve names. -
Not a fan myself of the ! method.. Rules should be very explicit so they are easy for both pfsense and the user to interpret.
If you do not want this vlan/network to get to your other vlans/networks - then create a alias that includes your networks, or all rfc1918 space for that matter and block/reject it vs using a ! rule..
Here is example of a locked down network.
You can adjust per your specific wants/needs - these allow ping, dns, and ntp to talk to the pfsense interface on this network. Blocks all other access to any pfsense IP - this prevents access to say the pfsense gui. The rfc1918 alias prevents access to any of your other networks, 10/8, 172.16/12, 192.168/16
Reject can be better than block for internal because this tells the client right away via icmp message - hey you are not getting there, this can keep the client from banging its head trying to go there via retrans because it got no answer.
-
@johnpoz said in Not understanding firewall rules:
Not a fan myself of the ! method.. Rules should be very explicit so they are easy for both pfsense and the user to interpret.
If you do not want this vlan/network to get to your other vlans/networks - then create a alias that includes your networks, or all rfc1918 space for that matter and block/reject it vs using a ! rule..
Here is example of a locked down network.
You can adjust per your specific wants/needs - these allow ping, dns, and ntp to talk to the pfsense interface on this network. Blocks all other access to any pfsense IP - this prevents access to say the pfsense gui. The rfc1918 alias prevents access to any of your other networks, 10/8, 172.16/12, 192.168/16
Reject can be better than block for internal because this tells the client right away via icmp message - hey you are not getting there, this can keep the client from banging its head trying to go there via retrans because it got no answer.
For the record: I completely agree with @johnpoz, and my own firewall is configured exactly like his - because then the rules clearly tells you whats happening.
My only little snag with his approach is I do both :-)
My last rule - it's also called "allow Internet" - but it is a !RFC1918 rule, so it actually only allows access to internet. That way any mistake I might make above in blocking access, still does not get a free pass :-) The rule only allows what it says it does. -
Thank you all so very much!
Late last night, or rather early this morning, The explanation keyser gave became my AHA! moment. You are right about keeping it simple, but using the !, I'm able to replace several rules with this one. With a background in programming, I usually don't have a problem with using this type of logic. Notice the "usually" there!
Guess I'm getting old.
Anyway, thanks to you all (again) I can mark this thread as Solved.
Bart
-
@barth said in Not understanding firewall rules:
'm able to replace several rules with this one.
Why is that advantage? Unless you had like hundred of rules that you had to scroll through? 1 rule vs 100 isn't going to be seen as any sort of performance bump, etc.
Replacing multiple rules combining things to me would be disadvantage in ease of reading the rule, and in making slight changes to it, etc. Bang (!) rules do a use cases - but normally its less complex to just clearly create a very explicit rule, be that 10 rules so what they are one time things - your not having to edit rules every day are you? On multiple interfaces, etc.
-
First, let me clearly state I am not trying to be argumentative. I truly enjoy a thorough discussion of any computer subject as I have learned so much from them.
So, in defense of my way of doing it, The way I read Netgate's documentation is that the best way of creating rules is to realize that everything is blocked by default and rules should be created to allow only what is wanted. I took that as a challenge. I was able to limit my allowance to only the part of the range of IPs I wanted and by creating a single pass rule for ports above this one, I did everything with just two rules. With only two rules to look at and understand, I think the way I did it, is actually easier to understand.
Your turn! :-)
Bart
-
@barth said in Not understanding firewall rules:
I think the way I did it, is actually easier to understand.
But in practice it is not easier to make it work as the bang rules are more likely to have consequences which are not as obvious.
There is a difference between thinking understanding is good and the understanding actually being accurate. -
Point taken!
-
@barth Your two rules don't work.. Or why is there even this thread ;) So clearly you don't understand them very well ;)
I did everything with just two rules.
If that is what you want that is fine.. Lets see you rules you have created.
What did you accomplish? Did you block access to your pfsense web gui? Which is most likely a public IP?
Was not aware there was a contest to see how few rules you could create to accomplish what you want to accomplish. Bang rules have had issues in the past, especially if your using vips.. Have at it that is what you want to do.
I am not taking your comments as argumentative btw - I too like a discussion and am very passionate about this subject matter so please do not take any of my comments as negative or argumentative... More than happy to discuss the many different ways to skin a cat.. Firewall rules can be done in different ways to accomplish the same goal.. As long as your goal is accomplished be it you take a shortcut or a the long way doesn't matter as long as you fully understand what the rules are saying and what they are doing.. And able to troubleshoot them if need be to why something might not be working the way you think they should be working.
I am a fan of KISS (keep it simple stupid).. If you can do something easy, then do it that way. But to me that is being very explicit in exactly what the rules are doing. That bang symbol can be missed when looking at rules ;)
I had a very similar discussion long time ago with very smart guy on this forum.. And one thing he said made great sense, don't block with an allow.. I wasn't seeing it that way, I was seeing at a more explicit allow, etc. But in the long run his point was very valid. If you want to block then block, if you want to allow then allow - its a less convoluted method, and is more in line with the KISS practice ;)
-
You know (I think it's obvious) I'm new to this networking thing. I made my living years ago doing custom, contract programming. I wanted Vlans on my network for the usual reasons. I thought, "Networking? Huh, you just plug in the cables and it works! I can even make my own cables. How hard can this be?" Well, I found out. And, learned a whole lot of respect for this end of the business. So now I'm sure you can understand where I come from. By the way, I've been out of the computer business for nearly 20 years.
You want to see my rules. Do I do a screen capture and use the little button, second on the right, to upload it?
Or, as they're only two, should I just describe them? /S
As far as don't block with an allow, that does make a great deal of sense.
I do want to split my IOT Vlan up a little more. At what point would I be seeing a degradation in performance? How hard can I push this little 4100?
