SIP Telefon im entfernten Netz registrieren

Hi,
mach mal einen Wireshark. Es klingt hier als ob das RTP fehlt.

Gruß

Moin,

wie der Kollege @killtec geschrieben hat, fehlt die Freigabe der RTP Ports über den Tunnel.
Diese sind abhängig von Deiner Telefonanlage.
Zum Test solltest Du von beiden Seiten mal UDP 1-65535 freigeben. Damit sollte es funktionieren.


Gruß

Looser

Das Problem ist in der Tat nicht "komisch". Komisch gibt es in der IT generell nicht, denn da ist alles digital, weiss man ja auch als Netzwerker ! 😉
Ein analoges Design wie deins kannst du auch in diesem_Thread nachlesen.

Wie oben Kollege @BirdyB schon sehr richtig vermutet hat, ist sehr wahrscheinlich deine VPN Tunnel Konfiguration der Router fehlerhaft. Ist aber erstmal nur frei geraten weil man weder deine Router noch die Konfig kennt.
Das beschriebene Verhalten lässt aber stark vermuten das du fälschlicherweise im VPN Tunnel auch NAT machst (IP Adress Translation) das ist natürlich unsinnig und ein Konfig Fehler im eigenen Netz ist NAT natürlich überflüssig ! NAT im Tunnel führt bei RTP (was die eigentlichen Sprachdaten transportiert) zu so einem typiscen Verhalten.
Der Grund ist das RTP dynamische Ports benutzt. Der Angerufene eröffnet also dynamische RTP Ports (UDP) zurück auf den Anrufer die aber in der Session Table des sendenden Routers keinen entsprechenden Session Eintrag haben. Die Folge davon ist dann das die NAT Firewall diese inbound Sessions abweist. Das hat dann zur Folge das RTP Flows vom sendenden Router durchkommen die vom Gegenüber wegen der o.a. Problematik aber nicht.
Das resultiert dann immer in dieser klassischen Symptomatik der "einseitigen" Kommunikation bei VoIP. Eine Seite hört was...die andere nicht.
Kollege @LordGurke hat das hier im Forum sehr schön im Detail erklärt: VoIP-Telefonie über SIP-Client "Zoiper" (FritzBox 7560 als Router)
Fazit:
Korrigiere deine falsche VPN Konfig auf den Routern und nehme dei IP Netze .1.0 bis .4.0 und .11.0 bis .41.0 aus dem NAT raus. Dann klappt es auch mit der Telefonie sofort !

My WAN und Remote WAN "0.0.0.0" ist nur ein Dummy, oder ?? Ansonsten wäre das ein hellseherischer Wunderrouter.
Routing und NAT hat per se NICHTS miteinander zu tun. Um ganz sicher zu gehen solltest du in den Zielnetzen mal ein tcpdump oder Wireshark Trace machen und dir die Absender IPs aus dem jeweils anderen Netz ansehen. Kommen Pakete damit = kein NAT, kommen sie mit IPs aus dem loklen Netz = NAT. In der Regel machen IPsec Site to Site VPNs sowas nicht, aber bei diesen einfachen Router kann man sich nicht sicher sein. Deine VoIP Symptome sprechen aber klar für ein NAT im Tunnel.
Es ist auch möglich das der Haken "Create Phase 2 SA for each subnet" etwas damit zu tun hat. Normal ist das die Regel es sei denn man macht eine Summary P2 SA mit einem größeren Prefix um ALLE lokalen IP Netze einzufangen. Bei dir dann z.B. mit einem 21 Bit Prefix (255.255.248.0) der dann alle IP Netze von .0.0 bis .7.254 in den VPN Tunnel routet mit einem einzigen P2 SA. Da du aber 24er Prefixes verwendest müsste er (eigentlich) für alle einen P2 SA erzeugen...etwas komisch oder eben Draytek erzeugt diese Prefixes selber.

Logisch nachdenken hilft hier !
Wenn du die Phase 2 so eingerichtet hättest mit remote Network = 192.168.0.0 /21 dann hätte das alle IP Netze von .0.0 bis .7.254 inkludiert !
Die Phase 2 klassifiziert ja für den Router alle IP Pakete die in den VPN Tunnel geroutet werden ! Wenn du ihm also sagst: //Nimm alles was 192.168.0.0 /21 (21 Bit Subnetzmaske = 255.255.248.0 = 21 Bit Prefix) ist dann routet er mit einer einzigen Phase 2 Definition alles was als Zieladressen 192.168.0.1 bis 192.168.7.254 hat in den VPN Tunnel. Eben ohne 4 mal Phase 2 zu definieren.
Was ist daran denn schwer zu verstehen ?? IP Adress technisch doch eigentlich ganz logisch !

Richtig ! Dafür wäre einmal ein Wireshark Trace hilfreich um zu sehen woran die SIP bzw RTP Sessions wirklich scheitern.