Recent posts

#91

German - Deutsch / Re: Anbindung an die Telematik...

Last post by RES217AIII - December 31, 2025, 05:02:57 AM

So wie ich das verstanden habe hast du vorher im LAN einen "echten" Konnektor gehabt und nun auf einen HK (Highspeedkonnektor) per VPN gewechselt.

Nach Auslaufen der Zertifikatsgültigkeit der Einbox- Konnektoren, was von Konnektor zu Konnektor unterschiedlich ist, erfolgt eine Neuanbindung an die TI derzeit nur noch per TI Gateway per VPN.

Dann drängt sich mir als erstes auf, hast du die "alten" routen auf den jeweiligen Geräten Mac´s gelöscht ?
und dann die neuen gesetzt?

Die Routen sind spätestestens zum Zeitpunkt der Umstellung auf den Clients zu löschen und entsprechende Routen in der Firewall zu setzen.
Auch wenn Du nicht Tomedo nutzt, stellt Zollsoft eine Liste zur Verfügung:
https://support.tomedo.de/handbuch/tomedo/telematikinfrastruktur-ti/ports-und-routen-fuer-die-ti/

sind die Ports entsprechend angelegt worden? siehe PDF

Auch wenn ich den Link nicht öffne, nehme ich an, dass dort eine Aufstellung zu finden ist, welche ausgehenden Ports freigegeben sein sollen. Da es sich bei der OPNsense um eine statefull Firewall handelt, müssen keine ausgehenden Ports definiert werden. Antwortpakete von aussen werden zugelassen, wenn sie zu dem gesetzten "state" passen.
Die jedoch zu definierende NAT Regel ist eine outbond Regel zur Maskierung auf eine dem TI-Konnektor bekannte IP (lokale Tunnel IP, die in der Konfiguration vorgegeben ist).

P.s. IPsec Ports müssen auf der WAN Schnittstelle natürlich erlaubt sein als Grundvoraussetzung damit IPsec überhaupt funktionieren kann.

#92

General Discussion / Re: Simple Port Forward Failin...

Last post by Patrick M. Hausen - December 31, 2025, 04:32:31 AM

Is the external client connected directly to your WAN network instead of "somewhere on the Internet"? If yes, by default OPNsense will send outbound packets from WAN to the WAN gateway and not to the client. To change this set:

Firewall > Settings > Advanced > Disable force gateway

#93

25.7, 25.10 Series / Re: ISC DHCP to dnsmasq Migrat...

Last post by muchacha_grande - December 31, 2025, 03:55:34 AM

Hi JusNo1.
I guess it is the firewall rules.
Can you show in detail the NAS rules?

#94

General Discussion / Re: Simple Port Forward Failin...

Last post by kojak - December 31, 2025, 02:04:07 AM

I discovered that Opnsense offers a packet capture feature directly within its user interface. I performed captures on both my WAN and MGMT interfaces simultaneously, allowing me to trace the packet flow through the NAT, WAN, and MGMT interfaces. In this capture, I am able to observe:

• The incoming SYN packet from the HTTP client at 10.10.20.44 hitting the external IP of the OpnSense firewall 10.10.20.50
• The NAT translating 10.10.20.50:8080 into an internal address of 10.0.0.14:8080
• The internal client, 10.0.0.14, receiving and sending a SYN ACK to 10.10.20.44
• The NAT appears to be converting the internal IP, 10.0.0.14, back to the external IP, 10.10.20.50, in the 4th packet.
• Lots of retries after this...

It looks like the NAT is doing its thing correctly but it is hard to say whether that 4th packet is _actually_ leaving the Opnsense router and egressing onto the 10.10.20.x network.  I am certain that the client is not receiving it because I've run packet captures there as well.

#95

25.7, 25.10 Series / ISC DHCP to dnsmasq Migration:...

Last post by JustNo1 - December 31, 2025, 01:17:40 AM

After migrating from ISC DHCP to dnsmasq DHCP on my OPNsense firewall, my NAS VLAN (10.32.13.0/24) stopped having internet access. Devices receive IP addresses from dnsmasq but cannot reach the gateway (10.32.13.1) or external addresses like 8.8.8.8. Interestingly, this only affects the NAS VLAN – my WLAN and other VLANs continue to work fine with dnsmasq. Before the migration, internet access worked on all VLANs.

Current Configuration (NAS VLAN):

dnsmasq DHCP Range Settings:
Interface: NAS
Start Address: 10.32.13.2
End Address: 10.32.13.6
Subnet Mask: automatic
Mode: Nothing selected
Lease Time: 86400
Domain: (empty)

dnsmasq Global Settings (relevant):

Interface [no DHCP]: Nothing selected
DHCP FQDN: ✅ Enabled
DHCP local domain: ✅ Enabled
DHCP authoritative: ❌ Disabled
Router advertisements: ❌ Disabled
DHCP register firewall rules: ✅ Enabled

Firewall Rules (NAS):

IPv4 → NAS address (Zugriff NAS)
IPv6 → ! RFC4193_Networks (IPv6 Internet)
IPv4 → ! RFC1918_Networks (IPv4 Internet)

Comparison with Working VLAN (WLAN):

The WLAN VLAN works perfectly with dnsmasq and has these settings:
Start Address: 10.32.11.3
End Address: 10.32.11.62
Subnet Mask: 255.255.255.192

Firewall Rules: Similar structure with internet access enabled

Troubleshooting Performed:
✅ Firewall rules exist for internet access
✅ Devices receive IP addresses (DHCP works)
❌ Ping to gateway 10.32.13.1: 100% packet loss
❌ Ping to 8.8.8.8: 100% packet loss
✅ Devices can ping each other within the VLAN
✅ NAS VLAN interface and VLAN configuration unchanged since migration
✅ Other VLANs with dnsmasq work fine

Observations:

The issue appears to be DHCP-related (ISC DHCP worked, dnsmasq doesn't for this VLAN)
Gateway/Router and DNS Server options are not explicitly set in the dnsmasq DHCP range configuration
DHCP authoritative is enabled – could be causing conflicts
Subnet mask is set to 255.255.255.248 (/29)

Questions:

Why does this only affect special VLANs while most work fine?
Any help would be greatly appreciated. I can provide additional screenshots or configuration details if needed.

System Info:

OPNsense 25.7.10
Multiple VLANs (NAS, WLAN, Banking, DNS, etc.)
Migrated from ISC DHCP + Router Advertisement to dnsmasq

Edit: Nameserver and interface address (both 10.32.13.1) getting recognised by the Clients

[Packet Trace on the HTTP Server:]

#96

General Discussion / Re: Simple Port Forward Failin...

Last post by kojak - December 30, 2025, 11:17:58 PM

Thank you for the suggestions, but I still haven't had any success. I updated the port forwarding rule to be more specific, as you recommended, and set the destination to "WAN net." I also discovered the useful "Linked rule" feature, which automatically created a non-editable rule in the WAN FW's ruleset.

I also tried broadening the WAN and MGMT rules to allow all TCP traffic in every direction (note the disabled rules), but this didn't resolve the issue. As you suggested, I set up a packet sniffer on the HTTP server and observed traffic reaching the server, 10.0.0.14. The server is responding to the client, 10.10.20.28; however, it appears OpnSense is blocking the replies, since both the client and server are repeatedly attempting retransmissions.

Packet Trace on the HTTP Server:


The NAT with a destination set:


WAN with disabled permissive rules (the MGMT network looks the same).  These permissive rules did not work:

#97

German - Deutsch / Re: Caddy + ACME Client mit HT...

Last post by viragomann - December 30, 2025, 10:51:57 PM

Caddy braucht kein Acme Client Plugin, es macht Acme selber mit einem eingebauten client (certmagic).

Gelesen hatte ich den Absatz, so verstanden aber nicht. :-/

/well-known wird reserviert, aber wenn du z.B. http domains reverse proxiest, werden alle Pfade durchgereicht. Hier ein beispiel:
https://docs.opnsense.org/manual/how-tos/caddy.html#redirect-acme-http-01-challenge

Eben genau dieses hätte ich gedacht, müsste konfiguriert werden, damit Caddy die HTTP-01 Challenge durchreicht. Und daher hatte ich angenommen, dass er es sonst nicht tut.

Im Grunde benötigt man eigendlich /nie/ das http frontend

Ich nutze jedoch HTTP, bspw.  für Audio-Streams. Muss ich dann nur diese Domains für HTTP konfigurieren und http-Anfragen auf andere Domains werden automatisch auf https umgeleitet?

Das Acme sh script plugin (Also os-acme-client) benutzt PF Anchors um einen upper port in der firewall zu öffnen und darüber die challenge zu machen. Das ist ein anderer mechanismus. Die HTTP01 challenge kann auch über einen anderen port als 80 erfolgen.

Ja, so etwas hatte ich schon vermutet. Jedoch zeigte pcap Port 80 Zugriffe von LE, weswegen ich angenommen hatte, dass Caddy diese handeln müsste.

Ich denke hier werden ein paar Konzepte miteinander vermischt und das ergibt Verwunderung.

Und die hält immer noch an...

Ich muss also ins kalte Wasser springen, auch sämtliche https Domains auf Coddy einrichten und dann schauen, was passiert.

Werden die Zertifikate von Coddy eigentlich auch im Trust Store von OPNsense abgelegt, so dass man dies auch verifizieren kann?

#98

German - Deutsch / Re: Caddy + ACME Client mit HT...

Last post by Monviech (Cedrik) - December 30, 2025, 09:33:49 PM

Caddy braucht kein Acme Client Plugin, es macht Acme selber mit einem eingebauten client (certmagic). Das benötigt port 80 und 443 offen auf WAN mit target This Firewall. Caddy kann mit mehreren challenge typen Zertifikate erlangen (je nach Konfiguration 3 verschiedene Challenges zu 2 default ACME Providern).

/well-known wird reserviert, aber wenn du z.B. http domains reverse proxiest, werden alle Pfade durchgereicht. Hier ein beispiel:

https://docs.opnsense.org/manual/how-tos/caddy.html#redirect-acme-http-01-challenge

https://github.com/opnsense/plugins/blob/d3cbedaa8e405a72fc8317d0b4d4aed9c96a63c3/www/caddy/src/opnsense/service/templates/OPNsense/Caddy/Caddyfile#L268

Das oben zeigt ganz klar was passieren würde wenn man einen handle / auf eine http domain setzt, auch der http01 pfad wird nach hinten durchgereicht. Da wird für die selbe Domain nichts reserviert.

Im Grunde benötigt man eigendlich /nie/ das http frontend, mit dem https frontend pro domain macht Caddy schon eine automatische weiterleitung und reserviert sich /well-known/.... für sich selbst.

-------

Das Acme sh script plugin (Also os-acme-client) benutzt PF Anchors um einen upper port in der firewall zu öffnen und darüber die challenge zu machen. Das ist ein anderer mechanismus. Die HTTP01 challenge kann auch über einen anderen port als 80 erfolgen.

Ich denke hier werden ein paar Konzepte miteinander vermischt und das ergibt Verwunderung.

#99

German - Deutsch / Re: Caddy + ACME Client mit HT...

Last post by viragomann - December 30, 2025, 08:53:16 PM

Es gab nun einen Erfolg.

Ich hatte das ACME Client Plugin nicht aktiviert gehabt. Ich hatte gedacht, dass dies für den Testmodus nicht nötig wäre. Ich hatte ACME schon auf zwei anderen OPNsense Instanzen eingerichtet, doch hier wohl erstmalig die Test CA verwendet, was auch gut war. :-/
Muss sagen, das Fehlerbild dieser Misskonfiguration ist aber ziemlich seltsam. Warum da Let's Encrypt keine Antwort bekommt, eine andere Quelle aber schon...?
Und warum der ACME-Client dennoch Let's Encrypt kontaktiert hatte?

Dann hatte ich in meiner Verzweiflung noch für den letzten Test einen Reverse-Proxy Handler mit meinem Backend-Webserver hinzugefügt. Damit hatte ACME auch nicht funktioniert. Ich musste ihn wieder entfernen.
Warum eigentlich? Sollte Caddy nicht den "/.well-known/acme-challenge/" Pfad automatisch umleiten?

#100

25.7, 25.10 Series / Re: Unbound DNS Questions

Last post by spetrillo - December 30, 2025, 08:22:01 PM

One thing I did see between two servers on the same subnet.

If you run resolvectl status on one server it returns the following:

Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (ens160)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.0.3.1
       DNS Servers: 10.0.3.1
        DNS Domain: regulatoryintelligence.com rics.prod

If you run it on the second server it returns the following:

Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (ens33)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.0.2.1
       DNS Servers: 10.0.2.1
        DNS Domain: rics.prod regulatoryintelligence.com

As an additional question why is the domain order different between these servers?