Messages

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.

Du schreibst nichts über die Topologie und hast keine Netzmasken erwähnt - ich gehe mal von /24 aus.

Grundsätzlich routet die OpnSense sowieso nicht zwischen dem Server 2 und 3, da beide im selben Netzwerk 10.0.2.0/24 liegen. Die einzige Art, wie der Traffic überhaupt die OpnSense passieren könnte, wäre, wenn die beiden Server an unterschiedlichen Interfaces der OpnSense hängen - diese müssten dann aber gebridged sein, so dass wieder nichts geroutet wird. Das bedeutet insbesondere, dass dort auch keine Firewall-Regeln greifen können.

[und]

1. Deine Outbound NAT Regel müsste UDP und TCP umfassen (SIP kann über beide Protokolle gehen und das tut es bei der Telekom auch). TCP fehlt bei Dir.

2. Du benötigst die Outbound NAT Regel und die Port-Forwarding-Regel(n). Die erste sorgt dafür, dass der SIP-Server des ISP den richtigen Absende-Port sieht (wenn er nicht "static" wäre, wäre das ein zufälliger Port). Die zweite erlaubt eingehende SIP und RTP-Verbindungen.

3. Die Telefonie-Ports der Fritzbox sind (standardmäßig): 5060 für TCP und UDP (SIP) und 7077:7109 UDP (RTP/RTCP). Man findet sie in den Diagnose- und Sicherheitseinstellungen der Fritzbox und auch in den gespeicherten Enstellungen. Der Rest ist Mumpitz. Man kann diese Einstellungen aber auch ändern und ich würde nicht ausschließen, dass sie sich nach den Telefonie-Provider-Einstellungen richten - durch Modifikation der Konfigurationsdatei lassen sie sich auf jeden Fall ändern.
Es gibt in der Konfigurationsdatei beispielsweise noch zwei Angaben: "random_sip_port_enabled = no" und "random_sip_port_range = "20000-30000", bei mir waren die aber immer inaktiv.

4. Viele ISPs machen VoIP auch über IPv6 (Beispiel: M-Net). Wenn das aktiv ist, wird es immer bevorzugt verwendet. Daher helfen dann die IPv4-Einstellungen gar nichts. In diesem Fall muss man entsprechende Firewall-Regeln für den eingehenden SIP- und RTP-Verkehr für IPv6 anlegen. Dazu benötigt man die EUI-64 der Fritzbox und muss einen "Dynamic IPv6 Host"-Alias als Ziel-Host nutzen oder man verwendet stattdessen einen MAC-Alias. Ausgehender IPv6-Traffic ist hoffentlich sowieso erlaubt und es braucht dort auch kein NAT. Das aber nur am Rande, weil es nicht Dein Problem ist.

5. Ich würde anfangs komplett darauf verzichten, die VoIP-Server des ISP als Einschränkung zu verwenden und zunächst "any" als Quelle zuzulassen. Wenn alles funktioniert, kann man das ggf. nachrüsten. Einer der Gründe ist, dass Deine Subnetze in beiden Richtungen nicht stimmen:

a. 217.0.7.0/24 ist in 217.0.0.0/13 vollständig enthalten und daher überflüssig, wie ein Subnetzrechner Dir sagen wird.
b. Bei mir ergibt "nslookup -query=srv _sip._udp.tel.t-online.de":

Code Select Expand

_sip._udp.tel.t-online.de       service = 20 0 5060 nes008-f01-mav-pc-rt-001.edns.t-ipnet.de.
_sip._udp.tel.t-online.de       service = 10 0 5060 kln000-l01-mav-pc-rt-001.edns.t-ipnet.de.
_sip._udp.tel.t-online.de       service = 30 0 5060 hno002-l01-mav-pc-rt-001.edns.t-ipnet.de.

Beispielsweise: "nslookup nes008-f01-mav-pc-rt-001.edns.t-ipnet.de." ergibt 217.0.147.5, was wiederum außerhalb der von Dir zugelassenen Bereiche liegt. Übrigens: _sip._tcp.tel.t-online.de gibt es auch, wie bereits erwähnt!

Wenn man überhaupt so etwas macht, dann über einen ASN-Alias der Telekom. Das lässt dann zwar auch alle Kunden der Telekom zu, stellt aber sicher, dass es immer funktioniert. Bei anderen ISPs kann das nach hinten losgehen, weil die teilweise Dienstleister für VoIP nutzen, die andere Netzbereiche verwenden, dann muss man deren ASN verwenden.

If your ISP uses dynamic IPv6 prefixes (many do), then you can create a "dynamic IPv6 host" alias using the EUI-64 and the interface it is on.

Of course, with dynamic prefixes, you also need a dynamic DNS service that allows you to use an IPv6 address that is using a predefined EUI-64 part. If it can only register the outbound IPv6, it will only see OpnSense's WAN IPv6, so you must be able to mix in the lower 64 bits if the target IP is not OpnSense itself.

Another way to do this is using a reverse proxy like Caddy, HAproxy or NGinx on OpnSense, in which case the dynamic DNS update gets easier, because OpnSense itself is the target, then. When you use that, you do not even have to use IPv6 for your internal web service, plus you do not need a specific firewall rule.

...or else they'll fix that problem! ;-)