Outbound NAT Problem

[matboehmic]

Hallo,
wir haben bei einer Opnsense folgendes Symptom beim Outbound NAT:

<VOIP-TK> im internes Netzwerk <-> opnsense <-> Internet mit statischer IP <SIP Provider>

Im internen Netz kommuniziert eine VOIP-Telefonanlage (Innovaphone) via Outbound NAT mit dem SIP-Provider. Dazu haben wir (in Absprache mit dem SIP Provider) das Outbound NAT so eingestellt, daß die nach außen kommunizierende Telefonanlage via Static Port spricht.

Von außen nach innen haben wir dann ein Port-Forwarding angelegt. Das funktioniert auch in 99% der Fälle.
Wir haben aber leider 1-2 mal am Tag für wenige Minuten das Phänomen, daß das outgoing NAT die interne IP-Adresse nicht richtig auf die externe IP-Adresse des WAN-Interfaces umschreibt. Statt dessen wird nach extern die interne IP der Telefonanlage gesendet.
D.h. am WAN Interface erscheinen auf einem mitgeschnittenen tcpdump die internen IP-Adressen (10.x.x.x) . Das führt natürlich beim Empfänger (SIP-Provider) dazu, daß der nicht weiß wohin mit dem Paket, wenn er es zurück schicken soll.
Folge: Der Telefon-Anruf (SIP) scheitert.
Die Opnsense ist auf physischer Hardware installiert. Darin ist ein quad-Core Prozessor mit 16 GB RAM (aus meiner Sicht mehr als ausreichend) . Das System ist praktisch nie wirklich ausgelastet.
System:    OPNsense 19.1.10-amd64,OpenSSL 1.0.2s 28 May 2019

Frage: An welcher Stelle müssen wir schrauben / schauen damit wir das Problem eingrenzen und idealerweise los werden?

Hat jemand eine Idee, welche Einstellung des outbound NAT noch beeinflusst?

Vielen Dank vorab,
Mat

[JeGr]

> Statt dessen wird nach extern die interne IP der Telefonanlage gesendet.
> D.h. am WAN Interface erscheinen auf einem mitgeschnittenen tcpdump die internen IP-Adressen (10.x.x.x) . Das führt natürlich beim Empfänger (SIP-Provider) dazu, daß der nicht weiß wohin mit dem Paket, wenn er es zurück schicken soll.

Also setzt einfach mal "kurz" die NAT aus? Das wäre sehr seltsam. War/ist in dem TCPDump denn etwas ersichtlich anders bei dem Aufbau? Fragmentation, anderer State, Flags (wenn TCP), irgendwas? Ich würde das mit einer "OK" Sitzung mal direkt vergleichen, ob das nicht an der Stelle dann was komisches von der Anlage ist und gar nicht der Filter/Sense schuld ist. Gab es leider viel zu häufig, dass die Schuld im Nachgang der ISP/SIP Provider/Die Anlage war und man Stunden unnötig auf der Firewall zugebracht hat.

Gruß

[matboehmic]

hm, ok - danke

dann tauch'  ich da noch mal ein
Gruss
Mat