"Recent posts
#1
General Discussion / Unbound Not showing any cached...
Last post by Meg - Today at 09:13:55 AMI was playing around with my bound minimum and maximum ttl when I noticed at some point I wasn't seeing any cache hits even though running dig proved that i am caching I flushed cache and restarted unbound and opnsense but don't see any cached hits accumulating.
#2
25.7, 25.10 Series / Re: Why can't you host the ISO...
Last post by Stormscape - Today at 08:55:57 AMI don't understand, there's lots of mirrors right on the download page?
#3
25.7, 25.10 Series / Re: ISC DHCP to dnsmasq Migrat...
Last post by Stormscape - Today at 08:52:14 AMDHCP 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?
What do the firewall logs show?
#4
German - Deutsch / Re: Caddy + ACME Client mit HT...
Last post by Monviech (Cedrik) - Today at 08:17:35 AMDeine 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.
Alle Caddy Zertifikate kann man im Trust Store sehen und sie werden auch im Certificates Dashboard Widget angezeigt.
#5
German - Deutsch / Re: Anbindung an die Telematik...
Last post by RES217AIII - Today at 05:02:57 AMQuote from: magicas on December 30, 2025, 02:49:16 PMSo 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.
Quote from: magicas on December 30, 2025, 02:49:16 PMDann 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/
Quote from: magicas on December 30, 2025, 02:49:16 PMsind 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).
#6
General Discussion / Re: Simple Port Forward Failin...
Last post by Patrick M. Hausen - Today at 04:32:31 AMIs 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
Firewall > Settings > Advanced > Disable force gateway
#7
25.7, 25.10 Series / Re: ISC DHCP to dnsmasq Migrat...
Last post by muchacha_grande - Today at 03:55:34 AMHi JusNo1.
I guess it is the firewall rules.
Can you show in detail the NAS rules?
I guess it is the firewall rules.
Can you show in detail the NAS rules?
#8
General Discussion / Re: Simple Port Forward Failin...
Last post by kojak - Today at 02:04:07 AMI 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:
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.
- 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.
#9
25.7, 25.10 Series / ISC DHCP to dnsmasq Migration:...
Last post by JustNo1 - Today at 01:17:40 AMAfter 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
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
#10
General Discussion / Re: Simple Port Forward Failin...
Last post by kojak - December 30, 2025, 11:17:58 PMThank 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:
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:
