SIP Testumgebung mit PPPoE

Hallo zusammen,

ich habe eine Testumgebung für SIP. Ein Router soll sich via PPPoE auf einem entsprechenden Server einwählen und sich dann an einem SIP UAS registrieren.
Als PPPoE Server verwende ich Accel-PPP.

<CPE IF:wan 192.168.9.100> --- <IF:ppp0 192.168.9.1 | PPPoE Server | IF:eth0 10.12.0.105> --- <SIP UAS IF:eth0 10.12.0.104>

Soweit so gut.

Aber mein PPP Server verändert den Source Port bei verbindungen zum PPP Client. Dies tritt auf, wenn ich einen Anruf vom PPP Client mache und vom SIP UAS RTP zuerst kommt. Dem SIP UAS habe ich eine Route mitgeteilt um die Pakete über den PPP Server zu senden und dieser macht dann PAT... kann man das irgendwie umgehen?

Viele Grüße und besten Dank für mögliche Antworten!

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 7814126944

Url: https://administrator.de/forum/sip-testumgebung-mit-pppoe-7814126944.html

Ausgedruckt am: 21.12.2024 um 17:12 Uhr

10 Kommentare

Neuester Kommentar

mein PPP Server verändert den Source Port bei verbindungen zum PPP Client.

Mit dem "richtigen" PPPoE Server passiert das nicht! 😉
https://www.heise.de/select/ct/2022/22/2225615544262937960

Hallo und vielen Dank. Ich habe mich einmal durch den Artikel gehangelt und das nachgebaut. Und da sehe ich das gleiche Verhalten. Vom SIP UAS Source Port 6000 wird am PPP Server ein beliebig freier Source Port gewählt.

Ich habe jetzt mein Setup geändert.
Auf dem SIP Simulator als Default Gateway meinen PPP-Server festgelegt und damit geht es.
Eine invertierte NAT Regel maskiert alles was ins Internet will und ignoriert alles was ins TestLAN will.
Aber warum bei meinem ersten Setup auf dem Rückweg der Source Port verändert wird verstehe ich nicht wirklich. Da ich statt einem Default Gateway eine feste Route eingetragen habe, sollte das doch auch klappen?

Das ist eigentlich komisch, denn bei PPPoE wir bekanntlich Default Route und DNS immer dynamisch via PPP übertragen. Endkunden von PPPoE Providern müssen das doch niemals selber statisch definieren, das wäre ja etwas praxisfern. Ebenso das NAT. Das macht ja auch immer der Router am Endkundenanschluss?!

Übrigens kann man auch mit einem kleinen 25 Euro Mikrotik einen PPPoE Server zum Testen betreiben:
https://wiki.mikrotik.com/wiki/Manual:Interface/PPPoE

Das ist eigentlich komisch, denn bei PPPoE wir bekanntlich Default Route und DNS immer dynamisch via PPP übertragen.

...

Ebenso das NAT. Das macht ja auch immer der Router am Endkundenanschluss?!

Die beiden Sachen sind auch nicht mein Problem.

Der PPPoE Server macht auch NAT MASQ für alle Pakete aus dem PPP Netz. Soweit auch in Ordnung. (Steht so auch in dem CT Artikel)
Aber ich denke hier liegt auch mein Problem.
Die SIP Pakete vom CPE enthalten im SDP die WAN IP der CPE.
Der SIP Simulator versucht durch mein 10er Netz direkt an die CPE WAN IP 192.168.x.x zu schicken. Das klappt, weil ich am SIP Simulator eine Route definiert habe (schicke 192.168. über PPPoE Server IP).
Und am PPPoE Server wird dann PAT? gemacht. Obwohl es doch nur Routing sein sollte, mMn.

Die SIP Pakete vom CPE enthalten im SDP die WAN IP der CPE.

Das ist ja auch üblich und durchaus normal, denn die eigentliche interne IP des SIP Endgerätes ist ja in der regel eine unroutebare RFC1918 IP. Die kann der SIP Host ja nicht sehen folglich ist die Source immer die (erreichbare) WAN IP des CPE.
Hier ist das von @LordGurke recht gut anhand eines Wireshark Traces erklärt.

Danke. Die CPE macht ja alles richtig. Ich verstehe nur nicht warum mein PPPoE Server das inbound RTP auf einen anderen Port packt.. oder stehe ich grade auf dem Schlauch und habe eigt schon alle Antworten bekommen?? :D

Im Bild sind zwei Traces, aber der gleiche SIP Flow zu sehen. Einmal am ppp0 zwischen CPE und PPPoE Server und einmal am "uplink" des PPPoE Server. Der inbound RTP Stream wird vom PPPoE Server auf einen anderen Port gepackt.
Ich nehme an, weil da das Connectiontracking irgendwie nicht passt?

RTP nutzt dynamische Ports. Das ist vermutlich normal.

Ich habe jetzt mein Problem vorerst gelöst. NAT Regel auf dem PPPoE Server rausgeworfen und überall als Gateway den PPPoE Server eingetragen. Jetzt passt es mit den Source Ports.