Bridge firewall rules
My pfsense has 3 interfaces. WAN, LAN and PUBLIC. WAN and PUBLIC are bridged together.
If I want to allow traffic unrestricted from WAN to PUBLIC, on the WAN tab in the firewall rules, is it normal to create a rule and put the destination as "WAN Subnet"? This is the only way I can get this to work, and I guess it makes sense as Public and WAN share the same subnet. Since Public hasn't been assigned an address, giving a destination "Public Subnet" doesn't work.
Also, I wish for the LAN to remain secure from both WAN and PUBLIC. For this to work, in the WAN tab and PUBLIC tab I've blocked access to the LAN subnet.
Does the above seem correct and secure?
Since WAN and PUBLIC are bridged, WAN Subnet == PUBLIC subnet. So yes adding a firewall rule to allow incoming traffic on WAN from WAN subnet to allow everything in on PUBLIC is (kind of) correct. Also explicitly blocking LAN from WAN and PUBLIC interface is correct, however I take it the rule on the WAN interface is redundant as it already blocks by default and there's no general rule to allow everything in (as opposed to the rule on the WAN interface for PUBLIC). Just make sure the block any to LAN rule on the PUBLIC interface is above the allow any rule.
Regarding security: for LAN this is fine, but for PUBLIC this is obviously not very secure. Since you have the possibility of a filtering bridge, why not use it and only allow specific traffic in? Als note that the pfSense WAN IP is also included in "WAN subnet" and your rule is now opening access to your firewall completely. I guess this is not what you want. You can fix that with specific allow/block rules to the firewall WAN IP above the allow any to WAN subnet for the PUBLIC interface.
Thanks for your help.
Regarding the insecurity from WAN to PUBLIC, since this is for a public VPS hosting system, I'm leaving it up to the individual customers to secure their VMs using iptables. Also, since each machine on the PUBLIC interface will not trust each other, placing rules in pfSense doesn't really help (except block traffic from WAN). Thanks for reminding me to block the IP for the pfsense WAN interface address.
By the way, here is what my WAN tab currently looks like. Please ignore the lines which are scribbled out. Also, I haven't blocked the pfsense WAN interface IP yet.
"Private Networks" includes LAN as well as ABPNI (which is another network I wish to keep secure). Also, the PUBLIC tab has the "Private Networks" set to block as the first rule in the list. Also, I should probably mention that WAN and PUBLIC are in a public address space, whilst LAN and ABPNI are in a 2 separate private networks.
I should probably mention that I'm using 2.0 BETA.
I'm having some problems regarding my above setup.
Some rules in the PUBLIC tab are getting ignored to certain destinations. Just to give an example of an extreme case: if the only rule I place on the PUBLIC tab is a "block all", access to the pfsense WAN interface, as well as any other hosts behind any other interface connected to pfsense*, are determined by the rules in the WAN tab. One would assume that a block all rule on the PUBLIC tab would stop the PUBLIC hosts from accessing anything..
What am I doing wrong here?
- This only happens if the hosts on the PUBLIC interface use the pfsense WAN ip as their default gateway.
Update: My problem above seems to be temperamental. Maybe this is a bug in 2.0 BETA? With the only rule on the PUBLIC tab as block all, without even touching pfsense, somehow I can suddenly ping some devices behind other interfaces (Provided access is allowed on the WAN tab). It's as if pfsense is having trouble deducing whether the traffic came from the WAN interface or PUBLIC interface.
2nd Update: I think I have found how I can cause traffic to "leak". If a host on the LAN interface accesses a host on the PUBLIC interface (which is ok), pfsense ignores all rules in the PUBLIC tab for hosts which are behind the LAN interface, as well as the WAN interface address itself.
Shall I file a bug report somewhere? Can someone please verify this?
Folks I've created a new topic in the 2.0 section, as this may be a possible bug related to 2.0.