Hi All,
I am new to OPN, coming from other FW.
One of the things I am trying to understand is the following:
A) I have installed OPN, 4 interfaces, nothing fancy, WAN, LAN, LAN1, WIFI, so far all ok, I have not changed any default option, yet.
B) Under Firewall -> Rules for each interface I find almost 15 rules created automatically by the system.
C) I have the need to add or change some rules on each interface, but this is what I find:
C1) The automatically generated rules cannot be edited
C2) If add a rule it cannot be moved UP, I mean before the system ones
D) As much as I have search on the documentation and the forum I can't find an explanation on how this should work
E) I read about the OPTION Anti Lock Out. But is this the option that "tell" the system to genarate the automatic rules ?
F) If I disable the AntiLock Out option do I loose the automatically generated rules ? Do they get removed ? Would I be locked out of the system ?
G) How do I edit the auto generated system rules and change the order of my rules in respect to the system ones ?
Thank you for your help,
Giovanni
The automatic rules that have a looking glass at the end are driven by a setting. The looking glass brings you to the setting.
I have not played with the anti-lockout setting myself but it's my understanding that it adds a port no redirect rule and a FW rule on either LAN, or opt1 (or WAN if no other interface exists). AFAIK, if you mess up with this one, the only recourse is via console option 13. This only concerns ports 22, 80 and 443 (likely adjusted if you change the GUI ports). You can roll your own version, at your own risks.
These automatic rules wouldn't be very useful if they were invalidated by rule ordering...
They are designed to maintain basic functionality.
Note that a few of them are last match (grey bolt).
Which ones are getting in your way?
I do not understand what the anti-lockout rule is good for, because it generates not a firewall rule but some obscure NAT setting. If you have a sufficiently broad "allow" rule on LAN you will always be able to access SSH and the UI. If you mess up you mess up.
I have it disabled on all of my firewalls.
The "unchangeable" automatic rules are essential for network operation at a fundamental level and I appreciate that they are even shown which many other enterprise firewall products, even my beloved Sidewinder, just don't. But there's really nothing to change there.
Wrt anti-lockout, there's also a firewall rule on the LAN or opt1 or WAN interface (whichever exists first):
Pass, in, 1st match, IPv4+6 TCP, *, *, (self), 22 80 443, *, *, anti-lockout and looking glass pointing to the setting.
Thanks, I missed that. Still all pretty opaque :) I do not like "magic". I like explicit configuration.
If anything is magic here, it's really the choice of the interface. The rules themselves are pretty simple.
I look at this as a shortcut to rules I'd need anyway, in one form or another...
I don't have as much experience as you do. Guardrails are fine with me.
I'm not happy about the interface that ends up being used (after I deleted LAN as part of work you inspired to get rid of untagged traffic) but I either live with it or take the risk of shooting myself in the foot later.
I didn't understand why OPN picked that interface until I found this: https://forum.opnsense.org/index.php?topic=22640.0 (https://forum.opnsense.org/index.php?topic=22640.0). It might ring a bell 😉
Quote from: Patrick M. Hausen on January 13, 2025, 11:44:35 PM[...]
The "unchangeable" automatic rules are essential for network operation at a fundamental level and I appreciate that they are even shown which many other enterprise firewall products, even my beloved Sidewinder, just don't. But there's really nothing to change there.
I don't like this one hanging out at the top:
"IPv6 IPV6-ICMP * * * * * * *"
I would always have the capability to cover that (or any other Source = * rule) with a block rule. The way it is now, it appears as though someone could always irritate you (assuming you have IPv6 connectivity) by sending unsolicited unreachables that penetrate your firewall.
Just to say thank you for all of your answers, is now more clear to me what those two things are.
Now I am trying to get access via ZeroTier to a box on the LAN, looks like I may need your help again !
Quote from: pfry on January 14, 2025, 04:50:40 AMQuote from: Patrick M. Hausen on January 13, 2025, 11:44:35 PM[...]
The "unchangeable" automatic rules are essential for network operation at a fundamental level and I appreciate that they are even shown which many other enterprise firewall products, even my beloved Sidewinder, just don't. But there's really nothing to change there.
I don't like this one hanging out at the top:
"IPv6 IPV6-ICMP * * * * * * *"
I would always have the capability to cover that (or any other Source = * rule) with a block rule. The way it is now, it appears as though someone could always irritate you (assuming you have IPv6 connectivity) by sending unsolicited unreachables that penetrate your firewall.
I'm not qualified to argue about the details of RFC4890.
This said, it's my understanding that given the size of the IPv6 address space (even at the prefix level, square of the IPv4 space), random spraying is impractical.
Quote from: EricPerl on January 18, 2025, 03:30:09 AMI'm not qualified to argue about the details of RFC4890.
This said, it's my understanding that given the size of the IPv6 address space (even at the prefix level, square of the IPv4 space), random spraying is impractical.
Don't bet on that. But I was thinking mainly of static address space.
Quote from: pfry on January 18, 2025, 09:39:46 AMDon't bet on that. But I was thinking mainly of static address space.
Pro tip:
If you run IPv6 connected statically configured systems, generate the host part your addresses randomly. That's what DNS is for.
Quote from: Patrick M. Hausen on January 18, 2025, 11:50:45 AMPro tip:
If you run IPv6 connected statically configured systems, generate the host part your addresses randomly. That's what DNS is for.
I think y'all are so dynamic client-focused that you're missing my point. Are you suggesting that randomizing a chunk of the address would obscure it when a) it is used as a source when accessing the Internet or b) it is published in DNS? And how would this be superior to a non-random/potentially predictable address when statically configured?
Quote from: pfry on January 18, 2025, 05:26:34 PMI think y'all are so dynamic client-focused that you're missing my point.
Au contraire, mon ami! :-) I am data centre focused.
Quote from: pfry on January 18, 2025, 05:26:34 PMAre you suggesting that randomizing a chunk of the address would obscure it when a) it is used as a source when accessing the Internet or b) it is published in DNS? And how would this be superior to a non-random/potentially predictable address when statically configured?
While it is always possible to perform a targeted attack against my infrastructure, because
- outbound connections showing source
- DNS
- all public certificates are on publicly accessible lists today
randomizing host IP addresses makes it impractical to perform exhaustive scans of the address space. Which is the case with IPv4! The entire legacy internet is scanned 24x7. Since a single /64 is the legacy internet squared (!) in size, randomizing addresses is a reasonable policy.
Compare to assigning addresses like: dead:beef:dead:beef::1, dead:beef:dead:beef::2, dead:beef:dead:beef::3, dead:beef:dead:beef::4 ... you get one, you can begin to scan hosts. So my recommendation with IPv6 is: don't.
Kind regards,
Patrick
Quote from: Patrick M. Hausen on January 18, 2025, 09:57:18 PM[...]
While it is always possible to perform a targeted attack against my infrastructure [...]
Heh. Difference in focus. Nitpickety, weak attack vector though it may be, I'd still provide a mechanism to close it!
This conversation reminded me that I had a pass rule for IPv4 unreachables that would never be matched, so I deleted it. I have several like it, as (to my knowledge) pf (and every other stateful filter/firewall I've ever used) does not fix up unreachables that do not originate from the original destination of a session, and I want to see those (although I can only see them internally and on my static subnet, as they cannot be un-NAT'd dynamically).