Grundsatzfrage Mobydick + VPN + NAT

Hallo zusammen,

inzwischen tut der Moby eigentlich ganz ordentlich seine Dienste verrichten. Nun dachte ich, wir könnten mal auf die advanced topics steigern.

Szenario:
Client@home (VPN) ------- NAT-Router ------- Internet ------- (VPN) Mobydick@Rootserver

OpenVPN eingerichtet; pingt, WebUI tut, gut. Nun geht praktisch aber nur das eine oder das andere. Nur der SIP-Trunk zu sipgate ODER die Verbindung zu den OpenVPN-Clients. Telephone für Mac ist auch nicht gerade die beste Client-Lösung, sendet immer mal falsche IPs im RTCP. Aber mit offener Firewall ging es hervorragend.

Probleme:
Die VPN-Clients verbinden sich via VPN zu 10.0.0.1. Da der Asterisk auf 0.0.0.0 lauscht, tut die Verbindung. In Telephone muss ich die Contact und Via-Header setzen, sonst sendet der Dummkopf RTCP 192.168.x.x als Client-Adresse. Dann muss noch der SIP-Client in Moby auf nat=yes gesetzt werden. Dann bekomme ich eine Verbindung intern zu stande! Die Clients halten diese aber nicht, angerufen werden können die Clients nicht. Das geht erst wenn die Server-Firewall aus ist. Der Rückkanal läuft also nicht an 10.0.0.1 sondern an 217.x.x.1. Irgendwie verbindet sich der Client lieber auf die externe Adresse.

Das kann ich ändern, indem ich in der sip.conf auf bindaddr=10.0.0.1 umstelle. Jetzt sind die Clients da und auch erreichbar. Allerdings geht jetzt das sipgate nicht mehr, weil der externe Server ja nicht mit 10.0.0.1 sprechen mag.

Trotz Tricks externip und localnet bleibt es dabei: entweder intern oder extern. Dabei ist das Szenario einfach: Asterisk spricht als 10.0.0.1 mit den Clients und als 217.x.x.1 mit dem Rest der Welt. Anscheinend wird das aber doch oft durcheinander gewürfelt.

Müsste ich auf dem Server zusätzlich einen SIP-Proxy installieren? Ein RTP-Proxy? Dann könnte der Server mittels bindaddr nur intern laufen. Sollte ich nat noch woanders setzen als auf den SIP-Geräten?

Wie sehen die Szenarien bei euch aus? Bei externen Roadwarriors ist da doch immer wenigstens ein NAT beteiligt.

Über ein paar Erfahrungen würde ich mich freuen

Hallo bytesplit,

nach meiner Erfahrung ist es am einfachsten, wenn man das NAT intern vermeidet. Also z.B.

Homeoffice: 192.168.100.0/24
VPN-Transit: 10.100.0.0/24
MobyDick Netzwerk in der Firma: 192.168.1.0/24

Dann kannst Du alles sauber routen und musst nichts NATen. Vermeidet viele Probleme.

Evtl. verstehe ich Dich aber auch falsch ;).

LG
Mathias

Hallo Mathias,

es ist etwas komplizierter, leider.Der MobyDick-Server läuft ja direkt im Internet (mit Firewall Zugang nur durch VPN). Damit hat Asterisk aber 2 Adressen, extern Inet und intern VPN. Gleiches gilt für den Client, der ja auch eine VPN-Adresse, eine LAN-Adresse und dann die externe Router-Adresse hat.

Telefon (die App) erkennt anscheinend das VPN nicht und schreibt gern die interne LAN-Adresse in den SIP-Header. So melde ich mich korrekt auf 10.0.0.1 an, der RTP-Traffic läuft dann aber mit 192.x.x.x (falsch). Da serverseitig das default-Gw das externe Interface ist, antwortet der dann mit 217.x.x.x nach 192.x.x.x. Klappt natürlich hin und her nicht, da beides nicht VPN. Mittels nat ignoriere ich jetzt den falschen Header von Telefon und dann kommunizieren 10.x.x.x und 10.x.x.y miteinander. D.h. die Hosts liegen im VPN direkt nebeneinander, erkennen aber diese Route bei der Erkennung der eigenen IP nicht an.

Setze ich im Asterisk das bindaddr auf 10.0.0.1, dann klappt die Kommunikation im VPN immer hervorragend. Dagegen wird aber die Anmeldung bei Sipgate abgelehnt, denn auch da steht in den SIP-Headern wir seien 10.0.0.1. Damit will Sipgate verständlicherweise nichts zu tun haben.

Somit scheint nur der Weg via nat zu funktionieren. Mit iptables SIP-NAT bin ich bisher gescheitert. Ich grüble noch ob sipproxd oder openSER noch eine Möglichkeit wären.

Zusammenfassend:
Mobydick hat 2 IPs; eine externe ins Inet und eine interne ins VPN
Mit der externen geht’s zum SIP PBX
Mit der internen an die eingebuchten Clients
bindaddr=0.0.0.0
Damit falsch erzeugte Header ignoriert werden, müssen die Clients nat=yes gesetzt bekommen (Z.B. Serververbindung OK aber kein Ton)
Wenn OpenVPN als default-gw gesetzt würde, gäbe es keine Probs, da aller Traffic übers VPN käme
Blink scheint besser als Telefon mit IPs umzugehen

Letztendlich bleibt meine Frage diese:
Wenn wie Du beschreibst Mathias, Mobydick z.B. 192.168.1.14 verwendet; klappt dann die Anmeldung beim SIP-Provider? Müsste da nicht ein Proxy umschreiben? Wie in meinem Szenario sendet er doch 192.168.1.14! Das klappt wohl nur wenn ich OpenVPN auf dem Default-Gateway oder zumindest ausserhalb der Mobydick fahre? Also sollte man OpenVPN besser nicht auf der Appliance installieren?

Kurzum:
Für mich ist da SIP ganz schön schräg drauf. Hat Asterisk mehrere IPs verwendet es gern die falsche Absenderadresse über das falsche Interface. 217.x.x.x via 10.x.x.x an 192.x.x.x hab ich im tcpdump gesehen und war arg verwundert. Warum SIP eine IP-Adresse im Paket separat angibt ist mir völlig schleierhaft.

Nachtrag: Google hat mir einen langen Thread auf der digium-Mailingliste angegeben. Asterisk macht generell Probs mit mehreren IPs. Also werd ich die VM wohl in ein LAN bewegen und den Rechnern dann mit nur einer IP ausstatten. Das ist dann zwar auch serverseitig NAT zu sipgate, aber nagut.

Hallo,

hmm… Also wir nutzen oft, fast immer mehrere Interfaces mit der MobyDick. Z.b. einmal VoIP Netz des Providers (bei business trunks) und einmal das Telefonnetz. Hatte damit noch keine Probleme.

Wir selbst nutzen das auch so:

eth0 10.X.X.X/24 das Telefonnetz
eth1 192.168.X.X/24 das VoIP Netz des Providers
bindaddr 0.0.0.0

Habe mir eben auch die SIP Invites angesehen. Alles nutzt brav zur Kommunikation die jeweilige IP des Interfaces über die es angesprochen wird.

Hast Du evtl. beide IPs auf dem selben Interface? Das macht bestimmt Probleme. Wenn ja würde ich mit VLANs arbeiten oder wenn’s virtuell ist einfach ein weiteres Interface dazu.

LG
Mathias

Hi,

es scheint wohl auf einem client-seitigen Problem zu beruhen. Sowohl Telefon als auch Blink senden im RTCP 192.168.3.64 (mein Client im LAN zu Hause). Blink bekommt es irgendwie hin NAT atom. zu aktivieren. Im Asterisk-Log wird zumindest nach ein paar Sekunden auf NAT gewechselt.

Letzten Endes laufen tut:
bindaddr=0.0.0.0
externip=217.x.x.x
localnet=10.0.0.0/255.0.0.0

(Übrigens erlaubt asterisk mehrere localnet-Angaben, das klappt im Commander allerdings nicht. Da darf’s nur ein localnet geben)

Alle Clients habe ich mit nat=yes versorgt. Rein und raustelefonieren klappt nun problemlos.

Möglicherweise könnte ich auf externip und localnet sogar verzichten. Immerhin passen die Daten nicht zueinander, denn die Geräte sind ja 10.x.x.x. Aber solange es tut, lass ich jetzt lieber die Finger davon!