Messages

The problem is / was probably present before. If you use DNS names for wireguard peers, then the daemon will only resolve them once on start and never recognizes if the peer's IP changes. There is a cron job "Renew DNS for Wireguard on stale connections" which will restart Wireguard. You can run that job every 5 minutes and it will probably fix the DNS resolution problem during startup, too (at least after 5 minutes).

This has been reported over an over, so now I appended it as point 30 here: https://forum.opnsense.org/index.php?topic=42985.0

Firewall aliases are meant to be used with pf rules. pf acts on IPs and subnets. So what should a DNS "domain" mean in that context?

It is not even a specific hostname within a domain, which could at least be resolved to an IP (or a set of IPs).

You can use domains in DNSBL lists to block DNS resolution of specific names, but that is another concept that has nothing to do with firewall rules (and aliases).

Wenn Du individuelle Interface-Regeln brauchst, dann musst Du sie entweder im Interface oder in den Floating Rules machen.

Die Priorität ist ja in der offiziellen Dokumentation erläutert. Floating Regeln sind ganz vorne, dann kommen Interface Gruppen, dann Interfaces.

Entsprechend muss man die Regeln auch positionieren. In den Floating Rules kommt das, was mehr oder weniger für alle gilt - übrigens kann man dort auch Interface Gruppen verwenden.

Wenn Dir das zu unübersichtlich ist, kannst Du auch alle Regeln in den Floating Rules belassen, dann übersiehst Du nichts.

I have to access the WAN net because I'm behind another NAT unfortunately. Should The Admin Aliases to Firewall be placed in the Floating, or are they best left specifically for the Admin VLAN rules?

If they are really VLAN-specific, they do not need to be in the floating rules. As I said, I put everything there that I need to have for many VLANs or things that must override inbound NAT rules. Those with "pass" rules are evaluated before any interface-specific rules, so they must be done in the floating rules. As an example, when you want geoblocking on WAN, you may have to do that in the floating rules, because otherwise, your forwarded ports will not be protected.

IDK, but I doubt it. Did you install the microcode updates?

ASPM is your smallest problem. That is neither the first nor the only thing in point 23. You need to use the os-microcode-intel plugin and the tuneables from the linked posting in point 23 with your Alder Lake CPU.

You also do not need to add anything to any files, just use the web UI to enter the tuneables and reboot afterwards.

There are lots of problems with those rules.

First, you have to ask yourself what you want to achieve by separating out a guest VLAN.

Usually, this is used to protect your "valuable assets" in your main LAN from anyone who may just use your internet connection. In order to do this, you should have rules in place to protect your LAN from the guest VLAN.

Your rules show an attempt to further regulate the traffic originating from your guest network. This is debatable at best and your rules do not provide that, either. The way you currently do it would keep most guests from browsing anything at all, because current browsers use DoT on port 853, which you do not allow. On the other hand, because you allow port 443, anybody could use DNS via DoH, so you do not block external DNS requests effectively.

Before I go on to show what is wrong with your rules, I tell you what mine are:

1. I have floating rules to allow traffic that I need to allow basic network functions for all local networks - that includes the guest VLAN.
Those would be DNS (53/UDP) and NTP (123/UDP). I also allow access to specific resources there, like a printer on my IoT VLAN.

2. In the VLAN-specific rules, I have one rule to allow any to any, like the default LAN rule. This will allow guest clients to access anything on the internet. Why? Frankly, because you cannot effectively regulate traffic, there anyway. The only thing you have to do there is a block rule to an alias "RFC1918", which has to be placed before the "allow any" rule, in order to keep guests from accessing your local networks.

That is about it.


Now for your rules:

- Allow DHCP Port 67/UDP: This rule is unneccesary AFAIR, because that is allowed in the "Automatically generated rules" already. Delete it.
- Allow DNS Port 53: Only needed with UDP and should beplace in floating rules for all local network interfaces. Move it there.
- Block External DNS Port 53: Why would you? These days, browsers mostly do DoT or DoH, anyway. As long as you do not block that, either, this is fruitless. If you want to block it: This is very complex and frankly, at your current level, you would not succeed in doing it. Leave it be, delete the rule.
- Block access to firewall management: Since this rule comes before the next rules, it would block anything after it, like "Allow NTP", so it is misplaced. If at all, you should move it further down in the list. Then again, it is not needed at all, because there already is an implicit "block all" rule at the end of the list. Rule of thumb: order matters! Delete it.
- Block access to private/internal networks. Yes, keep it.
- Allow Inbound Connection Ports 80-443: Problem here is, you allow not only ports 80 and 443 ofr HTTP and HTTPS, but anything in between, including NTP (123) and many others. If you really want ports 80 and 443 only, you need either two rules or a "Port" alias for web traffic consisting of port 80 and 443. I would say, delete the rule and replace it by an "allow any" rule.
- Allow Outbound traffic Port 443-80: You never need to have a firewall rule for outbound directions (with only a few exceptions), even less so for an existing inbound rule. The responses to allowed traffic are always allowed. Delete it.
- Allow NTP Port 123: Move the rule to floating.
 

As long as Kea DHCPv6 is not active for an interface, it is neither shown nor selectable in the interface filter of the "leases" display.

SLAAC is never shown at all, because those are no leases - the clients decide for themselves, which suffix they use. You would see SLAAC assigments in the NDP table only. If you ever had DHCPv6 leases, they will show up for a long time after they have been handed out, though.

Why wouldn't they? They want (some actually need) the party to go on.

Using an Intel CPU? See this, point 23.

This is not an official answer, only my observations:

1. I never saw any updates for older CE branches after the next release has come out, so I guess, if you do not apply the latest updates, you potentially risk to have unfixed vulnerabilities.

2. Deciso offers the business edition for exactly the purpose you aim at. It is usually 3 months behind the community edition feature-wise (i.e. it has ripened a little), but is updated for vulnerabilities regularly. This version is the one to use if you want production quality. The CE version is free, but you have to be able to cope with problems induced by feature upgrades that come along with new releases. Short story is: YOu can use the CE version for free if you volunteer for testing it - otherwise, buy the business license.

3. Since the "major" updates for CE come out twice a year with YY.1 in January and YY.7 in July, they tend to have more new features in them. The minor updates that follow (e.g. YY.7.x) usually have less new features included - which is not to say that they cannot break.
If you can cope with not always having the "latest" and greatest, you should probably skip YY.X.0 versions or at least wait a few days after a release has been announced to see if there were neccessary fixes (YY.X.Z_n).

[is]

i am not using this product.  but i did sign up for it.  i stayed with Opnsense Business edition geoblocking

anyways.  my lite account says unlimited requests using the API access.

seems weird they would be blocking all of a sudden?

Look again.

Their API handles single IP queries and is unlimited, indeed.
The download of their database is limited as indicated by the error message.

It works just fine for me and there is a very simple explanation that hides behind this log line:

Code Select Expand

2025-12-05T11:42:13    Error    firewall    geoip update failed : You have reached your 10 downloads per day limit for ipinfo_lite.csv.gz from [ip.ad.dr.ess] Please reach out to increase your limit via support@ipinfo.io. [http_code: 429]

Ipinfo has a daily download limit that you have exceeded, probably because you use the same token on multiple OpnSense instances.

Ich verstehe offen gesagt nicht, wieso Du so pikiert reagierst. Du hast anfangs nicht genau gesagt, was Du eigentlich tust. Ich schrieb Dir dann, dass Deine Frage, wie der Switch das Routing zwischen Server 2 und 3 übernehmen kann mit "gar nicht" beantwortet werden muss, weil beide im selben VLAN liegen und somit kein Routing erfolgt.

Danach sagtest Du, dass Du den Switch nutzen willst, um direkt zwischen dem VLAN für den Mac und dem für die Server zu routen und habe lediglich gefragt, wozu Du dann die OpnSense noch benötigst. Das primär deswegen, weil die OpnSense dann eben genau bislang wirksame Netztrennung der VLANs nicht mehr gewährleistet - so langsam das aktuell auch sein mag. Ein solcher Hinweis ist doch wohl legitim, wenn Du selbst sagst, dass Du kein Netzwerkprofi bist.

Finde ich auch schade, aber ich nehme wahr, dass Du offenbar keine weiteren Hinweise mehr möchtest.

Frage: Welchen Sinn hat eine Netztrennung und eine Firewall, wenn dann der Traffic über einen Layer3-Switch daran vorbei geleitet wird?

Offenbar sind es ja nicht so viele Geräte, dass die Auftrennung in unterschiedliche ARP-Domains das Ziel ist.