"Recent posts
#1
26.7 Series / Re: [26.7] UPnP/NAT-PMP leaks ...
Last post by Mann-IT - Today at 12:45:45 PMHI,
Mostly servers/VMs, all ZeroTier members. Thanks for the hint, but we'll stay with UPnP for now:
- With PCP/NAT-PMP off the problem is gone: the anchor stays at ~23 rules (= leases), no stalls, 0.3 ms jitter.
- UPnP IGD deletes its rules correctly. Only the NAT-PMP path leaks.
- Static port/EIM outbound NAT would remove the anchor, but gives no measurable gain at 23 rules,
and changes NAT behaviour for every host on a multi-tenant box.
- Once miniupnpd gets 463ec13 we simply re-enable NAT-PMP.
Grretings Mario
Mostly servers/VMs, all ZeroTier members. Thanks for the hint, but we'll stay with UPnP for now:
- With PCP/NAT-PMP off the problem is gone: the anchor stays at ~23 rules (= leases), no stalls, 0.3 ms jitter.
- UPnP IGD deletes its rules correctly. Only the NAT-PMP path leaks.
- Static port/EIM outbound NAT would remove the anchor, but gives no measurable gain at 23 rules,
and changes NAT behaviour for every host on a multi-tenant box.
- Once miniupnpd gets 463ec13 we simply re-enable NAT-PMP.
Grretings Mario
#2
Development and Code Review / Freeradius VLAN fallback curre...
Last post by cguareschi - Today at 12:31:59 PMI am not sure if this is the right place to post this.
In the current implementation of freeradius there is a big problem with VLAN fallback if freeradius is used for both MAC Based Authentication and other authentication methods like EAP-TLS that requires further handshake.
The problem with the current implementation is that when Fallback VLAN is enabled,
the generated FreeRADIUS users file contains:
DEFAULT Auth-Type := Accept
This fallback rule is not restricted to MAC authentication and can therefore
interfere with other authentication methods handled by the same FreeRADIUS
instance.
In particular, Auth-Type := Accept can prevent EAP authentication from
proceeding through its normal handshake.
The solution is a one-liner change in the freeradius user template.
Restrict the fallback rule to MAC authentication using the RADIUS
Service-Type = Call-Check semantic:
DEFAULT Service-Type == Call-Check, Auth-Type := Accept
This preserves the existing fallback behavior for MAC authentication while
preventing the fallback rule from matching unrelated authentication methods.
RFC 5080, section 2.1.1, specifically addresses this use case:
"Implementing MAC address checking without using a Service-Type of
Call Check is NOT RECOMMENDED."
https://www.rfc-editor.org/rfc/rfc5080.html#section-2.1.1
Tested with Fallback VLAN enabled:
Unknown MAC authentication -> fallback VLAN
Known MAC authentication -> configured VLAN
EAP-TLS -> authenticates normally
Captive portal authentication -> authenticates normally
I submitted an issue and a pull request to help with this quite some time ago but it still unanswered.
I was wondering if the freeradius maintainer or anybody else that can help hangs here and could kindly review this.
I think this would be useful to many.
Cheers
Claudio
PS the issue is:https://github.com/opnsense/plugins/issues/5734
In the current implementation of freeradius there is a big problem with VLAN fallback if freeradius is used for both MAC Based Authentication and other authentication methods like EAP-TLS that requires further handshake.
The problem with the current implementation is that when Fallback VLAN is enabled,
the generated FreeRADIUS users file contains:
DEFAULT Auth-Type := Accept
This fallback rule is not restricted to MAC authentication and can therefore
interfere with other authentication methods handled by the same FreeRADIUS
instance.
In particular, Auth-Type := Accept can prevent EAP authentication from
proceeding through its normal handshake.
The solution is a one-liner change in the freeradius user template.
Restrict the fallback rule to MAC authentication using the RADIUS
Service-Type = Call-Check semantic:
DEFAULT Service-Type == Call-Check, Auth-Type := Accept
This preserves the existing fallback behavior for MAC authentication while
preventing the fallback rule from matching unrelated authentication methods.
RFC 5080, section 2.1.1, specifically addresses this use case:
"Implementing MAC address checking without using a Service-Type of
Call Check is NOT RECOMMENDED."
https://www.rfc-editor.org/rfc/rfc5080.html#section-2.1.1
Tested with Fallback VLAN enabled:
Unknown MAC authentication -> fallback VLAN
Known MAC authentication -> configured VLAN
EAP-TLS -> authenticates normally
Captive portal authentication -> authenticates normally
I submitted an issue and a pull request to help with this quite some time ago but it still unanswered.
I was wondering if the freeradius maintainer or anybody else that can help hangs here and could kindly review this.
I think this would be useful to many.
Cheers
Claudio
PS the issue is:https://github.com/opnsense/plugins/issues/5734
#3
German - Deutsch / Certalys – eigentlich wollte i...
Last post by Certalys - Today at 10:50:49 AMHallo zusammen,
ich bin Meik, arbeite seit vielen Jahren in der IT und möchte euch ein Projekt vorstellen, dessen Anfang ziemlich unspektakulär war.
Eigentlich wollte ich nur ein kleines Tool, mit dem ich einen Client bequem zwischen zwei OPNsense-Aliasen wechseln kann: einmal über die VPN-Verbindung, einmal über den normalen Internetzugang. Möglichst ohne dafür jedes Mal die Weboberfläche der Firewall öffnen zu müssen.
Aus diesem ,,eigentlich nur" ist inzwischen etwas mehr geworden. Das Projekt heißt heute Certalys.
Während der Arbeit daran hat mich zunehmend eine andere Frage beschäftigt: Wie bekomme ich einen verständlichen Überblick darüber, was in meiner Infrastruktur passiert und wie die einzelnen Systeme zusammenhängen? Mich interessierte nicht nur, ob irgendwo eine Anzeige rot wird, sondern was konkret betroffen ist und wo ich sinnvoll mit der Fehlersuche anfangen sollte.
Diese Frage ist heute der Kern von Certalys. Es ist eine eigenständige Windows-Anwendung für Monitoring und Analyse über mehrere Plattformen hinweg. OPNsense war der Ausgangspunkt und der erste integrierte Provider. Inzwischen sind auch Unraid, Proxmox VE und Proxmox Backup Server angebunden und praktisch getestet.
Ein wichtiger Unterschied zur ursprünglichen Alias-Idee: Das heutige Monitoring arbeitet read-only gegenüber den überwachten Systemen. Certalys ändert keine Firewall-Regeln und führt keine automatischen Reparaturen aus.
Neben den Sensoren gibt es eine CMDB, die bestätigte Beziehungen grafisch darstellt. Beispielsweise lässt sich nachvollziehen, dass ein NAS einen bestimmten DNS-Dienst oder ein Gateway nutzt. Die regelbasierte Analysis ordnet Zustände und vorhandene Belege ein; im Requires attention wird zusammengefasst, was passiert ist, was betroffen sein könnte und welcher nächste Prüfschritt sinnvoll ist.
Dazu kommen Benachrichtigungen über SMTP, Pushover, Slack und PagerDuty. Neu sind außerdem Benutzerverwaltung mit Rollen und 2FA sowie ein verschlüsseltes Backup und Restore der Certalys-Anwendungsdaten.
Mir ist wichtig, dass Monitoring und Analyse ohne Cloud-Dienst funktionieren. Externe Benachrichtigungen sind eine bewusst eingerichtete Option, keine Voraussetzung. Bei der Entwicklung nutze ich KI-Unterstützung; praktische Tests und die schrittweise Überprüfung der Funktionen gehören fest dazu.
Certalys ist weiterhin in Entwicklung, noch keine Final 1.0. Als nächster Provider ist XCP-ng vorgesehen. Später sollen unter anderem TrueNAS, Windows-Server- und Linux-Server-Agenten sowie Switches und Netzwerkdrucker folgen. Dafür möchte ich keine Termine versprechen, die sich am Ende nicht halten lassen.
Was mich daran motiviert, ist der Spaß, aus einem konkreten eigenen Bedarf etwas Nützliches zu entwickeln. Wenn das später auch anderen die tägliche Arbeit erleichtert, würde mich das freuen.
You cannot view this attachment.
Mich würde interessieren: Welche OPNsense-Zustände oder Zusammenhänge fehlen euch in einer übergreifenden Übersicht? Und wo würdet ihr bei meinem Ansatz genauer nachfragen?
Etwas Hintergrund zum Projekt habe ich auf https://certalys.com zusammengestellt. Certalys ist mein eigenes, unabhängiges Projekt und keine offizielle OPNsense-Erweiterung.
Viele Grüße
Meik
ich bin Meik, arbeite seit vielen Jahren in der IT und möchte euch ein Projekt vorstellen, dessen Anfang ziemlich unspektakulär war.
Eigentlich wollte ich nur ein kleines Tool, mit dem ich einen Client bequem zwischen zwei OPNsense-Aliasen wechseln kann: einmal über die VPN-Verbindung, einmal über den normalen Internetzugang. Möglichst ohne dafür jedes Mal die Weboberfläche der Firewall öffnen zu müssen.
Aus diesem ,,eigentlich nur" ist inzwischen etwas mehr geworden. Das Projekt heißt heute Certalys.
Während der Arbeit daran hat mich zunehmend eine andere Frage beschäftigt: Wie bekomme ich einen verständlichen Überblick darüber, was in meiner Infrastruktur passiert und wie die einzelnen Systeme zusammenhängen? Mich interessierte nicht nur, ob irgendwo eine Anzeige rot wird, sondern was konkret betroffen ist und wo ich sinnvoll mit der Fehlersuche anfangen sollte.
Diese Frage ist heute der Kern von Certalys. Es ist eine eigenständige Windows-Anwendung für Monitoring und Analyse über mehrere Plattformen hinweg. OPNsense war der Ausgangspunkt und der erste integrierte Provider. Inzwischen sind auch Unraid, Proxmox VE und Proxmox Backup Server angebunden und praktisch getestet.
Ein wichtiger Unterschied zur ursprünglichen Alias-Idee: Das heutige Monitoring arbeitet read-only gegenüber den überwachten Systemen. Certalys ändert keine Firewall-Regeln und führt keine automatischen Reparaturen aus.
Neben den Sensoren gibt es eine CMDB, die bestätigte Beziehungen grafisch darstellt. Beispielsweise lässt sich nachvollziehen, dass ein NAS einen bestimmten DNS-Dienst oder ein Gateway nutzt. Die regelbasierte Analysis ordnet Zustände und vorhandene Belege ein; im Requires attention wird zusammengefasst, was passiert ist, was betroffen sein könnte und welcher nächste Prüfschritt sinnvoll ist.
Dazu kommen Benachrichtigungen über SMTP, Pushover, Slack und PagerDuty. Neu sind außerdem Benutzerverwaltung mit Rollen und 2FA sowie ein verschlüsseltes Backup und Restore der Certalys-Anwendungsdaten.
Mir ist wichtig, dass Monitoring und Analyse ohne Cloud-Dienst funktionieren. Externe Benachrichtigungen sind eine bewusst eingerichtete Option, keine Voraussetzung. Bei der Entwicklung nutze ich KI-Unterstützung; praktische Tests und die schrittweise Überprüfung der Funktionen gehören fest dazu.
Certalys ist weiterhin in Entwicklung, noch keine Final 1.0. Als nächster Provider ist XCP-ng vorgesehen. Später sollen unter anderem TrueNAS, Windows-Server- und Linux-Server-Agenten sowie Switches und Netzwerkdrucker folgen. Dafür möchte ich keine Termine versprechen, die sich am Ende nicht halten lassen.
Was mich daran motiviert, ist der Spaß, aus einem konkreten eigenen Bedarf etwas Nützliches zu entwickeln. Wenn das später auch anderen die tägliche Arbeit erleichtert, würde mich das freuen.
You cannot view this attachment.
Mich würde interessieren: Welche OPNsense-Zustände oder Zusammenhänge fehlen euch in einer übergreifenden Übersicht? Und wo würdet ihr bei meinem Ansatz genauer nachfragen?
Etwas Hintergrund zum Projekt habe ich auf https://certalys.com zusammengestellt. Certalys ist mein eigenes, unabhängiges Projekt und keine offizielle OPNsense-Erweiterung.
Viele Grüße
Meik
#4
General Discussion / Re: Free GeoIP Database to use...
Last post by Tonton Jo - Today at 09:36:45 AMQuote from: Patrick M. Hausen on October 16, 2026, 10:25:43 PMThey are providing a database that could be used by the builtin functionality. As an alternative to Maxmind or IPinfo.
Not sure if this is a permitted use of Internet registry info, though.
Hi!
Thanks for you concern and sadly you looks to be right.
Will take this down.
Regards.
#5
26.1, 26,4 Series / Re: os-ndp-proxy says it is fo...
Last post by Monviech (Cedrik) - Today at 08:10:44 AMThe NDP proxy is primarily designed for on-link IPv6 prefixes advertised via Router Advertisements (SLAAC).
If you receive all your prefixes through DHCPv6 Prefix Delegation, the proxy cannot do much for your setup. It only learns and manages addresses within prefixes advertised by the upstream router via RA.
DHCPv6-PD prefixes should already be routed to your firewall by your ISP, without requiring NDP proxying.
https://docs.opnsense.org/manual/ndp-proxy-go.html#example-setup
If its really something weird with your Comcast modem, recently I added a prefix responder mode to the proxy where it can respond to any prefix you tell it, but unknown if it helps you. That feature is available in the current community version.
https://github.com/Monviech/ndp-proxy-go/blob/d4a0c05f20af2463644e5d7b39484f0584d89204/README.md?plain=1#L136
With the latest ndp proxy version the command line launch would probably look like this in your case:
If you receive all your prefixes through DHCPv6 Prefix Delegation, the proxy cannot do much for your setup. It only learns and manages addresses within prefixes advertised by the upstream router via RA.
DHCPv6-PD prefixes should already be routed to your firewall by your ISP, without requiring NDP proxying.
https://docs.opnsense.org/manual/ndp-proxy-go.html#example-setup
If its really something weird with your Comcast modem, recently I added a prefix responder mode to the proxy where it can respond to any prefix you tell it, but unknown if it helps you. That feature is available in the current community version.
https://github.com/Monviech/ndp-proxy-go/blob/d4a0c05f20af2463644e5d7b39484f0584d89204/README.md?plain=1#L136
With the latest ndp proxy version the command line launch would probably look like this in your case:
Code Select
ndp-proxy-go \
--respond-prefix \
--static-prefix 2603:XXXX:XXXX:XX60::/59 \
--static-prefix 2603:XXXX:XXXX:XXe0::/59 \
--static-prefix 2603:XXXX:XXXX:XX20::/59 \
--no-ra \
--no-routes \
--debug \
igb0
#6
26.7 Series / Re: Internet Connectivity Issu...
Last post by (MARLOO) - Today at 05:16:56 AMthis is most likely related to PF rule reloading or the gateway/default route becoming invalid after an alias change.
check
netstat -rn | grep default
pfctl -si
pfctl -sr | head -50
cat /var/log/filter/latest.log
if the default route is missing, disable and re-enable the affected gateway under System → Gateways, then apply changes
Quote from: ajaydharwa on October 16, 2026, 07:10:27 AMIs there a recommended way to troubleshoot and resolve this issue without restarting the firewall?
check
netstat -rn | grep default
pfctl -si
pfctl -sr | head -50
cat /var/log/filter/latest.log
if the default route is missing, disable and re-enable the affected gateway under System → Gateways, then apply changes
#7
Zenarmor (Sensei) / Re: App Control Definition Upd...
Last post by nutty_net - Today at 04:46:23 AMQuote from: sy on October 16, 2026, 01:01:23 PM...Please note that our updates are not limited to adding or removing apps; we are also continuously enhancing existing applications by updating hostnames and IP addresses.
Ohhh, good point and good to know!
Quote from: sy on October 16, 2026, 01:01:23 PM...I will share your feedback with the product team to ensure better visibility in the future.
Thanks!
#8
Zenarmor (Sensei) / Re: How to block Firefox VPN
Last post by nutty_net - Today at 04:43:59 AMThanks Seimus. In re-reading, I think I misunderstood: I thought the custom app function itself was broken.
#9
Zenarmor (Sensei) / Re: How to block Firefox VPN
Last post by Seimus - Today at 02:17:10 AMAt least for my Custom apps I am not aware currently of any FIX.
ZA support and DEV team is aware but currently its in the backlog. They are trying to find a slot to put on active work.
Regards,
S.
ZA support and DEV team is aware but currently its in the backlog. They are trying to find a slot to put on active work.
Regards,
S.
#10
26.1, 26,4 Series / os-ndp-proxy says it is forwar...
Last post by really_lost - Today at 01:58:19 AMIs there a firewall setting that may need tweaking to get ndp-proxy NA's to go through? They aren't making it to the upstream interface, and I think that will solve my issue.
I'm certain I'm doing something wrong. I'm also certain this is as much a Comcast/XFinity issue as it is an OPNsense one.
I'm using OPNsense 26.4.2p3. I have a Comcast Business class with static IPs. I have a /29 for ipv4 and a /56 for ipv6. Comcast will only permit me to request prefix delegations no larger than /59. Packet captures show if I request multiple /59 PD's, Comcast says I have them.
However, only ipv6 /64's in the firstly requested /59 fully route.
For those that fail, remote packet captures show the packets making it to my Comcast modem and failing.
Packet captures on my OPNsense box's WAN interface, show Comcast sending a neighbor solicitation packet and not getting a reply. NOTE: for anything in the first PD requested, Comcast does not send NS requests. It just sends the packets to OPNsense.
After frequent attempts to set this up and knocking parts of my family's internet out, I am just trying on one isolated test system.
I tried setting up os-ndp-proxy-go to have Comcast as the upstream interface and the downstream interface as the one connected to my test system as the downstream.
In that setup, via packet captures on OPNsense, I see Comcast send an NS to my WAN. I see OPNsense send an NS to my test system. I see my test VM send a Neighbor Advertisement. I do not see an NA go out my WAN interface.
NDP Proxy debug logs say that it is forwarding the NA to the upstream.
Custom WAN dhcpv6.conf:
NDP Proxy settings:
You cannot view this attachment.
NDP Proxy log saying it is forwarding the NA:
You cannot view this attachment.
I'm certain I'm doing something wrong. I'm also certain this is as much a Comcast/XFinity issue as it is an OPNsense one.
I'm using OPNsense 26.4.2p3. I have a Comcast Business class with static IPs. I have a /29 for ipv4 and a /56 for ipv6. Comcast will only permit me to request prefix delegations no larger than /59. Packet captures show if I request multiple /59 PD's, Comcast says I have them.
However, only ipv6 /64's in the firstly requested /59 fully route.
For those that fail, remote packet captures show the packets making it to my Comcast modem and failing.
Packet captures on my OPNsense box's WAN interface, show Comcast sending a neighbor solicitation packet and not getting a reply. NOTE: for anything in the first PD requested, Comcast does not send NS requests. It just sends the packets to OPNsense.
After frequent attempts to set this up and knocking parts of my family's internet out, I am just trying on one isolated test system.
I tried setting up os-ndp-proxy-go to have Comcast as the upstream interface and the downstream interface as the one connected to my test system as the downstream.
In that setup, via packet captures on OPNsense, I see Comcast send an NS to my WAN. I see OPNsense send an NS to my test system. I see my test VM send a Neighbor Advertisement. I do not see an NA go out my WAN interface.
NDP Proxy debug logs say that it is forwarding the NA to the upstream.
Custom WAN dhcpv6.conf:
Code Select
interface igb0 {
send ia-na 0;
send ia-pd 0;
send ia-pd 1;
send ia-pd 2;
request domain-name-servers;
request domain-name;
script "/var/etc/dhcp6c_wan_script.sh";
};
id-assoc na 0 {
};
id-assoc pd 0 {
prefix 2603:XXXX:XXXX:XX60::/59 infinity;
prefix-interface igb2 {
sla-id 26;
sla-len 5;
ifid 1;
};
prefix-interface igb1 {
sla-id 0;
sla-len 5;
};
prefix-interface igb3 {
sla-id 30;
sla-len 5;
};
};
id-assoc pd 1 {
prefix 2603:XXXX:XXXX:XXe0::/59 infinity;
prefix-interface ix2 {
sla-id 1;
sla-len 5;
};
};
id-assoc pd 2 {
prefix 2603:XXXX:XXXX:XX20::/59 infinity;
};NDP Proxy settings:
You cannot view this attachment.
NDP Proxy log saying it is forwarding the NA:
You cannot view this attachment.
