Aliases vs. Individual Rules - what is best practice?
-
There is so much conflicting information out there on rules and allowing or blocking access, etc. and the pfSense docs are excellent but very high-level and non-specific (because there are an infinite number of configurations).
In the past I have created aliases and either allowed access from subnet1 or IP1 to alias1 or !allow (block) subnet1 or IP1 to alias1. I'm redoing my rules because I need to isolate subnets, allow some subnets to talk to other subnets or specific IPs, and isolate some subnets or IPs to specific gateways but not others.
Currently I have the basic Load Balancing rules in place on all subnets:
"Allow All-IPv4 from LAN net to *Any on/via LoadBalance Gateway"
"Allow All-IPv4 from LAN net to *Any on/via WAN1 Fail to WAN2 Gateway"
"Allow All-IPv4 from LAN net to *Any on/via WAN2 Fail to WAN1 Gateway"This gets each subnet out to the internet only and allows inter-subnet access but not subnet1 to subnet2 access. All subnets can ping any subnet gateway and access pfSense web GUI but nothing else on any other subnet.
I know that my allow/block rules need to be BEFORE those rules. Should they be allow/block to aliases (which would be groups of other subnets or IPs) or should it be individual rules specifying each subnet (place) that is allowed/blocked?
I have a WAP with guest access that I want to isolate all of those users to a specific ISP (WAN2) and NOT use the load balancing or ever failover to WAN1. When I made a rule:
"Allow All-IPv4 from 'WAPGUEST net' to *(Any) on/via WAN2_Gateway"
I was not able to get to the internet, and was only able to talk to others on the same subnet.
Likewise I have a subnet with a web server and email server that I want to do the same as well as restrict them so that they can't even talk to each other on same subnet (I can do those rules).
I also have a different group of three subnets that I would like to be able to talk among themselves but nothing else - and not use load balancing however take advantage of failover, meaning they stick to WAN2 and only failover to WAN1 if WAN2 is down. Those subnets need to talk to individual IPs in other outside places as well.
Are there tutorials for this? How would I go about learning what way to build rules that suit my needs? Should I approach it all with Aliases or should I just start plugging away at a long list of individual rules per subnet?
Thanks.
-
aliases could wind up expanding to individual rules; they make it easy for you to write the rules. Say you have an alias AllowedPorts that contains http, https, dns, ntp. You use that alias as the destination for the ports on TCP rules; that expands to 3 different rules after it gets loaded into pf. ssh to your box, then "pfctl -sr" to see the ruleset after it's loaded and expanded. You wind up seeing all your user defined rules after an anchor "userrules", a bunch of system ones before that (default deny, passing ICMP etc).
Aliases are a way of making it easier on you to write rules you can understand. Is it easier to think of "I need a rule to allow outbound http keeping state and a rule to allow outbound https keeping state" or "I need a rule to allow outbound to AllowedPorts keeping state"? You need an other protocol, add one to the alias instead of another rule.
If you are not serving anything to the outside world, the default deny on the WAN means you don't need to put rules there.
See if you can find "The Book of pf" by Peter Hansteen. It's directed at OpenBSD and pf but since pfSense is "FreeBSD with a port of pf" under the hood, it can give you a good understanding.
If you haven't yet, draw yourself a block diagram of your network, add IP addresses as needed. Then start at one endpoint, think about the data you want to send, and trace it out. That helps alot with "what rules where".
-
I'm just looking for a template or good base set of rules to start with. This is all still in a lab environment while I'm trying to figure it out so I'm happy to learn by trial and error but trying to tweak LB+Failover as well as rules and then add NATs for web/email/other is just a lot to swallow all at once.
This isn't really directed at you but it's a pretty common occurrence that people come here expecting to find a walkthrough for their particular set of circumstances. Your description is pretty specific. I don't think you're going to find a template.
is just a lot to swallow all at once
So don't. Add one thing at a time. Nothing you're describing is particularly difficult.
I want to isolate the web & email servers to one subnet on one WAN. No failover.
I would make that WAN the default gateway. Then just don't set a gateway for the rules on that interface. For isolation the general technique is:
Pass specific local assets the servers need (DNS, etc)
Reject less-specific local assets you don't want them to have access to (other LANs, This firewall, etc)
Pass everything else (the internet).Note that you might not need to pass everything for a server DMZ like this. A mail server might be perfectly happy with just DNS and SMTP. Your web server might not need to make any outbound connections and be happy with just DNS. You do not need any pass rules on your DMZ in order for your servers to accept connections from the outside. Just like you don't need any pass rules on WAN to allow hosts to make connections out.
I want other subnets to be LB+Failover but internet only
Again:
Pass specific local assets the hosts on the interface need (DNS, etc. Don't set a gateway for local assets)
Reject less-specific local assets you don't want them to have access to (other LANs/OPTs, This firewall, etc)
Pass everything else.This time set the gateway group on your rules that pass traffic to internet assets. If you do not want them to have access to any other local assets not already specifically passed then you don't have to worry much about bypassing policy routing.
I want others to be LB+Failover and talk to other subnets.
This is probably the one messing you up.
Pass specific local assets the hosts on the interface need (DNS, etc. Don't set a gateway for local assets)
Reject anything you don't want them to have access to
Pass the more-specific local assets you want hosts on this interface to be able to access (Other LANs, etc. Don't set a gateway on these rules)
Pass everything else (Set the gateway group here.)When you send certain traffic to a certain gateway/group, you are policy routing:
https://doc.pfsense.org/index.php/What_is_policy_routing
You need to tell the firewall to NOT policy route local traffic:
https://doc.pfsense.org/index.php/Bypassing_Policy_Routing
-
You say you are still in a lab environment. What SINGLE problem do you want to solve?
I simply cannot do a forum conversation with all these variables.
Once you understand how the firewall works, you'll be fine.
Blow out everything you've done and we can work on ONE problem. You pick it.
I am going to repeat myself. You need to read and understand all of this:
https://doc.pfsense.org/index.php/Firewall_Rule_Processing_Order
https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting
https://doc.pfsense.org/index.php/What_is_policy_routing
https://doc.pfsense.org/index.php/Bypassing_Policy_Routing
https://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense
https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting
-
Maybe this is making more sense: Pass important, block important, allow all??
It's not really importance, it's specificity.
Pass specific local assets the users need (Like access to DNS)
Reject less-specific access to local assets (Like LAN, and OPT)
Pass everything else (the internet)This all hinges on you understanding what interface the rules should be placed on, which is all described in the firewall rule troubleshooting link above.
-
You are probably dealing with NAT reflection if I understand the problem description.
Instead, you want your internal DNS to return internal addresses for internal servers. You want your outside DNS to return outside addresses for your servers (the address that is port-forwarded.)
Commonly called Split DNS and can be accomplished using host overrides in the DNS Resolver. BIND calls them views IIRC (queries from inside addresses get answered this way, queries from everywhere else get answered another way).
Further, on your WAP rules, the only rule of the last three that will ever match is the one with gateway LB. The other policy routes will never process any traffic.
Still further, a suggestion I have on your XX (DMZ) would be to change all those block rules to reject rules. Block is fine if you want to be "stealth" to inbound connections on WAN but there is no reason not to immediately return a NAK to internal hosts and servers instead of just letting them hang until timeout.