Rule set for many interfaces
chrullrich last edited by
I'm getting used to pfSense (coming from Checkpoint and looking to switch), and I'm having trouble deciding how to set up my rules. My environment has quite a few separate internal networks, implemented as VLANs. There are ~8 of them, plus one WAN (and a second one once I get around to figuring out multi-WAN).
Several of the internal networks, however, have very similar rules on them, and I don't like the idea of creating essentially the same rule on each of the VLAN interfaces. In the existing firewall, that is easy because it does not concern itself with interfaces in the rule set, it looks only at addresses (and knows what source addresses to expect on each interface, of course).
The closest equivalent to that I can find in pfSense is using only floating rules with no interface selected, but I suspect that will become an unmanageable mess within minutes.
I'm sure someone here has already been in this situation. How have you solved it? I'll be grateful for any hints.
8 is not very many.
Need examples of the types of rules you are talking about. Your options are pretty much interface groups, floating rules, or duplicating them.
KOM last edited by
Interface group is probably the simpler way to do it.
Mr. Jingles last edited by
I'm just 'playing' with interface groups ;D
If I may sneak in with a quick question: a VPN client interface (assume: PIA), is that part of the LAN interface group or the WAN interface group?
(I suspect LAN, but I'm not exactly sure).
Btw, what I am missing in Interface Groups is 'variables': how can I tell, using only one firewall rule in an interface group, that, as a matter of example, each VLAN-net is allowed to each own interface address to certain ports captured in an alias?
I know of systems that do work like that, and, translated to pfSense, it would be something like variables that are either standard in pfSense, or can be customized by the user.
Only 1 Firewall rule on the VLAN Interface Group, for 3965 VLANs ( ;D ):
IPV4 | $INT_NET$ | * | $INT_ADDRESS$ | PORT_ALIAS_DNS_NTP_ETC | * | none description.
Since I know of large systems that multinationals use that have the same logic, it appears not be useless, from a maintenance point of view.
Interface groups on WAN are troublesome for pass rules because the states do not get reply-to. They work great for block rules there. I use it to block interface group WANS outbound for RFC1918 and tagged traffic ("NO_WAN_EGRESS") etc.