VoIP + NAT

[cryz]

Tag auch.

Ich bin dabei mein Abschlussprojekt in nem Betrieb durchzuführen.

Ich habe 2 IP-Phones von Cisco (7962 und 7975) die jeweils hinter einem Src.-, sowie Dest-NAT Router (Cisco 1711er) stehen. Aus Sicherheitsgründen und Abgrenzung zum Netz des Unternehmens war dies notwendig.

Meine Phones erreichen sich telefonisch, allerdings kann man weder etwas hören noch reinsprechen. D.h. es liegt an RTP. Leider kann ich hier nicht sniffen um herauszufinden warum bzw. WO die RTP-Pakete verworfen werden. Ich nehme schwer an, dass sie am gegenüberliegenden NAT-Router verworfen werden. Hier nun die Frage:

Stimmt das?
Wenn ja, warum?

Ich weiß, es gibt workarounds wie z.B. STUN etc., diese aber möchte ich erst testen, sobald ich den Grund für die Schwierigkeiten kenne.


Ich wäre euch echt dankbar.

Greetz

Cryz

 

[chaos2000]

Hallo cryz,

welche firmware verwendest Du?
Hast du schon irgendwelche Ports weitergeleitet?

Versteh ich das richtig, das pro Netz nur ein Telefon steht?

 

[cryz]

Kannst du mir sagen wie ich die Firmware abfragen kann?^^
Port forwarding fand ich für sinnlos, da RTP ja eine Range von mehreren tausenden von Ports verwendet. Ich habe lediglich folgendes konfiguriert:

Die öffentlich angesprochene IP wird umgesetzt in meine Testip (Phone)

Dest 192.168.1.1 wird umgesetzt in 172.16.1.3
Z.B.

 

[chaos2000]

die Anzahl der rtp-ports kannst du ja beschränken - so war es zumindest bei den alten SIP Firmware Versionen.
Wenn du pro Netz nur ein Telefon hast, kannst du somit auch die rtp ports explizit weiterleiten.

Das die rtp Pakete verworfen werden wenn keine Regel definiert ist, sollte klar sein.

 

[chaos2000]

Erklärung der Problematik: http://www.voip-info.org/wiki/view/NAT+and+VOIP

 

[cryz]

Erklärung der Problematik: http://www.voip-info.org/wiki/view/NAT+and+VOIP

"The audio traffic is handled by another protocol and to make matters worse, the port on which the audio traffic is sent is random. The NAT router may be able to handle the signalling traffic, but it has no way of knowing that the audio traffic is related to the signalling and should hence be passed to the same device the signalling traffic is passed to. As a result, the audio traffic is not translated properly between the address spaces."

Ist für mich keine ausreichende Erklärung. Warum können die nicht in dem Adressraum übersetzt werden? Warum hat das mit Ports zu tun? Dann müsste es bei mir gehen, denn ich habe auf meinen Router eine 1zu1 Übersetzung konfiguriert. Sobald die öffentliche Adresse angesprochen wird müsste jedes Paket sofort an mein Phone weitergeleitet werden.

Ich habe bereits mit Cisco gemailt. Die kleinste Anzahl an verwendeten RTP-Ports wäre eine Spanne zwischen ca 24000-32500.

 

[chaos2000]

welche firmware verwendest du denn?
Wie ist die konfiguration?
Was verwendest du als sip-proxy?

 

[chaos2000]

Ich habe bereits mit Cisco gemailt. Die kleinste Anzahl an verwendeten RTP-Ports wäre eine Spanne zwischen ca 24000-32500.

Bei SIP definitiv nicht:
http://www.voip-info.org/wiki/view/Asterisk+phone+cisco+79x1+xml+configuration+files+for+SIP

These are the UDP ports that the phone expects to see RTP streams (UDP traffic) coming in and going out on. These values below are probably the defaults anyway. If you are running your phone behind a non SIP aware router you may want to narrow this range down to say 16384 and 16390, and then map UDP ports 16384 through to 16390 to your phone from the outside. This will allow your phone to receive inbound RTP voice streams. If your router is SIP aware then likely you do not need to change this from the defaults.

<startMediaPort>16384</startMediaPort>
<stopMediaPort>32766</stopMediaPort>

 

[cryz]

Ah ich sehe gerade, dass ich die Angabe vergessen habe. Ich arbeite leider nur mit SCCP. Das ist mir von der Firma vorgegeben. So wie im Bild unten habe ich alles konfiguriert.
Ich arbeite übrigens mit UCM, welcher sich auf einem Server im öffentlichen Netz befindet.

 

[chaos2000]

nur sccp ist gut - besser als sip - ist meine Meinung.
Mich persönlich würde interessieren wie man die Spanne bei sccp definiert - das ist aber wieder eine ganz andere Geschichte.

Hast du die Telefone schon mal als DMZ deklariert?

 

[cryz]

Bisher nicht. Aber inwiefern hätte das eine Auswirkung?

 

[chaos2000]

das sollte deinem problem entsprechen
http://www.voip-blog.co.uk/index.php/2009/11/21/nat-sip-range-on-uc500-cme

 

[cryz]

Leider nein. Ich habe 1 Phone an die Wolke "gehängt" und dort auch einen Sniffer laufen. UDP (Also RTP) Pakete kommen nur vom Phone hinter dem NAT Router zum Phone an der "Wolke". Vom Phone im Büro (Wolke) wird kein UDP Paket versendet. Weiß jemand warum? Sobald ich hierrauf eine Antwort habe könnt ihr den Thread closen!^^

 

[chaos2000]

Mit dieser Erklärung versteh ich die Skizze nicht mehr.
Wenn das Phone keine UDP Pakete sendet, dann kann es sein, das eine Skinny Nachricht nicht angekommen ist oder der Router alles schluckt.
Was ist bei dir "Wolke", i.d.R ist Wolke eine abstrakte Sache, an die man keine Telefone schließen kann

 

[cryz]

Die Wolke entspricht einem Switch aus dem internen Firmennetz.
Kann es sein dass ich das ALG-Feature am Router konfigurieren muss, damit er aus dem Payload die IP und Ports in den Header steckt, weil SCCP ein recht "dummes" Protokoll ist wie Cisco meint?

"Cisco IP phones use the SCCP to connect with and register to CCM.

To be able to deploy Cisco IOS NAT between the IP phone and CCM in a scalable environment, NAT needs to be able to detect the SCCP and understand the information passed within the messages. Messages flow back and forth that include IP address and port information used to identify other IP phone users with which a call can be placed.

The SCCP client to CCM communication typically flows from inside to outside. DNS should be used to resolve the CCM IP address connection when the CCM is on the inside (behind the NAT device), or static NAT should be configured to reach the CCM in the inside.

When an IP phone attempts to connect to the CCM and it matches the configured NAT rules, NAT will translate the original source IP address and replace it with one from the configured pool. This new address will be reflected in the CCM and be visible to other IP phone users."

Quelle: http://www.cisco.com/en/US/docs/ios/ipaddr/configuration/guide/iadnat_applvlgw.html#wp1048899

 

[chaos2000]

SCCP ist nicht dumm, im Gegenteil - die Telefone sind dumm, da sie ohne das Protokoll nichts können.
ALG ist auf jeden Fall kein Nachteil, wobei es in dieser einfachen Installation auch so funktionieren sollte.

Bei dem angegebenen Bsp frag ich mich nur gerade, seit wann sccp über port 20002, korrigiert mich aber standart ist 2000

 

[Tweety]

Fassen wir mal zusammen:

Es gibt 2 Netze, 172.16.1.0/29 (= SN1) und 172.16.1.8/29 (= SN2).
In diesen 2 unterschiedlichen Subnetzen befinden sich 2 Telefone mit den IPs 172.16.1.3 (SN1) und 172.16.1.11 (SN2).
Als Gateways kommen 1841er zum Einsatz, welche auf der WAN Seite mit einem (wie auch immer gearteten) Netz verbunden sind, welches komplett geroutet ist.
Damit Clients aus den Netzen SN1 und SN2 nach außen kommen, wird Source NAT genutzt.
Ein CUCM steht irgendwo in der Wolke und ist komplett geroutet direkt durch die 1841er erreichbar.

Soweit OK?

Was passiert also aktuell? Die Telefone wollen die RTP Pakete direkt austauschen, daher sendet (ohne ALG) das Telefon mit der IP 172.16.1.3 die IP Pakete direkt an 172.16.1.11! Das kann natürlich absolut nicht klappen, da die Router in der Cloud die Pakete nicht zustellen können. Gleiches gilt für das Telefon 172.16.1.11 an 172.16.1.3

Was muss also passieren? Wenn die Nachricht OpenReceiveAck ausgetauscht wird, muss durch das ALG in den 1841 die IP des Telefones ersetzt werden (durch die WAN IP) und per DNAT der RTP Port weitergeleitet werden. Den Link hierfür hast du ja schon.

Ich muss ganz ehrlich sagen, dass ich diese Konfiguration so nicht draußen habe. Persönlich würde ich einen Tunnel einsetzen, finde NAT im VoIP Kontext immer etwas hässlich, da es in den ALGs schon des öfteren diverse Bugs gab...

EDIT: Es muss OpenReceiveAck und nicht StartMediaTransmission sein.

 

[chaos2000]

OpenReceiveAck ist schon richtig