Asterisk / Firewall - kein Audio

[FrankR]

Ich versuche gerade eine SIP Client (X-Lite) Anbindung zu Asterisk durch einen VPN Tunnel (IPsec) zu konfigurieren. Das ganze funktioniert soweit auch ganz schön, solange ich die Firewall des Routers deaktiviere (ich kann leider die Firewall für das VPN auf diesem Router nicht seperat ausschalten, sobald sie an ist, muss ich diese auch für das VPN nutzen/konfigurieren).

Der Asterisk ist mit 1.2.14 schon etwas angegraut - aber da der bisher gut mit Bristuff und unseren SNOM Telefonen funktioniert, möchte ich da jetzt nicht dran schrauben, wenn es sich vermeiden lässt.

Ich habe in rtp.conf die Ports 10000 bis 10010 für RTP konfiguriert und diese Ports in der Firewall freigegeben (neben 5060 natürlich)

rtp.conf:

[general]
rtpstart=10000
rtpend=10010

beim Start meldet Asterisk auch wie erwartet:

Feb 20 22:45:56 VERBOSE[14457] logger.c:   == Parsing '/etc/asterisk/rtp.conf': 
Feb 20 22:45:56 VERBOSE[14457] logger.c:   == Parsing '/etc/asterisk/rtp.conf': 
Found
Feb 20 22:45:56 VERBOSE[14457] logger.c:   == RTP Allocating from port range 100
00 -> 10010

bei eine "sip debug" sehe ich jetzt allerdings:

Feb 20 23:13:57 VERBOSE[14503] logger.c: --- (13 headers 0 lines) ---
Feb 20 23:13:57 VERBOSE[14503] logger.c: Using latest SUBSCRIBE request as basis
 request
Feb 20 23:13:57 VERBOSE[14503] logger.c: Sending to 1.1.1.2 : 23068 (NAT)
                                                           ^^^^^^^^^^^^^^^^^^^^
Feb 20 23:13:57 VERBOSE[14503] logger.c: Found user 'fr_mbp'
Feb 20 23:13:57 VERBOSE[14503] logger.c: Looking for fr_mbp in local (domain 192
.168.0.9)
Feb 20 23:13:57 VERBOSE[14503] logger.c: Transmitting (no NAT) to 1.1.1.2:23068:
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 1.1.1.2:23068;branch=z9hG4bK-d8754z-75c0927ba59aee27-1---d8754z
-;received=1.1.1.2;rport=23068
                                   ^^^^
From: "fr_mbp"<sip:[email protected]>;tag=e7c1744e
To: "fr_mbp"<sip:[email protected]>;tag=as4a4c43e1
Call-ID: NWU0YzlmNzQyZDc3YzEwZGJhZDhjNGIwNzRkZDAwMTU.
CSeq: 1 SUBSCRIBE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0

Also wird offensichtlich Port 23068 für RTP verwendet?!
Ignoriert der Asterisk irgendwie die Einstellungen aus rport.conf?

Die Einstellungen in sip.conf für den Client:

[fr_mbp]
type=friend
context=local
username=fr_mbp
secret=******
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
allow=alaw
callgroup=1
pickupgroup=1
mailbox=66
nat=no
bindport=5060
canreinvite=no

Edit Guard-X: Code-Tags eingefügt!

 

[stinkstiefel]

[fr_mbp]
type=friend
context=local
username=fr_mbp
secret=******
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
allow=alaw
callgroup=1
pickupgroup=1
mailbox=66
nat=no
bindport=5060
canreinvite=no

Schau mal nach der Markierung.

 

[FrankR]

Ok, stehe da etwas auf dem Schlauch - das ganze läuft innerhalb eines VPN Tunnels - zwischen dem Rechner auf dem X-Lite läuft und dem Netz in dem der Asterisk steht ist kein NAT aktiv - also sollte das IMHO nicht das Problem sein.

Habe zum Spaß mal "nat=yes" gesetzt - gleicher Effekt.

 

[stinkstiefel]

Dann verstehe ich nicht was du damit meinst.

Das ganze funktioniert soweit auch ganz schön, solange ich die Firewall des Routers deaktiviere (ich kann leider die Firewall für das VPN auf diesem Router nicht seperat ausschalten, sobald sie an ist, muss ich diese auch für das VPN nutzen/konfigurieren).

 

[FrankR]

Ich meine, dass ich keine Audio Ausgabe bekomme und offensichtlich andere RTP Ports als die von mir konfigurierten verwendet werden. Verstehe einfach nicht warum...

 

[stinkstiefel]

SIP/2.0 404 Not Found <= Du wirst vermutlich wissen warum es zu 404 kommt.
Via: SIP/2.0/UDP 1.1.1.2:23068 <= Hier wird die IP-Adresse, die Portnummer und das Protokoll für die Rückantwort des Requests hinterlegt.
Ich frage mich also warum etwas für 192.168.0.x an 1.1.1.2 geschickt wird.

 

[FrankR]

Ehrlich gesagt, hatte ich keine Lust das weiter zu debuggen und habe jetzt alle UDP Ports aufgemacht, die Firewall ist auf diesem VPN sowieso nicht so sinnvoll, da ja bereits via IPSsec abgesichert - jetzt funktioniert alles einwandfrei.