Passthrough/Transparant Mode Setup - Suggestions on Rules?

[UserSN]

Hello Everyone,

I'm using a DEC2687 - OPNsense box in front of my servers at a NOC. I've set it up to run in transparant/bridge mode as all my machines behind have a static IP configuration that's a web accessible IP. In Opnsense i've create a simple ALLOW ALL rule on my WAN interface & then I configure all my block/pass rules on the BRIDGE adapter but since i've added emerging threats and other IP Block lists, in the dashboard I see a large percentage of the pie graph makes up TOR Exit Nodes (Another block rule I added) & Emerging Threats on currently active processes.

My question:
Should I add global block rules IE: Emerging Threats & TOR Exit Nodes and all other global drop/block lists/rules at the WAN level vs the BRIDGE level, would that improve performance in any way if I block it directly at WAN?

Thank you!

[pfry]

[...]
Should I add global block rules IE: Emerging Threats & TOR Exit Nodes and all other global drop/block lists/rules at the WAN level vs the BRIDGE level, would that improve performance in any way if I block it directly at WAN?

Assuming I follow your question, you can't. That is, if your WAN interface is a member of a bridge, interface-level filters applied to it will not function. I experimented with this a bit (specifically to configure anti-spoofing filters), and on my systems, the bridge sysctls/tuneables (net.link.bridge.pfil_...) had no effect. YMMV, but I wouldn't bet on it. (Fortunately source spoofing appears to be largely gone from the Internet.) For instance, have a look at "Firewall: Diagnostics: Statistics", under the "rules" tab, rules -> filter rules, and expand your WAN pass rule. I'm betting you'll see no evaluations.

You can, of course, tune your filters based on source and destination address. I have a number of source-and-destination-specific filters on my edge bridge in addition to address-agnostic filters. (I use them only to control access, though.)

If your WAN is not a member of a bridge, ignore the above.

[UserSN]

If i'm understanding correctly, adding any FW rules to my [WAN] interface would be useless.

Currently, ISP -> FW [WAN] Port
FW [LAN] Port -> My Switch

[BRIDGE] just connects the [WAN] -> [BRIDGE] (all my fw rules here) -> [LAN] -> switch.

From your reply I gather my current config is correct and that moving my block rules from [BRIDGE] to [WAN] won't work or bring any benefits?

[Patrick M. Hausen]

This depends on whether you have either

Code Select Expand

net.link.bridge.pfil_bridge=1
net.link.bridge.pfil_member=0

or

Code Select Expand

net.link.bridge.pfil_bridge=0
net.link.bridge.pfil_member=1


[pfry]

This depends on whether you have either [...]

Heh. As I've said, in my experience they have no effect. I'd guess that the new bridge code (by Kristof Provost, who also appears to maintain the pf port) hooks the interface before pf. I haven't bothered to dig through the code, as it's not likely an easy issue to patch. Of course, I'd always recommend setting the sysctls/tunables appropriately to avoid wackiness if the behavior is ever changed/corrected. UserSN's "pass all" rule should be safe in any case. (If I was even more paranoid than I am I'd configure a pass rule on each bridge member interface with logging enabled and a... distinguishable description.)

[...]
From your reply I gather my current config is correct and that moving my block rules from [BRIDGE] to [WAN] won't work or bring any benefits?

Yup, unless you remove WAN from the bridge and configure alternative forwarding (e.g. proxy ARP). Feel free to try it, but if your current WAN rule shows no evaluations in the stats, it's not likely to work.

In my case I was purely testing, so I had only one test machine behind the firewall (no operational risk). I set up a few different pass rule schemes on the bridge and member interfaces, with no block rules. Basically, for bridge/member: pass all/pass all, pass all/pass specific, pass all/none, pass specific/pass all, none/pass all. The only rules that functioned were those on the bridge, regardless of the "net.link.bridge.pfil_*" sysctl settings. I rebooted and verified them from the console after each change. To be clear, though, I did not attempt to characterize the operation of the default floating rules, and I may not have been comprehensive in the rule variations vs sysctls (my patience is limited, and my purpose was to test combinations that I would actually use).

The only real disadvantage of the bridge from a rule standpoint is that you cannot configure a rule based purely on input interface (e.g. my earlier example of an anti-source-spoof rule). I can't think of any other limitations offhand.

[UserSN]

Thanks for the input & feedback!