Understanding better the firewall rules
-
Again rules are ONLY evaluated on traffic that is entering the interface from the network they are connected to...
if your lan is say 192.168.1.0/24 -- when would or how could it ever see a source IP of say 1.2.3.4?? Its not possible. Lan interface would never see a source IP of 5.6.7.8 if your local network is 192.168.1.0/24..
The only possible time it could see anything other than 192.168.1.0/24 is if there was some downstream router with other networks behind it connected to your 192.168.1.0/24 network.. If that is not the case then there would be zero reason to use any on your source IP in your lan rules.
Any means exactly what it says ANY... The source IP could be ANY.. but in a lan interface it would be impossible to see anything other than lan IPs as the source.. So there is no reason to make that rule any.. Unless you have downstream routers connected to your lan, then you would have to make sure your source includes whatever downstream source IPs might be seen if you want to allow them.
-
Example :
When you know that the stars "*" mean "any" the image is quiet good readable.
The second rule : "Traffic coming into LAN interface, IPv4 & IPv6 - from the LAN, net range, is accepted"
The first rule is created when you activate the GUI and console anti lock out.The counter in front of the rules are important. You can check if your rules actually apply.
-
@gertjan thank you for your replay
OK let say I have LAN - OPT1 - OPT2
I will use your example standard out of the box rule as you shown on the pictureI will put as "SOURCE : OPT1 Net" then "Traffic coming into LAN interface, IPv4 & IPv6 - from the OPT1, net range, is accepted"
example if I have an app "192.168.1.25:8454" running on LAN and I am on the OPT1 net running windows on my laptop I can type into my browser "192.168.1.25:8454" and I will be able to access it
if that's true then, if SOURCE : "ANY" I will be able to access that app from any other interface I have !!! -
NO NO NO..
Traffic is evaluated PER interface where it enters. What rules you put on opt1 have zero to do with any other interfaces other than traffic entering opt1.. Opt2 clients wouldn't be able to do anything, other than what the rules on opt2 allow them to.
-
@johnpoz OK if you want to give access to an app that is on the LAN net “192.168.1.25:8454” from all interfaces let say you have 5 more interfaces OPT1, OPT2, OPT3 OPENVPN, IPSEC What rule you are going to put on the LAN or you have to put rules on each individual interfaces to get access to this app ? !!!
-
This other interfaces are different networks.. Your not thinking they are switch ports right..
So lan is 192.168.1/24 sand lets call opt1 192.168.2/24 and opt2 192.168.3/24
So yes if you want opt1 network to access 192.168.1.25 port 8454 then you would have to allow that on opt1 interface either directly with those specifics or an any rule on opt1 would allow it.
Its really quite simple.. As the traffic enters the interface from the network.. Run down the rules on that interface it enters on top down, first rule to trigger wins, be it a allow or block no other rules are evaluated. It really is that simple.
If you want to allow or block something on multiple interfaces you could use the floating tab rules to select which interfaces rules are applied too, and make them quick, etc.
The order that rules are evaluated is listed here.
https://www.netgate.com/docs/pfsense/firewall/firewall-rule-processing-order.html
-
@johnpoz OK OK Now I understand better. If I want opt1 host to access opt2 host it has to be allowed on the OPT1 That's why the interfaces rules are called also "INBOUND RULES" because that specific interface control only that interface network. They can go anywhere if it is allowed on the interface otherwise pfsense have embedded out of the box "DENY ALL" rule. Witch is very very clever.
-
Yes pretty much every firewall on the planet would be a default deny ;) Not sure I would call it "clever" ;) hehehe
-
@johnpoz Why not deny until you allow only what you need is easier approach, then other way around. Right ? Anyway I've come across an example here https://www.netgate.com/docs/pfsense/dns/blocking-dns-queries-to-external-resolvers.html allow 53 to LAN Address and then deny all to port 53. Is that deny rule is in this place because you want to make sure that you might place some other rule after that witch might allow dns to external resolver before hit bottom where default DENY rule will prevent this network to use other then LAN Address to resolve the queries :)
-
@johnpoz and one more question what is the "Invert Match" mean? Is this when you want to match INBOUND AND OUTBOUND REQUEST?
-
Again rules are evaluated TOP down, first rule to trigger wins.. NO OTHER rules are evaluated... So yes if you want to block access to something on the internet you would need to put it above some rules that says any to the internet.
Invert match is exactly that, I have mostly used them in destination rules.. They have nothing to do with inbound vs outbound on the traffic flow. The only way to do outbound rules is in the floating tab - and I would suggest you stay away from there until you fully up to speed on how to do normal rules on the interfaces themselves. You should only need floating rules if your doing something tricky.
Lets say you wanted to allow your dmz segment to go everywhere but not your other segments. So anything on the internet is fine.. So you could block specifically dest rfc1918 space above your any any rule.
Or you could have your allow rule say dest ! rfc1918, or not rfc1918 or inverted rf1918 all the same thing. Which is like saying hey as long as your not going here, its allowed but if dest is rfc1918 then rule would not trigger and wold hit the default deny rule and not go anywhere.
These can be tricky, and they can have issues with how the rules are evaluated. I would not suggest you use such rules unless your sure 100% what your doing, and then validate its working as expected.. These are more advanced sort of rules..
I would suggest if you want some network segment to not go somewhere then put in a specific deny to where that something is above where you allow to the internet with any any rule.
-
@johnpoz hello
I don't know if I am doing this right!!!!
Let me explain what I need and what I have make sure I don't need
I need all the cameras to hit the pfSense interface for DNS 53 and NTP 123
What I want to make sure 1st they cannot access the pfsense web gui on ports 80,443 and ssh to 22. 2nd each cams are not aware of other hosts on it's network or any other netowrk
They will be controlled from a software on the mgmt netowork,so all I need is to resolve and get the time's rightThank you
-
@xlameee said in Understanding better the firewall rules:
2nd each cams are not aware of other hosts on it’s network
This has zero to do with pfsense. Your going to need a switch that can to private vlans for that, or if wifi then set AP to isolate clients. Different makers call it different things.
What is below that.. I don't see any allow rules - is there an allow rule for any so they can use the internet? What is in your aliases?
But from your descriptions sure that would allow access to dns and ntp on the pfsense surv IP. Then block/reject anywhere else those ports.
Then if your private networks alias includes all rfc1918 space or your other networks it would block access to those. But if you have say an any any rule below that, then it would be possible to hit the web gui on your wan IP.. Which you would assume would be public.
If you do not want stuff to get to stuff on firewall, then you should use the "this firewall" dest built in alias which would include all pfsense IPs, lan, optX, wan, etc.
-
@johnpoz alias PRIVATE_NETWORK RFC1918
alias LOCAL_DNS_NTP_PORTS ports 53 123
No dont want them to access internet
Isn't is pfSense have an built in firewall rule DENY ANY to All until PASS traffic rule is in place -
yes there is a default deny for sure.. So if you do not have an allow below that then your fine other then the rule would allow your camera to hit your web gui via the wan IP address, unless it is also a rfc1918 address.
Most the time the wan IP is public, user tend to forget this when doing rule.
But if you do not have any allow rules, what would be the point of the cam being able to do dns? Other than say looking up stuff on its own network, but you stated you didn't want the cam even knowing about other devices on its own network. So having a hard time understanding the point of allowing dns?
-
@johnpoz I want them to resolve so when I configure them or adding them into the software I can use their hostnames not an IP addresses I have lots of stuff on my networks and I am an one men show here my head kind of messed up sometimes :) I can remeber them as names but hard time remembering 30+ segmentation over 3 locations :) as an IP addresses
-
That has ZERO to do with them talking to dns.. Are you saying they are registering their dns entries?
If you want to be able to resolve them by name, setup reservations or just put in host overrides.. Only if you were having the devices themselves register in dns would you need to allow them to talk to 53.. Which I find unlikely for camera's to do.
-
@johnpoz I ahve most of my network with static mapping in the unbound of pfsense
-
Great - again then allowing your cameras to talk to 53 has ZERO to do with YOU resolving them by name.
-
@johnpoz Aren't they have to have access to port 53 or actually yes yes I understand .... My host need to have an access to port 53 because I am sending request not the camera it self. So what rules do you suggest to have so I can keep them isolated and off the internet I have to create 1 rule on the top allow OPT net to OPT address or (Firewall it self)on port 123 and on the bottom REJECT OPT net to ANY and log it. Will that do the job?
