Android sipdroid via openvpn an MD - fail

Support
1

Hallo,

ich habe mal wieder ein first World Problem:

Ich versuche an MD6 per UMTS etc. (Android) einen SipClient (sipdroid) über openvpn dran zu bekommen. Will nicht.

Direkt per WLAN Zuhause meldet sich der sip Client an - kein Problem.

Unterwegs bekomme ich keine Verbindung. An der Firewalll liegt es eher nicht, die ist offen genug.

Ping über die Verbindung zu MB geht. Verbindung zu Port 80 - geht. Test connect auf Port 5060 - geht nicht - timeout…

Kann es sein, daß das SIP von MB die Anmeldung aus anderen Netzen (anderer IP Range für VPN-Einwahl) nicht zuläßt ?
Falls ja, wo kann man das ändern ?

(Ggf liegt es auch dran, daß aktuell der VPN Tunnel per TCP gebaut wird, man kann wohl auch UDP wählen, sipdroid kann wiederum auch per TCP voipen.)

Grüße
Michael

2

Hallo Michael,

mal sehen ob ich dir bei deinem first World Problem helfen kann ;).

Als aller erstes würde ich auf der MobyDick in der AsteriskCLI durch “sip set debug ip VPN_IP_DES_TELEFONES” den Debug einschalten um zu sehen ob da überhaupt was ankommt. Alternativ, und pauschaler, einen “tcpdump -i DEIN_INTERFACE -s0 -w test.pcap” und dann per wireshark ansehen.

Das dein Tunnel TCP ist und die RTP payload dann über UDP kommt ist zwar nicht optimal, aber für eine SIP-Registrierung sollte es in jedem Fall reichen…

Noch wichtig, evtl. weist du das nicht, glaube aber eher schon: Das SIP Signaling läuft über 5060. Per SDP ("Unterprotokoll von SIP zur Definition der Session, auch über 5060) werden dann beliebige (fast, manchmal kann man das am Endgerät einstellen) UDP High-Ports ausgehandelt. Die eigentliche Sprache läuft dann per RTP von UDP High-Port zu UDP High-Port.

LG
Mathias

3

Hallo Mathias,

danke für Deine Anregungen. Mir scheint, als könne MD den Weg zurück zum SIP Clienten auf dem Smartphone nicht finden.

Hier mal das sip debug:

SIP Debugging Enabled for IP: 10.242.2.6
Transmitting (no NAT) to 10.242.2.6:36117:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.242.2.6:36117;branch=z9hG4bK89136;received=192.168.0.200;rport=36117
From: <sip:102@192.168.0.30>;tag=z9hG4bK60026744
To: <sip:102@192.168.0.30>
Call-ID: 233993109060@10.242.2.6
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:102@192.168.0.30>
Content-Length: 0

Transmitting (no NAT) to 10.242.2.6:36117:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.242.2.6:36117;branch=z9hG4bK89136;received=192.168.0.200;rport=36117
From: <sip:102@192.168.0.30>;tag=z9hG4bK60026744
To: <sip:102@192.168.0.30>;tag=as71c60187
Call-ID: 233993109060@10.242.2.6
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
WWW-Authenticate: Digest algorithm=MD5, realm=“pascom.net”, nonce=“6d5809df”
Content-Length: 0

Scheduling destruction of call ‘233993109060@10.242.2.6’ in 15000 ms
Using latest REGISTER request as basis request
Transmitting (no NAT) to 10.242.2.6:36117:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.242.2.6:36117;branch=z9hG4bK89136;received=192.168.0.200;rport=36117
From: <sip:102@192.168.0.30>;tag=z9hG4bK60026744
To: <sip:102@192.168.0.30>
Call-ID: 233993109060@10.242.2.6
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:102@192.168.0.30>
Content-Length: 0

Der Paket Logger:
Source Destination
313 09:01:47 Do, 24.04.2014 18.4394890 192.168.0.30 10.242.2.6 SIP SIP:Response: SIP/2.0 100 Trying
314 09:01:47 Do, 24.04.2014 18.4394890 192.168.0.30 10.242.2.6 SIP SIP:Response: SIP/2.0 401 Unauthorized
315 09:01:47 Do, 24.04.2014 18.4407590 192.168.0.30 10.242.2.6 SIP SIP:Response: SIP/2.0 100 Trying
316 09:01:47 Do, 24.04.2014 18.4407590 192.168.0.30 10.242.2.6 SIP SIP:Response: SIP/2.0 401 Unauthorized
358 09:01:51 Do, 24.04.2014 22.4873410 192.168.0.30 10.242.2.6 SIP SIP:Response: SIP/2.0 100 Trying
359 09:01:51 Do, 24.04.2014 22.4879220 192.168.0.30 10.242.2.6 SIP SIP:Response: SIP/2.0 401 Unauthorized
360 09:01:51 Do, 24.04.2014 22.4882350 192.168.0.30 10.242.2.6 SIP SIP:Response: SIP/2.0 100 Trying
361 09:01:51 Do, 24.04.2014 22.4891420 192.168.0.30 10.242.2.6 SIP SIP:Response: SIP/2.0 401 Unauthorized
374 09:01:53 Do, 24.04.2014 24.8456820 192.168.0.30 10.242.2.6 SIP SIP:Response: SIP/2.0 100 Trying
375 09:01:53 Do, 24.04.2014 24.8456820 192.168.0.30 10.242.2.6 SIP SIP:Response: SIP/2.0 401 Unauthorized
522 09:01:58 Do, 24.04.2014 28.8652110 192.168.0.30 10.242.2.6 SIP SIP:Response: SIP/2.0 100 Trying
523 09:01:58 Do, 24.04.2014 28.8663950 192.168.0.30 10.242.2.6 SIP SIP:Response: SIP/2.0 401 Unauthorized
1060 09:02:02 Do, 24.04.2014 32.9456900 192.168.0.30 10.242.2.6 SIP SIP:Response: SIP/2.0 100 Trying
1061 09:02:02 Do, 24.04.2014 32.9460160 192.168.0.30 10.242.2.6 SIP SIP:Response: SIP/2.0 401 Unauthorized

Google sagt etwas zu NAT, was man ggf am Asterisk einstellen könnte. Oder doch ein nating Problem auf der Firewall / Router ?

Grüße
Michael

4

Hallo Michael,

wenn ich es richtig verstehe, machst du in deiner VPN Strecke NAT. Dann musst Du auch bei dem Gerät (Softphone) in der MobyDick bei den Optionen nat=yes eintragen. Dann sollte es klappen. Allerdings wäre es evtl. eleganter im VPN mit einem Transit-Netz zu arbeiten und auf NAT zu verzichten.

LG
Mathias

5

Servus,

epic fail - 10 Peitschenhiebe mit einem cat7 Kabel auf meinen Rücken …

Es lag wohl nur am falschen Gateway auf dem MD … Habe 2 Gateways: 1 x Fritzbox für direkt ins www und einmal die Firewall, die auch VPN-Einwahlserver (und worauf sich der Android einwählt) ist und den privaten Internet-Verkehr filtert. Die Fritzbox stand im MB als GW drin. Habe aber testweise auch die Firewall als Gateway eingetragen und die Konfig angewendet. Ging auch nicht. Nach einem Reboot von MD + der Firewall als GW hat er sich nun verbunden und ich kann auch telefonieren. Würde auch Sinn machen, daß MD die Weg zum SIP-Clienten nicht gefunden hat. Solche Anfängerfehler wieder …

Danke und Gruß
Michael

6

Hallo Michael,

epic fail - 10 Peitschenhiebe mit einem cat7 Kabel auf meinen Rücken …

Sei nicht so streng mit Dir, cat5 tuts auch ;).

Hauptsache es geht jetzt.

LG
Mathias

7

Nur für die Nachwelt: Es lag doch nicht am Gateway. Einen Tag später ging es plötzlich wieder nicht - geändert wurde nix. What ever - ggf liegt es am doofen SIP Client auf Android.

Ich werde, falls ich mal überhaupt telefoniere, das Callthrough der Fritzbox nutzen. Also Android SIP-Client nach sipgate. Sipgate Anruf nach Sipgate-Konto auf der Fritzbox und von da dann weiter. Spart auch den Aufbau des VPN Tunnels.

8

Nach der Migration auf MD7 geht es nun (wieder) - stand jetzt :wink: