Recent posts

#1

General Discussion / Re: Packet received by interfa...

Last post by lmoore - Today at 01:38:20 AM

The packet in question is under interface 2 and it repeats 4 times

The node at 192.168.4.27 is broadcasting the reply. For the packet to flow through pf in OPNsense, the MAC address would need to be unicast and forwarded to a8:b8:e0:04:91:1b

#2

Tutorials and FAQs / Re: IPv6 on OPNsense with Veri...

Last post by gadgetguy - May 30, 2026, 11:35:42 PM

While OPNsense has the necessary dhcp6c code path to allow your FiOS WAN interface IPv6 configuration to have both a link local (fe80:: prefix) and a global IPv6 address, it will not configure it that way by default (as of OPNsense 26.1.4 in March 2026).

You will need to also configure a custom dhcp6c client configuration file in [Interfaces->WAN->DHCPv6 Client Configuration, then select Override Configuration Mode] 

Thanks for this.  It has gotten me closer to getting a global address from FiOS, but I still don't receive it.  The only log entry that appears to be related is a series of these which I had not seen before:

Sending Solicit on igb0


They have been occuring at ever increasing intervals (20 secs, 30 secs, 1 min., 5 min., etc.)

Any hints as to what might be going on or where to check for more details?

#3

Virtual private networks / Policy routing with WireGuard ...

Last post by Hexodark - May 30, 2026, 11:09:07 PM

Hi,
I've been struggling with a persistent policy routing issue on OPNsense 26.1 using WireGuard and I'm hoping someone has found a reliable solution.
Setup:
OPNsense 26.1 on a mini PC
WireGuard ProtonVPN France (wg0) with gateway GW_fr
Two LAN firewall rules routing specific aliases (domains + IPs) through GW_fr
NAT outbound configured for wg0
Gateway monitoring enabled with 8.8.8.8 as monitor IP
Gateway shows Online consistently
Problem:
Traffic randomly stops going through WireGuard and falls back to WAN, without any changes made. The WireGuard tunnel stays connected (wg show shows recent handshake), the gateway stays Online, but the traffic exits through WAN instead of wg0.
Running configctl filter reload && configctl filter sync fixes it temporarily, but it comes back after some time.
Important detail:
This happens without any IP changes or configuration changes. The tunnel is up, the gateway is online, but the routing just stops working randomly. This suggests it's purely a state table issue — existing states are somehow using the wrong gateway.
What I've tried:
Enabled "Kill states when down" on gateway
Added cron script every 5 minutes to detect and reload rules
Cleared state table manually (fixes it temporarily)
Questions:
Is there a way to force OPNsense to always re-evaluate the gateway for new connections even when a state exists?
Is there a known fix for this in 26.1?
Would OpenVPN be more stable than WireGuard for policy routing?
Any help appreciated. Thanks!

#4

26.1, 26,4 Series / Re: Intermittent upload collap...

Last post by dare - May 30, 2026, 10:04:57 PM

Hello and sorry for double posting.

so I've heard back from protectli support and they say no one else has this problem and that they have actually tested it and they cannot reproduce the problem.
I've gone back to 25.7 in the meantime and the problem persisted, but less frequently. It was the same on a basic Asus router I tried next.

So then I had weeks of back and forth with my ISP's support, who weren't very helpful. Finally they said they have "updated my modem". The problem seems to have stopped since and I have done a clean reinstall of 26.1.

Needles to say this has been a very very weird episode and the only thing I can really say is that opnsense and protectli are not at fault. The drivers on 26.1 might be different so the ISP problem might have been more apparent on 26.1. Or something.

#5

General Discussion / Re: Packet received by interfa...

Last post by Somnolus - May 30, 2026, 09:42:48 PM

I have 2 devices that need to establish communication between eachother.  each device is on its own network, but connected to the same router.  These are separate physical connections, no VLANs are involved.  The machine is a intel N305 router with 6 2.5gb ports using the intel i226-v chipset.  The machine is running proxmox with 5 of the 6 ports directly passed through to opnsense.  Both devices are on ports directly passed through to opnsense.

Device 1 is on network 10.0.0.0/24, Device 2 is on 192.168.4.0/24.  Both machines have been given static IP's via KeaDHCP.
Machine 1 is set to ip 10.0.0.55, machine 2 is assigned ip 192.168.4.27

Machine 1 is a server that handles file sharing, Machine 2 is a system that requests the files.  Communication occurs over 2 ports.  Port 62966 and 62967.  Machine 2 broadcasts a multicast request over port 62966 that hits the router and runs through UDP-Broadcast-Relay which makes its way to machine 1.  machine one than responds to machine 2 letting it know its IP and the port to use for data transfer.  Everything works as it should both machines see each other just fine and all communication passes normally.  the problem is when machine 2 sends a UDP packet requesting data from machine 1.  That packet hits the router interface but doesn't seem to go anywhere beyond that.  I've enabled firewall logging for everything including NAT rules under the advances settings. I don't have captive portal, or ipsec enabled.
I've attached packet captures that were run directly inside opnsense.  The packet in question is under interface 2 and it repeats 4 times.

#6

German - Deutsch / Re: "Lahmes" Internet seit Upd...

Last post by cottec - May 30, 2026, 08:38:29 PM

Vielleicht das Interface selbst mal aus dem Legacy-Mode holen?

Ist das denn so falsch?
Ich scheine ja per DHCP auf dem WAN Adressen zu kriegen...
Hätte eh keine Ahnung wie ich sonst v6 einrichte um ehrlich zu sein...

#7

German - Deutsch / Re: Umgang mit VLAN

Last post by s.meier68 - May 30, 2026, 08:30:47 PM

Einen managebaren Switch beschaffen. Dort ein LAN (VLAN 1) und GAST (VLAN x) anlegen (oder eventuell weitere). OpnSense und alle APs (wichtig: VLAN-fähig) werden auf Trunk-Ports geschaltet, die Endgeräte je nach Vertrauensstellung auf VLAN 1 oder x.

Ich empfehle, wenn es KEIN Rack-Switch werden soll, den Zyxel XGS 1250-10. 8 1G Ports, 3 10G Ports und ein SFP+. Auf dem Switch lässt sich hervorragend OpenWRT installieren. (Du brauchst leider einmalig ein UART 3.3V Kabel) Dazu dann z.B. ein oder mehrere Zyxel NWA50pro (auf dem lässt sich auch OpenWRT installieren) So hast Du für die Netzwerktechnik eine Oberfläche die sich z.B. auch mit opensoho managen lässt.

Bei Mir macht die Fritzbox ebenso noch Telefonie, alles andere nicht mehr.

Auf den APs werden pro VLAN jeweils SSIDs angelegt mit unterschiedlichen Passworten. Somit kann man bei

WLAN-Clients durch Auswahl der SSID bestimmen, was sie dürfen.

Und Du kannst z.B. auch für IoT Geräte nur ein 2.4Ghz Wlan aufspannen, Client Seperation nutzen oder andere Verschlüsselungseinstellungen....


ich würde statt Kea allerdings dnsmasq empfelen. Durch die DNS Integration erspart man sich einiges an Konfigurationsaufwand. Auch ipv6 ist problemlos möglich.

Netzwerk-Clients, bei denen der Switch das zugewiesene VLAN ausgangsseitig entfernt und eingangsseitig hinzufügt (sogenannter "Tagged"-Port).

Das ist allerdings ein untagged Port. Dieser ist bei einem vLAN-fähigen Switch trotzdem einem vLAN zugehörig.
Ein Tagged Port ist eine andere Bezeichnung für einen Trunk-Port. Das ist Herstellerabhängig wie der genannt wird.
Ein TrunkPort ist ein Tagged-Port der ein oder mehrere vLANs enthält.

Wie Du deine Endgeräte (dazu gehört die Opnsense letztendlich auch) konfigurierst, hängt davon ab wie der Port auf dem Switch konfiguriert ist. Ein kurzes Beispiel. Wenn der Port auf dem Switch untagged ist, kannst Du das mit dem Port verbundene Interface der Opnsense ganz normal wie sonst auch konfigurieren. Du musst auf dem jeweiligen Endgerät nichts beachten.

Ein mit EINEM vLAN getaggter Port  auf dem Switch führt dazu dass Du auf dem Endgerät das eine vLAN konfigurieren musst. Das geht in der Opnsense, aber auch unter Linux und Windows. Macht man in der Regel so nicht, findet sich aber manchmal bei VOIP-Telefonen, dass ein einzelnes vLAN für die Netzkonfiguration vorrausgesetzt wird.

Ein Trunkport ist für alle vLANs konfiguriert, die an diesem Port ankommen und aus diesem Port ausgehend raus gehen sollen. Das wird z.B. genutzt um einem AP mehrere vLANs für mehrere SSID's bereitzustellen. Du kannst aber auch alle vLANs (die Du konfigurierst) mittels eines Trunkports an die Opnsense (oder auch ein Windows, Linux etc Device) übergeben. Dazu musst Du dann auf dem Interface der Opnsense, welches physikalisch mit dem Trunkport verbunden ist, logische vLAN-Interfaces erstellen.

Hier finde ich das auch sehr gut erklärt: https://www.thomas-krenn.com/de/wiki/VLAN_Grundlagen

#8

German - Deutsch / OPNsense verschluckt sporadisc...

Last post by markus.tobatz - May 30, 2026, 07:37:36 PM

Ich betreibe OPNsense 26.1.8 als VM auf einem Proxmox-Cluster. Ich nutze Proxmox SDN zur VXLAN-Separierung, aber jedes VXLAN nutzt zum Routing die OPNsense als Gateway. Die VXLANs sind als separate NIC der VM zugewiesen. Dahinter hängt u.a. ein Reverse Proxy und entsprechende Backend-Webserver. Auf dem Cluster ist aktuell noch sehr wenig los (vllt. 10-20 Web-Requests pro Minute). Mein Monitoring zeigt absolut keine Engpässe im Netz, I/O, RAM oder CPU.

Dennoch habe ich das Phänomen, dass sporadisch mal ein Request ins Leere läuft und der NGINX Reverse Proxy ein "Upstream timed out" liefert. Ich suche seit 2 Tagen, finde aber nichts. Ich habe hier ein paar TCP-Dumps:

Auszug vom Reverse Proxy (VXLAN 100) an den Backend-Webserver:

Code Select Expand

18:50:17.421126 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421142 ens18 Out IP 10.100.100.11.40762 > 10.130.130.22.80: Flags [S], seq 4016571385, win 65500, options [mss 1310,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421156 ens18 Out IP 10.100.100.11.40772 > 10.130.130.22.80: Flags [S], seq 3007325831, win 65500, options [mss 1310,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.422313 ens18 In  IP 10.130.130.22.80 > 10.100.100.11.40772: Flags [S.], seq 346040899, ack 3007325832, win 64900, options [mss 1250,sackOK,TS val 517535345 ecr 2156708648,nop,wscale 7], length 0
18:50:17.422313 ens18 In  IP 10.130.130.22.80 > 10.100.100.11.40762: Flags [S.], seq 3084255561, ack 4016571386, win 64900, options [mss 1250,sackOK,TS val 517535345 ecr 2156708648,nop,wscale 7], length 0
18:50:17.443384 ens18 Out IP 10.100.100.11.40784 > 10.130.130.22.80: Flags [S], seq 562223358, win 65500, options [mss 1310,sackOK,TS val 2156708670 ecr 0,nop,wscale 7], length 0
18:50:17.443661 ens18 In  IP 10.130.130.22.80 > 10.100.100.11.40784: Flags [S.], seq 3423290674, ack 562223359, win 64900, options [mss 1250,sackOK,TS val 517535367 ecr 2156708670,nop,wscale 7], length 0
18:50:17.467279 ens18 Out IP 10.100.100.11.40788 > 10.130.130.22.80: Flags [S], seq 2628846409, win 65500, options [mss 1310,sackOK,TS val 2156708694 ecr 0,nop,wscale 7], length 0
18:50:17.467319 ens18 Out IP 10.100.100.11.40796 > 10.130.130.22.80: Flags [S], seq 3915422948, win 65500, options [mss 1310,sackOK,TS val 2156708694 ecr 0,nop,wscale 7], length 0
18:50:17.467991 ens18 In  IP 10.130.130.22.80 > 10.100.100.11.40788: Flags [S.], seq 1676106060, ack 2628846410, win 64900, options [mss 1250,sackOK,TS val 517535391 ecr 2156708694,nop,wscale 7], length 0
18:50:17.468006 ens18 In  IP 10.130.130.22.80 > 10.100.100.11.40796: Flags [S.], seq 3056575451, ack 3915422949, win 64900, options [mss 1250,sackOK,TS val 517535391 ecr 2156708694,nop,wscale 7], length 0
18:50:18.445100 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156709672 ecr 0,nop,wscale 7], length 0
18:50:19.469188 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156710696 ecr 0,nop,wscale 7], length 0
18:50:20.493198 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156711720 ecr 0,nop,wscale 7], length 0
18:50:21.517175 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156712744 ecr 0,nop,wscale 7], length 0
18:50:22.541211 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156713768 ecr 0,nop,wscale 7], length 0
18:50:24.557198 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156715784 ecr 0,nop,wscale 7], length 0
18:50:28.589203 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156719816 ecr 0,nop,wscale 7], length 0
18:50:29.280604 ens18 Out IP 10.100.100.11.53162 > 10.130.130.22.80: Flags [S], seq 1555195113, win 65500, options [mss 1310,sackOK,TS val 2156720507 ecr 0,nop,wscale 7], length 0
18:50:29.282278 ens18 In  IP 10.130.130.22.80 > 10.100.100.11.53162: Flags [S.], seq 1424688371, ack 1555195114, win 64900, options [mss 1250,sackOK,TS val 517547205 ecr 2156720507,nop,wscale 7], length 0
18:50:36.781185 ens18 Out IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156728008 ecr 0,nop,wscale 7], length 0
Auszug vom Backend-Webserver (VXLAN 130):

Code Select Expand

18:50:17.421666 ens18 In  IP 10.100.100.11.40762 > 10.130.130.22.80: Flags [S], seq 4016571385, win 65500, options [mss 1250,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421667 ens18 In  IP 10.100.100.11.40772 > 10.130.130.22.80: Flags [S], seq 3007325831, win 65500, options [mss 1250,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421686 ens18 Out IP 10.130.130.22.80 > 10.100.100.11.40762: Flags [S.], seq 3084255561, ack 4016571386, win 64900, options [mss 1310,sackOK,TS val 517535345 ecr 2156708648,nop,wscale 7], length 0
18:50:17.421698 ens18 Out IP 10.130.130.22.80 > 10.100.100.11.40772: Flags [S.], seq 346040899, ack 3007325832, win 64900, options [mss 1310,sackOK,TS val 517535345 ecr 2156708648,nop,wscale 7], length 0
18:50:17.443620 ens18 In  IP 10.100.100.11.40784 > 10.130.130.22.80: Flags [S], seq 562223358, win 65500, options [mss 1250,sackOK,TS val 2156708670 ecr 0,nop,wscale 7], length 0
18:50:17.443627 ens18 Out IP 10.130.130.22.80 > 10.100.100.11.40784: Flags [S.], seq 3423290674, ack 562223359, win 64900, options [mss 1310,sackOK,TS val 517535367 ecr 2156708670,nop,wscale 7], length 0
18:50:17.467778 ens18 In  IP 10.100.100.11.40796 > 10.130.130.22.80: Flags [S], seq 3915422948, win 65500, options [mss 1250,sackOK,TS val 2156708694 ecr 0,nop,wscale 7], length 0
18:50:17.467778 ens18 In  IP 10.100.100.11.40788 > 10.130.130.22.80: Flags [S], seq 2628846409, win 65500, options [mss 1250,sackOK,TS val 2156708694 ecr 0,nop,wscale 7], length 0
18:50:17.467783 ens18 Out IP 10.130.130.22.80 > 10.100.100.11.40796: Flags [S.], seq 3056575451, ack 3915422949, win 64900, options [mss 1310,sackOK,TS val 517535391 ecr 2156708694,nop,wscale 7], length 0
18:50:17.467789 ens18 Out IP 10.130.130.22.80 > 10.100.100.11.40788: Flags [S.], seq 1676106060, ack 2628846410, win 64900, options [mss 1310,sackOK,TS val 517535391 ecr 2156708694,nop,wscale 7], length 0
Auszug der OPNsense auf dem eingehenden Interface (VTNET3) vom Proxy:

Code Select Expand

18:50:17.421192 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421195 IP 10.100.100.11.40762 > 10.130.130.22.80: Flags [S], seq 4016571385, win 65500, options [mss 1310,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421221 IP 10.100.100.11.40772 > 10.130.130.22.80: Flags [S], seq 3007325831, win 65500, options [mss 1310,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421614 IP 10.130.130.22.80 > 10.100.100.11.40772: Flags [S.], seq 346040899, ack 3007325832, win 64900, options [mss 1250,sackOK,TS val 517535345 ecr 2156708648,nop,wscale 7], length 0
18:50:17.421732 IP 10.130.130.22.80 > 10.100.100.11.40762: Flags [S.], seq 3084255561, ack 4016571386, win 64900, options [mss 1250,sackOK,TS val 517535345 ecr 2156708648,nop,wscale 7], length 0
18:50:17.443290 IP 10.100.100.11.40784 > 10.130.130.22.80: Flags [S], seq 562223358, win 65500, options [mss 1310,sackOK,TS val 2156708670 ecr 0,nop,wscale 7], length 0
18:50:17.443518 IP 10.130.130.22.80 > 10.100.100.11.40784: Flags [S.], seq 3423290674, ack 562223359, win 64900, options [mss 1250,sackOK,TS val 517535367 ecr 2156708670,nop,wscale 7], length 0
18:50:17.467166 IP 10.100.100.11.40788 > 10.130.130.22.80: Flags [S], seq 2628846409, win 65500, options [mss 1310,sackOK,TS val 2156708694 ecr 0,nop,wscale 7], length 0
18:50:17.467203 IP 10.100.100.11.40796 > 10.130.130.22.80: Flags [S], seq 3915422948, win 65500, options [mss 1310,sackOK,TS val 2156708694 ecr 0,nop,wscale 7], length 0
18:50:17.467844 IP 10.130.130.22.80 > 10.100.100.11.40796: Flags [S.], seq 3056575451, ack 3915422949, win 64900, options [mss 1250,sackOK,TS val 517535391 ecr 2156708694,nop,wscale 7], length 0
18:50:17.467853 IP 10.130.130.22.80 > 10.100.100.11.40788: Flags [S.], seq 1676106060, ack 2628846410, win 64900, options [mss 1250,sackOK,TS val 517535391 ecr 2156708694,nop,wscale 7], length 0
18:50:18.445247 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156709672 ecr 0,nop,wscale 7], length 0
18:50:19.469327 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156710696 ecr 0,nop,wscale 7], length 0
18:50:20.493431 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156711720 ecr 0,nop,wscale 7], length 0
18:50:21.517424 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156712744 ecr 0,nop,wscale 7], length 0
18:50:22.541471 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156713768 ecr 0,nop,wscale 7], length 0
18:50:24.557380 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156715784 ecr 0,nop,wscale 7], length 0
18:50:28.589278 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156719816 ecr 0,nop,wscale 7], length 0
18:50:36.781171 IP 10.100.100.11.40758 > 10.130.130.22.80: Flags [S], seq 928532187, win 65500, options [mss 1310,sackOK,TS val 2156728008 ecr 0,nop,wscale 7], length 0
Sowie auf dem ausgehenden Interface (VTNET6) der OPNsense Richtung Backend-Server:

Code Select Expand

18:50:17.421218 IP 10.100.100.11.40762 > 10.130.130.22.80: Flags [S], seq 4016571385, win 65500, options [mss 1250,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421225 IP 10.100.100.11.40772 > 10.130.130.22.80: Flags [S], seq 3007325831, win 65500, options [mss 1250,sackOK,TS val 2156708648 ecr 0,nop,wscale 7], length 0
18:50:17.421599 IP 10.130.130.22.80 > 10.100.100.11.40772: Flags [S.], seq 346040899, ack 3007325832, win 64900, options [mss 1310,sackOK,TS val 517535345 ecr 2156708648,nop,wscale 7], length 0
18:50:17.421729 IP 10.130.130.22.80 > 10.100.100.11.40762: Flags [S.], seq 3084255561, ack 4016571386, win 64900, options [mss 1310,sackOK,TS val 517535345 ecr 2156708648,nop,wscale 7], length 0
18:50:17.443307 IP 10.100.100.11.40784 > 10.130.130.22.80: Flags [S], seq 562223358, win 65500, options [mss 1250,sackOK,TS val 2156708670 ecr 0,nop,wscale 7], length 0
18:50:17.443514 IP 10.130.130.22.80 > 10.100.100.11.40784: Flags [S.], seq 3423290674, ack 562223359, win 64900, options [mss 1310,sackOK,TS val 517535367 ecr 2156708670,nop,wscale 7], length 0
18:50:17.467177 IP 10.100.100.11.40788 > 10.130.130.22.80: Flags [S], seq 2628846409, win 65500, options [mss 1250,sackOK,TS val 2156708694 ecr 0,nop,wscale 7], length 0
18:50:17.467207 IP 10.100.100.11.40796 > 10.130.130.22.80: Flags [S], seq 3915422948, win 65500, options [mss 1250,sackOK,TS val 2156708694 ecr 0,nop,wscale 7], length 0
18:50:17.467842 IP 10.130.130.22.80 > 10.100.100.11.40796: Flags [S.], seq 3056575451, ack 3915422949, win 64900, options [mss 1310,sackOK,TS val 517535391 ecr 2156708694,nop,wscale 7], length 0
18:50:17.467851 IP 10.130.130.22.80 > 10.100.100.11.40788: Flags [S.], seq 1676106060, ack 2628846410, win 64900, options [mss 1310,sackOK,TS val 517535391 ecr 2156708694,nop,wscale 7], length 0
Es ist "wunderschön" zu sehen, dass der Request vom Proxy mit dem Ephemeral Port 40758 zwar den Proxy verlässt, auch an der OPNsense ankommt, diese aber nicht mehr verlässt. Auch das Retry/Retransmission wird nicht von der OPNsense beantwortet bzw. geroutet.

In dem Fall handelte es sich bei dem gescheiterten Request um ein klitzekleines SVG-Bild, dass beim Abruf einer Webseite mit ausgeliefert wird. Das Problem tritt auch nachts auf, wo noch weniger los ist. Keepalive im Reverse Proxy ist im Einsatz. Wer kann helfen und erklären, warum hier intern Pakete verloren gehen!?

#9

26.1, 26,4 Series / Re: DNSCrypt service had a red...

Last post by ChelseyMoore - May 30, 2026, 07:31:10 PM

Your workaround will probably help, but honestly it does sound more like a startup race condition than an actual DNSCrypt crash. Especially since manually restarting DNSCrypt and then Unbound immediately fixes everything.

I've seen similar behavior on OPNsense when services depending on WAN connectivity or IPv6 come up before interfaces are fully settled. DNSCrypt may technically "start" successfully, but fail to establish upstream connectivity during boot and end up in a half-dead state while Unbound happily starts forwarding to it.

The timing in your logs is suspiciously tight too. One second between DNSCrypt and Unbound startup is not much, especially with a huge DNSBL load and interface initialization still happening in parallel.

Your staggered cron workaround is actually pretty reasonable as a first step. Personally I'd also test whether disabling IPv6 temporarily changes the behavior, just to rule out delayed RA/DHCPv6 assignment causing DNSCrypt startup failures.

Another thing worth checking is whether the DNSCrypt plugin has proper service dependencies defined at all. Some plugins don't fully integrate with boot ordering and assume networking is already stable when rc starts them.

#10

Q-Feeds (Threat intelligence) / Re: blocking https://internet....

Last post by RamSense - May 30, 2026, 04:11:23 PM

Thanks, and correct. Website is working again.