OPNsense Forum

Archive => 17.7 Legacy Series => Topic started by: jnm on December 08, 2017, 08:01:57 pm

Title: how to move anti-lockout rules to a bridge interface
Post by: jnm on December 08, 2017, 08:01:57 pm
OPNsense 17.7.9_8-amd64

I asked this on IRC earlier, but didn't get a response after a few hours. I figured rather than keep reposting there, I'd put it here:

If I use a bridge interface (between, say, re1 and ath0_wlan1) to serve my private LAN, how can I replicate the various anti-lockout rules that get automatically created for the LAN interface? I think I've got the actual firewall rules right, but would like to be sure. I for sure would like a little direction about the NAT/port forward rule that gets created. I've created multiple new rules that mimic the behavior of the original anti-lockout rules on the wired interface, but would love to clean it up a little by either removing the original rules or redefining them and removing my additions.

TIA, etc. :)
Title: Re: how to move anti-lockout rules to a bridge interface
Post by: robvh on December 09, 2017, 08:39:30 am
You could use Firewall-Groups to create a group that includes all interfaces with similar access requirements, then apply your rules on the Rules tab that will be created for the group.
Title: Re: how to move anti-lockout rules to a bridge interface
Post by: zeon on January 16, 2018, 12:53:35 pm
Hello,

I faced same problem. Let me explain.
When I do have two local interfaces (vtnet1 and vtnet2) and I need to tight them together (created bridge interface). So the final bridge interface in my scenario has name LAN.
So, Anti-lockout rules are exist on the previously configured LAN interface (was vtnet1).
My question is, how to move Anti-lockout rules off the vtnet1 and put in to the new LAN?
Of course I could create same rules manually, but this just doesn't make a sense.
Let me know if you need any information from my system.
Thank you.
Title: Re: how to move anti-lockout rules to a bridge interface
Post by: mircsicz on January 31, 2018, 10:47:44 am
+1 for me

just installed a new machine yesterday where I added igb1 & igb2 to a bridge and created a new LAN from that.
Title: Re: how to move anti-lockout rules to a bridge interface
Post by: hutiucip on February 01, 2018, 11:44:06 am
+1 :)
Title: Re: how to move anti-lockout rules to a bridge interface
Post by: franco on February 01, 2018, 03:39:32 pm
Hi guys,

There is no easy way to do this without risking opening up otherwise secured configurations. The anti-lockout works on the assumption that there is a physically attached LAN, which is also given full trust in the default config.xml. Each OPT interface does not have this trust and would mean to be sucked into this anti-lockout.

Maybe as a compromise we could make additional anti-lockout interfaces configurable via GUI?

But that could potentially prevent anti-lockout from working correctly in edge cases, defeating its purpose.

Thoughts? :)


Cheers,
Franco
Title: Re: how to move anti-lockout rules to a bridge interface
Post by: hutiucip on February 01, 2018, 05:49:16 pm
Thoughts:

I have the "Management" subnet on a distinct physical interface than my LAN ("CorpLAN"). I speak, and OPNsense listens for HTTP(S), SSH etc only on that particular interface/ IP. I would like to be able to choose one (and maybe only one) interface to be the one the default anti lock-out rule is applied onto. Of course, if for any reason the assignment of given logical interface is made to a special interface, like LAGG, it should be OK - since many times LAGG is made even for a fail-over config sake; I might be locked-out because default lock-out rule does not apply to LAGG, nor interface groups etc., && because the only physical non-LAGG/ non group interface the default A. L-O. rule is applied onto is not physically reachable any more...

I guess this way is much less prone to risks, regarding changing the interface for default lock-out rule: if I care about changing that interface it should be considered that is my responsibility, that I know the implications of changing that "trusted" interface.

Thank you!