Asterisk ungewöhliches NAT (extenhost wir ignoriert)

[sapier]

Hallo
Ich Nutze Asterisk 1.4.17 mit einer echt ungewöhnlichen Nat konfiguration ... ja ich weiss das ist immer problematisch aber evtl hat ja doch jemand ne Idee.

Ich versuche mich jetzt bei ekiga.net oder sipgate.de anzumelden, leider klappt das nicht wie gewünscht.

Die Situation ist folgende:

Internet <-> DSL-Router <-> Firewall <-> Asterisk

Also IP-Seitig:
[ PublicIP | Router | 192.168.X.Y ] <-> [192.168.X.Z | Firewall | 192.168.A.B ] <-> [ 192.168.A.C Asterisk]

Wenn ich auf der asteriskmaschine meine dyndns Adresse anpinge bekomme ich als ip die PublicIP also habe ich die dyndns Adresse via externhost=<dyndns> in die sip.conf eingetragen. Natürlich habe ich die entsprechenden port ranges sowohl auf dem Router als auch auf der firewall geforwarded.
Soweit so gut das SIP REGISTER geht auch an die entsprechenden hosts raus jedoch steht dort als IP nicht die externe ip sondern die Firewall-IP 192.168.X.Z .
Die ist natürlich für die registry wertlos folglich bekomme ich bei ekiga.net ein registry denied. Sipgate scheint da weniger verschnupft zu sein und akzeptiert trotz falscher IP aber auch hier werden die Gespräche nicht zum Asterisk durchgestellt.

Hat jemand eine Idee warum asterisk "externhost" (externip hab ich auch versucht)
einfach ignoriert?

 

[doxon]

Hast du das ganze schon mal mit der NAT-Option getestet?
nat=yes

 

[sapier]

Also das Gute gleich als erstes, das Problem ist gelöst.
Nein die nat=yes Option hat nichts gebracht, wenn ich die Doku dazu richtig verstanden habe beeinflusst das ja auch nur das Verhalten von Asterisk gegenüber eingehenden SIP-Nachrichten.
Aber für mein Problem war das eh unerheblich, weil Asterisk gar nicht die Ursache der Schwierigkeiten war. Nachdem ich die SIP-Pakete mal direkt am Asterisk-Server gedumpt habe ist mir aufgefallen, dass die ausgehenden Pakete die richige IP enthalten, am anderen Ende der Firewall aber die falsche drin stand.
Ursache war, dass auf der Firewall die ip_nat_sip und ip_conntrack_sip Module geladen wurden. Diese haben die IP im SIP-Header umgeschrieben.
Ich habe die Module entfernt und schon wurde die richtige IP sowohl an Sipgate als auch an ekiga.net übertragen.

Über sipgate eingehende Anrufe funktionieren nun, ekiga.net sträubt sich immer noch etwas aber das ist eine andere Baustelle.

 

[MicroPhone]

Hallo zusammen,
ich scheine irgendwie ein ähnliches Problem zu haben. Symptom: Asterisk kommt nicht an Sipgate ran, X-Lite jedoch ohne Probleme.
Wenn ich den IP-Stream auf dem ppp0 dumpe sieht das so aus:

vom Asterisk:

11:56:30.990581 IP 192.168.21.9.5060 > 217.10.79.9.5060: SIP, length: 491
11:56:31.986688 IP 192.168.21.9.5060 > 217.10.79.9.5060: SIP, length: 491
11:56:32.986156 IP 192.168.21.9.5060 > 217.10.79.9.5060: SIP, length: 491

vom X-Lite:

11:56:35.957953 IP 217.XXX.XXX.XXX.5060 > 217.10.79.9.5060: SIP, length: 2
11:56:35.960068 IP 217.XXX.XXX.XXX.5060 > 217.10.79.9.5060: SIP, length: 456
11:56:36.014506 IP 217.10.79.9.5060 > 217.XXX.XXX.XXX.5060: SIP, length: 458
11:56:36.017049 IP 217.XXX.XXX.XXX.5060 > 217.10.79.9.5060: SIP, length: 631
11:56:36.074626 IP 217.10.79.9.5060 > 217.XXX.XXX.XXX.5060: SIP, length: 408

Die Nat aendert die interne IP einfach nicht ab, ABER das NUR beim *.
Hat da jemand nen Denkansatz ? Ich habe bereits die sip_conntrac-module geladen und entladen - bringt keine Veraenderung.

Und witzigerweise hat das mal funktioniert - genau 23h lang - Neustart des * hat nix geaendert, nach dem Neustart des Routers gings wieder - etwa 16h. Jetzt hilft nichts von beidem mehr. Beim Nachforschen hab ich dann diesen Dump oben gesehen.

Ich vermute schwer, dass das irgendwas mit dem internen NAT-Table zu tun hat - aber was ? - und warum nur vom * ?

Meine Config:
* 1.4.17-bristuffed
Router: Debian 4.0 - Kernchen: 2.6.18

Sip.conf kann jederzeit nachgeliefert werden - sieht mir aber mehr nach Kern-Problematik aus, da das ja nicht die IP-Info im Application-Layer betrifft, sondern im Transport-Layer.

THX, Micro

 

[MicroPhone]

Das ist echt Kaese.

Die Sip-Verbindung funktioniert nen knappen Tag und steigt dann aus und ganz ploetzlich geht wieder nur die interne IP aus dem NAT. Da muss doch irgend nen table ueberlaufen oder so ?! ...
Nen Reset bringt leider nur manchmal Abhilfe - voll merkwuerdig.
Habe die Module die Sapier nannte wegkopiert - koennen also nicht mehr geladen werden.

Hat noch jemand Ideen ?

 

[MicroPhone]

[scheinbar geloest]

... hab scheinbar dat Problem gefunden - der NAT-Tracking-Table laeuft scheinbar bei den Sip-Verbindungen gen sipgate einfach ueber.

ein conntrack -F loest das Problem jedenfalls sofort!

 

[MicroPhone]

neuer Router - gleiches System - Problem weg

Hallo zusammen,

das Problem ist bei mir geloest - leider weiss ich nicht warum. Hab nen neuen Router mit nem aktuellen Debian 4.0, mit nem 2.6.18-6er (eigentlich das gleiche wie vorher) aufgesetzt.
Witzigerweise und entgegen jeder Erwartung tritt diese Erscheinung nicht mehr auf. Ich nutze immernoch conntrack_ftp als Modul.

Viel Erfolg auch euch!