Recent posts

#21

25.7, 25.10 Series / Re: Why can't you host the ISO...

Last post by Stormscape - Today at 08:55:57 AM

I don't understand, there's lots of mirrors right on the download page?

#22

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

Last post by Stormscape - Today at 08:52:14 AM

DHCP should be set to authoritative unless there is another DHCP server on the network. It won't fix it, but it should be set anyway so that new devices don't have to be known to get an IP address.
What do the firewall logs show?

#23

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

Last post by Monviech (Cedrik) - Today at 08:17:35 AM

Deine Situation scheint etwas komplexer. Ohne Caddyfile und Beispielen und was erwartet wird kann ich nicht mehr viel helfen.

Alle Caddy Zertifikate kann man im Trust Store sehen und sie werden auch im Certificates Dashboard Widget angezeigt.

#24

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

Last post by RES217AIII - Today at 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).

#25

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

Last post by Patrick M. Hausen - Today at 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

#26

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

Last post by muchacha_grande - Today at 03:55:34 AM

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

#27

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

Last post by kojak - Today at 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.

#28

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

Last post by JustNo1 - Today at 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:]

#29

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:

#30

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?