Onderwerp: Zijn hier ook Asterisk / openVPN guru's?

Hallo iedereen,

Misschien iemand hier die weet wat het volgende probleem kan veroorzaken?

Ik heb hier (thuis) een Asterisk server met freePBX (Debian OS) die een aantal trunks heeft en een aantal extensions.
Op de server staat ook openVPN
De trunks werken perfect, en hebben met het volgende probleem niks te maken.

Het probleem zit hem met een van de extensions.
Extentie 5003 is mijn thuis telefoon (zelfde netwerk als de Asterisk server)
Extentie 5008 is in de US, en werkt perfect.
Extentie 5009 (een Grandstream GXV3140) is in Dubai, en komt via openVPN op de Asterisk server aan (waar ook de openVPN op staat)
Ik zie dat 5009 netjes is verbonden met de Asterisk server, en een openVPN IP heeft.

Zowel extentie 5003 en 5008 kunnen naar 5009 bellen, maar 5009 kan niet naar 5003 / 5008 bellen.
Extentie 5009 heb ik (toen deze nog in Nederland was) getest via een andere ISP, en via de OpenVPN. Deze werkte toen goed.

Asterisk CLI geeft ook geen info als 5009 naar 5003/8 belt. M.a.w. Er komt niks van de 5009 kant aan op de Asterisk server!

Ik hoop dat er hier iemand is die misschien weet wat er mis kan zijn?

Alvast bedankt.

Ben wel een OpenVPN guru maar helaas nog een Asterisk beginner. Maar alsnog een poging om je van dienst te zijn:

Is de OpenVPN TUN of TAP? (cat /etc/openvpn/jeconfigfile)

Hallo rimote,

Bedankt voor je interesse.
Bij deze de server.conf

Code:

freepbx:~/openvpn/sbin# cat server.conf
## port 443
port 1194
proto udp
dev tun0
ca ca.crt
cert freepbx.crt
key freepbx.key
dh dh1024.pem
server 10.30.0.0 255.255.255.0
## crl-verify crl.pem
cipher BF-CBC
## ifconfig-pool=persist ipp.txt
keepalive 10 120
client-to-client
persist-key
persist-tun

tun-mtu 1500
mssfix 1400

## user nobody
## group nobody
log /root/openvpn/sbin/log/vpn.log
status /root/openvpn/sbin/log/openvpn-status.log
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"
# client-config-dir /root/openvpn/sbin/ccd
## push "dhcp-option DNS 4.2.2.1"
## push "dhcp-option DNS 4.2.2.2"
verb 3
mute 20
freepbx:~/openvpn/sbin#

Ik start openVPN met een klein scriptje

Code:

#!/bin/sh

dir=/root/openvpn/sbin
modprobe tun
cd $dir.
./openvpn --config server.conf --daemon

De Grandstream GXV3140 (voip telefoon) werkt enkel via TUN.

Noel

Oorspronkelijk geplaatst door edge

Hallo rimote,

Bedankt voor je interesse.
Bij deze de server.conf

knip openvpn config

Begin eens met tcpdump te sniffen (op het tunnel device, een openvpn van buiten sniffen is zinloos) wat er gebeurt als je belt vanuit 5009, en wat er gebeurt als je belt vanuit 5003 .
Kortom, vergelijk werkend en niet werkend.
Komt er echt geen bit binnen ? Dan kan de telefoon ook niet geregistreerd zijn. En dus niet belbaar.
SIP is vrij makkelijk leesbaar.

Kijk in de asterisk log (/var/log/asterisk/full ? ) .
Zet debug aan : sip set debug on (allemaal)
sip set debug peer 5009 (alleen 5009)
uitzetten :sip set debug off

sip show peers

Ik zal morgen wat testjes gaan doen, en die hier posten.

Bedankt voor je hulp.

Ik dacht dat het probleem wellicht werd veroorzaakt doordat je TUN (layer 3) ipv TAP (Layer 2) gebruikt.
Maar op internet zijn legio voorbeelden met een tun device dus ik neem aan dat het daar niet aan ligt.

Hoop dat het sniffen wat oplevert.

Helaas is het persoon 5009 (Dubai) er vandaag niet, en kan ik niet echt testen.
re: Komt er echt geen bit binnen ?
Wat ik bedoelde was dat ik in de Asterisk console (CLI) niks zie gebeuren als 5009 naar b.v. 5003 belt. (Andersom wel.)

Oorspronkelijk geplaatst door edge

Helaas is het persoon 5009 (Dubai) er vandaag niet, en kan ik niet echt testen.
re: Komt er echt geen bit binnen ?
Wat ik bedoelde was dat ik in de Asterisk console (CLI) niks zie gebeuren als 5009 naar b.v. 5003 belt. (Andersom wel.)

Dan moet er verbinding zijn, want dan is de 5009 blijkbaar geregistreerd.
Dat kun je dus zien met sip show peers (en de sniffer). De tijd voor her-registratie stel je in in de telefoon.
Die grandstreams kun je managen met een webbrowser, dus die kun je even wat sneller zetten (of het ding op afstand rebooten), en dan zie je 'm opnieuw registreren.

Ik zou nu ook al even wat sniffen en loggen, ook tussen 5003 (en maak nog een 5004 aan of zo, en zet zoiper op je laptop/desktop), dat je de call setup van calls tussen twee werkende extensies ziet.
Dan even kijken wat je ziet bij bellen naar 5009 (daarvoor hoeft er niemand te zijn), en als Dubai weer beschikbaar is kun je gaan kijken wat er dan anders is als 5009 zelf probeert te bellen.

Als je (ook voor jezelf) een goede baseline hebt hoe logs en packet captures eruit zien als het werkt is het een stuk makkelijker om het verschil te herkennen bij een niet werkende situatie.

Kortom : je kunt een hoop doen ook al is Dubai vandaag niet achter de telefoon.

Kan 5009 helemaal niet bellen, of alleen niet naar 5003/5008?

Klinkt als een geblokkeerd poortje?

5009 kan helemaal niet bellen (van de nieuwe locatie in Dubai. Uit de US, UK was het geen probleem).
Denk zlef niet dat het een poort probleem is omdat alles via OpenVPN loopt.
Ben nu even aan het pielen met sniffen en debuggen, maar dit gaat "tot nu" even boven mijn kunnen.

Ben er uit denk ik.

Ze doen daar in Dubai aan DPI (Deep packet inspection), en blokkeren alles wat ook maar o.a. met voip te maken heeft.
Zelfs mijn openVPN tunnel is niet heilig voor hun DPI.

Ik ga binnenkort naar Dubai, en zal van daar uit nog wat testjes gaan proberen.

Oorspronkelijk geplaatst door edge

Ben er uit denk ik.

Ze doen daar in Dubai aan DPI (Deep packet inspection), en blokkeren alles wat ook maar o.a. met voip te maken heeft.
Zelfs mijn openVPN tunnel is niet heilig voor hun DPI.

Heilig niet, maar de inhoud moet toch echt wel _veilig_ zijn voor DPI.
Het zou natuurlijk kunnen dat ze gewoon alle VPNs blokkeren, of er nu voip of iets anders doorheen gaat.

Maar ik ben niet helemaal overtuigd dat je eerste probleem vanwege DPI zou zijn, waarbij een uitgaand gesprek niet lukte en een inkomend wel.
Als ze menen aan de tunnel voip gedrag te herkennen is het raar dat er inkomend niks gedaan werd.

Oorspronkelijk geplaatst door edge

Ik ga binnenkort naar Dubai, en zal van daar uit nog wat testjes gaan proberen.

Ik ben wel nieuwsgierig, ik hoop dat je tegen die tijd post wat je gevonden hebt.

Het is alweer een tijdje geleden maar kan me nog iets herinneren wat betreft OpenVPN en Voip ik kan er helemaal naast zitten maar dacht dat dit het probleem was:

Is het niet zo dat Voip UDP is en dat OpenVPN geen UDP ondersteund?

Oorspronkelijk geplaatst door ivs

Het is alweer een tijdje geleden maar kan me nog iets herinneren wat betreft OpenVPN en Voip ik kan er helemaal naast zitten maar dacht dat dit het probleem was:

Is het niet zo dat Voip UDP is en dat OpenVPN geen UDP ondersteund?

Je zit er naast. OpenVPN ondersteunt UDP prima (zou lastig VPN'en zijn als DNS er niet overheen kon...)
Als UDP totaal niet zou werken zou inkomend bellen (wat bij de OP wel werkte) ook moeilijk verklaarbaar zijn.
VoIP is wel UDP inderdaad.

Tenslotte kan ik zeggen dat ik over een OpenVPN link wel kan bellen op een Asterisk centrale.

Misschien zit ik er helemaal naast, en ben dan ook geen voip/asterisk expert. Maar...

Kan het zo zijn, dat wanneer er een gesprek ge-initieerd wordt vanuit dubai, deze op de een of andere manier zijn publieke ip en route "ergens" gebruikt in de communicatie (met het andere toestel), en niet het verkeer door de tunnel stuurt? Ik denk niet dat je default route vanaf dubai door de openvpn tunnel is?

Andersom wordt het gesprek opgezet naar het vpn-ip van dubai, waardoor het wel werkt?

Ik zeg dit, omdat het volgens mij bij onze corporate voip centrale zo is, dat toestellen onderling ook met elkaar communiceren. Ik meen mij te herinneren dat dit mij ooit eens is opgevallen namelijk.

Misschien (mogelijk zelfs...) slaat het helemaal nergens op, maar misschien kun je er wat mee.