OPNsense Forum
Archive => 17.7 Legacy Series => Topic started 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. :)
-
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.
-
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.
-
+1 for me
just installed a new machine yesterday where I added igb1 & igb2 to a bridge and created a new LAN from that.
-
+1 :)
-
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
-
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!