OPNsense 26.1.11: Intermittierende eRezept-Störung bei TI-IPsec/NAT-T (UDP 4500)

[Vanille]

Hallo zusammen, nach Wechsel auf OPNsense 26.1.11 gibt es bei einer Arztpraxis intermittierende Probleme beim eRezept (,,Kommunikation Fachdienst", Medatixx), während eAU zuverlässig funktioniert.
Im Aufbau stehen secunet-Konnektor und medatixx-Server im selben flachen LAN ohne VLAN oder Firewall zwischen beiden; der Server hat statische Routen für 100.102.0.0/15 und 188.144.0.0/15 direkt über den Konnektor.
Der Konnektor baut den TI-IPsec/NAT-T-Tunnel über UDP 4500 nach außen auf; Outbound NAT mit Static Port ist vorhanden und LAN ist ausgehend nicht eingeschränkt. Im WAN-Capture ist bidirektionaler UDP-4500-Traffic sichtbar, ebenso ein aktiver State.
Der TI-Dienstleister vermutet, die Firewall verarbeite Antworten zu langsam, konnte bisher aber keinen konkreten Fehlerzeitpunkt, Zielhost/-IP, Port oder Lognachweis nennen.
Zusätzlich bestand ein DNS-Thema: Der Windows-DNS auf dem DC konnte TI-Split-DNS über seine normale Weiterleitung nicht auflösen. Deshalb wurde eine bedingte Weiterleitung splitdns.ti-dienste.de → Konnektor eingerichtet; die Auflösung funktioniert damit nun auch über den DC. Offen ist, ob dies ursächlich für die Störung war. Gibt es bei OPNsense/pf mit PPPoE und ausgehendem IPsec NAT-T über UDP 4500 bekannte Ursachen für sporadische Timeouts? Welche konkreten States-, NAT-, Firewall- oder Interface-Werte sollte ich prüfen? Und: Eine explizite WAN-Pass-Regel für UDP 500/4500 sollte bei einem vom Konnektor ausgehend aufgebauten Tunnel doch nicht erforderlich sein, da Rückverkehr über States zugeordnet wird – korrekt?
Über Rückmeldungen würde ich mich sehr freuen :)

[mooh]

Falls bei UDP große Verzögerungen zwischen aus- und eingehenden Paketen liegt, könnte die Firewall den Verbindungszustand bereits verworfen haben. Im Gegensatz zu TCP gibt es ja kein keep-alive. Ich selbst hatte das Problem noch nie und kann deshalb auf die Schnelle leider keine Stelle in der Konfiguration finden, wo man mit UDP timeouts spielen kann.

Ob es überhaupt daran liegt, kann man testen, indem man das Logging der FW für default Regeln einschaltet. Verspätete Antworten der UDP "Verbindung" laufen in die default deny all Regel.