Messages

Tuning for the sake of tuning is never a great idea.

Tunables should be touched only in case to fix some particular problem or to achieve some specific goal.

Regards,
S.

This. I only adjusted a few settings, with a specific reason. I get full theoretical LAN and routing speed after TCP/IP overhead, and with a 2G symmetrical WAN link. Trying to optimize further would just invite problems with no additional gain.

Some of those setting violate certain RFCs, and others could break intended behavior or make performance worse depending on circumstances.  I would make sure to only adjust what you know will bring your environment value.

I do not invert destination on v4 or v6 on the DNAT or the firewall rule. I'm not sure why you would need to?
I invert the source on DNAT v4/v6 to exclude the unbound server and other systems that need to be able to communicate to other DNS servers.

Can the OPNSense affected also if hacker got access to LAN?

Internal Firewall rules with separate zones/interfaces for Wifi/Client/DMZ/Core/etc. Would advise using VLANs if you can, otherwise subneting with /24s is a good idea.

From what I've read, you might also want to turn on MAC-Address filters on your WAPs and/or OPNSense's DHCP, good luck!

I have MAC filtering enabled. NO SSH and open ports. How to create VLAN or subnetting?

That's a little more involved than a forum post (IMO anyway).  I would suggest reading through google, or maybe even asking an AI model for starting steps.
It is absolutely a wifi and configuration issue though.  OPNsense wont automatically protect you if someone can connect to your wifi, join your main LAN, and then communicate directly with the rest of your LAN devices on the same LAN/VLAN/subnet.  The MAC address filtering won't help much, as if it is happening in the way you described they can just spoof the MAC address they got from session they sniffed anyway.

Also, move to WPA3 if able. I understand you likely have legacy devices that do not support it though, so its not as easy as said.
See if you can enable PMF (Protected Management Frames): Enable 802.11w or Protected Management Frames (PMF) in your router settings to prevent attackers from deauthenticating your devices to force a re-handshake.  While not full proof, it does lower the attack vector.  Once again though, everything you have may not support it, so you will need to see what if anything breaks.

Edit: realistically, if that is the attack method, you have an extremely weak wifi password as well.  Upgrade to  a nice long random password.

[both]

That is what I meant: Sure, it causes no immediate conflicts, iff the MACs are different. However, you must set the aliases on both sides in advance, not just one. Otherwise, a fail-over would null the existing settings.

Yeah you would want to make sure they all are set on all servers.

I can't find anything official on how it should handle "blank" subnets, but the method right now is it will parse any lists that are blank in addition to any other policy it did match on.  I agree if nothing else, it should be a feature request.

Ok, so it doesn't really cascade.  If I understood you, it matches the policy with the most specific source and then, having failed to match a blocklist item there, it falls immediately to the 'default' policy.

As far as forcing the route though the GUA to get there, you would have needed to add a firewall rule to allow that behavior, otherwise it wouldn't route. DNS is also not a security feature. They can also just type the IP in directly, add it their local hosts file,  or many other various methods

Right, let me clarify my question.

If I do configure ULAs they would be in addition to GUAs because I don't want to have to use NAT with IPv6.  What I recall is that clients choose GUAs before ULAs and in most cases the ULA address won't ever be used.

If Unbound is listening on a ULA, then does the client automatically choose its ULA as well to reach Unbound?  Or does it still try the GUA route?

I don't think I'd be able to control it from the client side (?), so I would have to assume that any client could try to reach Unbound from any of its configured IPs.  In that case I again have the problem that dynamic prefix GUAs would need to be handled by a default (catch-all) policy in Unbound which would break the 'localhost' policies.

I guess I could use firewall blocks to enforce it, but not sure I like that.  It seems like it would cause delays.

If a host has both IPv6 ULA and GUA addresses, internal communication will typically prefer ULA.  RFC 6724 address selection favors source/destination pairs with matching labels. When both endpoints have ULA addresses, the stack selects ULA→ULA instead of GUA→GUA or mixed pairs, which keeps internal traffic on the stable local addressing scheme.

In my environment all devices have a ULA and GUA and all DNS requests always come from the ULA address.  A quick search of the firewall and DNS logs do not show any attempts from the GUA address even.

I looked into the scripts a bit and my initial impression is that it doesn't process policy-by-policy at all.

Instead, I think it checks if the domain being queried is in the compiled blocklist (a big hashmap of all of the blocked domains across all the policies).  If the domain is blocked anywhere, then it loops through each of the policies associated with the blocked domain and checks if the client IP is within any of the source net(s) defined.  An empty source net value ([]) is considered as an automatic match for any IP.

So I think I agree that a 'quick' match option is useful.  I've added a feature request: https://github.com/opnsense/core/issues/9890

There we go, I think you explained it more elegantly than I managed to! :D  Feature request is a good idea, because I think it would be more useful that way as well.

You can force the interface name by using device hints.

Edit device.hints from the shell and edit (or create) the file /boot/device.hints
Add entries to bind the MAC address to a specific device name.
Example: To make a specific Intel card (igb0) always be lan0:
hint.igb.0.mac="00:11:22:33:44:55"
hint.igb.0.name="lan0"

This will keep the interface names identical between your boxes.

ooookay this is sick. Thanks for the tip!

I know the answer, but.... Why This is not a thing directly in the GUI? :)

Regards,
S.

I just realize you should be able to add these from the Tunables section of the GUI as well as new entries, which would probably be a better idea here anyway. :)

The documentation indicates "the algorithm selects the most specific subnet when domains overlap across subnet sizes."  This is true, if you have 10.0.0.0/24 and 10.0.0.5 for example, it will only match on 10.0.0.5 and not 10.0.0.0.  The main issue there is no default that says "if nothing applies, use this list".  Leaving it blank applies to all policies.  So 10.0.0.5 and the blank one would both apply, but not 10.0.0.0/24.
I can't find anything official on how it should handle "blank" subnets, but the method right now is it will parse any lists that are blank in addition to any other policy it did match on.  I agree if nothing else, it should be a feature request.

As far as forcing the route though the GUA to get there, you would have needed to add a firewall rule to allow that behavior, otherwise it wouldn't route. DNS is also not a security feature. They can also just type the IP in directly, add it their local hosts file,  or many other various methods

The DNS requests from your local LAN should always come from the LL or ULA address, which should be static prefixes.  Does each portion need separate blocks?  2 policies should it otherwise, you can add multiple subnets to each policy, you just can't mix v4 and v6 right now.

You will need to add a subnet to your clients-all policy.
For example, 192.168.1.0/24 (and your IPv6 subnet on a separate cloned policy) ; Now that list will apply to everything on that subnet and your localhost policies will work to not block from localhost.
If you leave it as blank, it will be evaluated regardless on top of your other policies.  You essentially saying this policy is for EVERYTHING by leaving it blank.

For what it is worth, I think it should work the way you assumed it would, but it does not. :)

Port range needs to be specified with "-" and not ":" so you would use 4500-65535

Can I do this somehow?

You can create a restricted administrator account and deny access to the the old Rules section (and anything else you don't use in your environment) to clean up the menu, and use that account.

You can force the interface name by using device hints.

Edit device.hints from the shell and edit (or create) the file /boot/device.hints
Add entries to bind the MAC address to a specific device name.
Example: To make a specific Intel card (igb0) always be lan0:
hint.igb.0.mac="00:11:22:33:44:55"
hint.igb.0.name="lan0"

This will keep the interface names identical between your boxes.