Basic ruleset to allow inet acces for all networks
-
i am looking for a best practice for creating a basic ruleset to allow inet access from all networks.
my networks:
WAN,
LAN: 192.168.100.0/24
DMZ: 192.168.110.0/24
WIFI: 192.168.120.0/24first i thought "Wan Address" is any address in the WAN, which i found out, is not true. it is only the WAN interface ip.
possibility1:
allow WIFI -> !LAN
allow WIFI -> !DMZ
allow DMZ -> !LAN
allow DMZ -> !WIFI
allow LAN -> !DMZ
allow LAN -> !WIFIpossibility2:
create an "LOCAL" alias with the following networks in it
192.168.100.0/24
192.168.110.0/24
192.168.120.0/24
and add a the rules
allow LAN -> !LOCAL
allow DMZ -> !LOCAL
allow WIFI -> !LOCALbut if i / somebody changes the ip of a network and forgets to adapt the alias it could be quite risky.
is there a better solution to my problem? is there any best practice?
(comming from ipcop, where i have the nice option to only allow WIFI -> WAN)greets
-
I usually do your "possibility2".
-
-
hi,
thank you for your fast replies.
i changed my LOCAL alias to the following:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16so i am still secure if i change an ipadress range of a local network and forget to adapt the LOCAL alias.
but in general, isn't it a suboptimal design?
wouldn't it be better to have a "WAN-subnet" where i allow the access to WAN (like in ipcop)
also it would be good to have this topic added to the faq.
i think nearly all ipcop users (and maybe others too) misunderstand the "WAN-address" parameter in the destination section.greets
-
I doubt you will see a modified approach to work exactly as you describe. By default all new interfaces (other than the default LAN with its default allow any rule) block all traffic. Then you allow only the traffic out that you want, in your case possibility2 works very well to accomplish what your goal is. Aliases provide an easy way to get this functionality. pfSense generally requires that you understand how firewall rules are evaluated once you move beyond a basic LAN/WAN two interface setup, in order to configure things properly, but it's very powerful (and secure-by-default–except for the default LAN-out rule which is less secure but expected behavior) once you understand how rules are evaluated. And it's actually kind of nice IMHO to have all interfaces be on "equal footing" with each other, without special rules unless you create them (although LAN and WAN are a bit different, but still you can have multiple of either, with a WAN being defined as having a default gateway and any other interface is internal, and there is more "automation" to NAT rules than direct firewall rules).
In other words, you need to understand how pfSense does things (which is more like many enterprise firewalls and routers than home ones) to configure it well. I don't see that changing, though 2.0 does add a lot of nice new functionality. But conceptually very similar.
However, in version 2.0 (still in beta though usable to some extent, arguably (sometimes heavily argued :-) ), you can create "interface groups." Add whatever interfaces you want to a group, and then create rules that apply to all the interfaces in that group. The rules still apply after the direct per-interface rules (as far as order evaluated) but it may give you a more logical layout to accomplish what you're wanting to do. You'd still need the LOCAL alias, as pfSense does not have a built-in idea of "all protected networks" beyond "this is a WAN" and "this is a LAN" (as defined as having a default gateway or not). It makes more sense this way too, given that many people have multiple WAN connections and multiple LAN/DMZ connections; assumptions would likely only work for some cases.
There's my six cents ;-)
