Sanity check for basic firewall rules
-
Before I go live with my firewall I was hoping to get a sanity check for my firewall rules.
PORT1WAN has only the 2 rules supplied by pfsense, blocking RFC 1918 networks and bogon networks.
Q1: Is that sufficient?
All of my other interfaces are local networks.
I want the interface for the guest network to have only access to the Internet. Its rules are as follows:
Block IPv4+6 * * This Firewall Firewall_Admin_Ports * … Pass IPv4+6 * * This Firewall * * … Block IPv4+6 * * <interface> subnets * * … Pass IPv4+6 * * * * * ….The rule containing the <interface> placeholder is repeated for every local interface.
Q2: Will the block rule for the <interface> subnets reliably block all traffic to those subnets?
Q3: Can/Should I add a rule to block destinations of RFC 1918 networks before that final pass rule that gives access to the Internet?
Additional context: I have one local interface for network administration that has no block rules for any local interfaces. My plan for other local interfaces is to duplicate the rules for the guest network and add at the top whatever pass rules are appropriate to for access to local networks.
Thanks for your help.
-
@gld Netgate has doc examples for guest networks, e.g. https://docs.netgate.com/pfsense/en/latest/solutions/netgate-4200/opt-lan.html#isolated
All interfaces have a default block all rule. So adding (only) block rules on WAN is unnecessary but doesn’t hurt.
Yes block rules will work. Read through the example above though.
-
@SteveITS Thank you.
I followed that example previously. But then, for fun, I tried to get IPv6 working on one sub net. Allowing IPv6 traffic to pass to the Internet ALSO allowed it to pass to the other local networks. I'm using the "<interface> subnets" aliases with the expectation that both IPv4 and IPv6 traffic will be blocked, based on a forum thread.
I gave up on IPv6 for now so I don't have any IPv6 stuff turned on, but sooner or later I'll probably take another run at it. Just for fun.
Sometime in the future I will attempt to figure out exactly what ports on the firewall need to be generally accessible.
Thanks again.
-
@gld said in Sanity check for basic firewall rules:
Allowing IPv6 traffic to pass to the Internet ALSO allowed it to pass to the other local networks. I'm using the "<interface> subnets" aliases with the expectation that both IPv4 and IPv6 traffic will be blocked, based on a forum thread.
It should work the same as IPv4 rules. Can you post a screenshot?
You can block from "any" instead of "LAN subnets" if you want to be more general. "LAN subnets" won't match any subnets behind pfSense that pfSense doesn't know about, most notably using static routes to an internal router.
-
@SteveITS said in Sanity check for basic firewall rules:
@gld said in Sanity check for basic firewall rules:
Allowing IPv6 traffic to pass to the Internet ALSO allowed it to pass to the other local networks. I'm using the "<interface> subnets" aliases with the expectation that both IPv4 and IPv6 traffic will be blocked, based on a forum thread.
It should work the same as IPv4 rules. Can you post a screenshot?
It is probably premature to work this issue, at least for me. I have yet to figure out how to use IPv6 addresses in my local network, which will have a prefix dynamically provided by my ISP, while also having static references to specific local hosts and networks. I'm giving up on using IPv6 until I learn how to do this.
But if you are interested in what I did, I'll attempt to describe it.
Using the documentation example you referenced above as an example, the rules for the OPTX interface (which are not associated with the firewall) are
Block IPv4 * * * PrivateNets * * ... Pass IPv4 * OPTX subnets * * * * ...Side note: In the last rule I don't understand the difference between source = "OPTX subnets" and source = "*".
As I recall, to get IPv6 working on the OPTX subnet I changed these rules to:
Block IPv4+6 * * * PrivateNets * * ... Pass IPv4+6 * * * * * * ...My client on the OPTX subnet could then get out on the Internet and pass all the IPv6 tests. However, since the PrivateNets alias contains only IPv4 addresses, it seems that packets referencing IPv6 addresses won't match the block rule and will subsequently match the final pass rule and be passed, even to the PrivateNets, if there were a client on one of those networks with an IPv6 address. Keep in mind I was flailing around at this point so what I was doing might have been a bit different from what I thought I was doing. I would not take this experience as a definitive test.
I don't know how to reference the IPv6 addresses of my private networks within an alias. So I resorted to using the "<interface> subnets" alias explicitly. A bit ugly, because now there is one block rule for every private <interface>, but it is clear and once set up for one interface these rules can be copied as a block to other interface rule sets. And I imagine it is unnecessary as I'm not using IPv6 addresses anywhere in my network at this time. But at some future point I'm likely going to get the itch to try again to get IPv6 working so I'm trying to lock down IPv6 access right now in preparation for my future experimentation.
Thanks again for your help.
-
@gld said in Sanity check for basic firewall rules:
rules for the OPTX interface (which are not associated with the firewall)
Then what is it? I'm a bit confused. OPT1/2/3/etc are the default names when adding more interfaces than WAN and LAN. Which some models call PORT1WAN for example. The documentation just assumes you've added OPT1 and need to configure it. You can name it anything, like DMZ or MYLAB.
"OPT1 subnets" would be any subnet assigned to the OPT1 interface.
If you don't have a pass rule for IPV6 then that traffic is not allowed. Each interface has a default block rule.
If the IPv6 addresses are automatically assigned then no you don't know the IPv6 subnets so using the aliases is probably better than creating your own aliases and having the IPv6 subnets change on you later. "PrivateNets" can be all RFC1918 subnets because those are known.
IPv6 is much easier if you let it be automatic. Add it to WAN, set a prefix delegation request large enough (/57, /60, depends on what your ISP allows) and set the internal interface to Track Interface. Then pfSense will get an IPv6 for WAN, and assign a unique block for the internal interface.
-
@SteveITS said in Sanity check for basic firewall rules:
@gld said in Sanity check for basic firewall rules:
rules for the OPTX interface (which are not associated with the firewall)
Then what is it? I'm a bit confused. OPT1/2/3/etc are the default names when adding more interfaces than WAN and LAN. Which some models call PORT1WAN for example. The documentation just assumes you've added OPT1 and need to configure it. You can name it anything, like DMZ or MYLAB.
"OPT1 subnets" would be any subnet assigned to the OPT1 interface.
I was using, as an example, the example in the documentation you referenced. The table in the documentation has the title, "Example firewall rules for isolated LAN type segment". Yes I understand everything you say here.
If you don't have a pass rule for IPV6 then that traffic is not allowed. Each interface has a default block rule.
My understanding is that to allow a subnet get out on the Internet with a IPv6 address there must be an IPv6 pass rule.
If the IPv6 addresses are automatically assigned then no you don't know the IPv6 subnets so using the aliases is probably better than creating your own aliases and having the IPv6 subnets change on you later. "PrivateNets" can be all RFC1918 subnets because those are known.
IPv6 is much easier if you let it be automatic. Add it to WAN, set a prefix delegation request large enough (/57, /60, depends on what your ISP allows) and set the internal interface to Track Interface. Then pfSense will get an IPv6 for WAN, and assign a unique block for the internal interface.
Yes. I was able to get this to work. I eventually got multiple subnets assigned IPv6 addresses. For them to get out to the Internet I had to add a IPv6 pass rule. After that the firewall rules similar to the documentation example you cited and I copied earlier failed to isolate traffic between the subnets I was trying to keep isolated.
I very well might have some significant misunderstandings about IPv6. I will probably take another run at that sometime in the future. For now I'm good.