jompsi
Sep 21, 2015
view7378
view11
0
Goto Top

VOIP Problem über IPSec

GermanQuestionVoice over IPNetworks
Hi zusammen

Wir haben in unserer Firma seit einer Weile einen zweiten Standort. Dieser zweite Standort ist mit IPSec zu unserem Hauptstandort verbunden. Bei unserem Hauptstandort haben wir eine FortiGate 60D und beim zweiten Standort einen Ubiquiti Edge Router Pro. Zwischen diesen läuft das IPSec eigentlich gut, jedoch haben wir mit der Telefonie Probleme. Wir verwenden Swyx(VOIP). Der Swyx Server befindet sich bei unserem Hauptstandort. Nun treten bei der Telefonie folgende Fehler auf:
- Die Telefonie zwischen dem Hauptstandort und dem zweiten Standort funktioniert sehr unzuverlässig. Meistens ist es so, dass das Telefon klingelt und auch abgenommen werden kann, jedoch hören sich die beiden Gesprächspartner nicht.
- externe Anrufe zum Hauptstandort funktionieren, sowie externe Anrufe zum zweiten Standort

Wir haben auf beiden Firewalls testweise alle Protokolle zwischen den IPSec Standorten erlaubt, doch das Problem wird dadurch nicht gelöst. In meinen Augen scheint das Problem nicht ein Protokoll zu sein, welches fälschlicherweise in der Firewall geblockt wird.

Das komische an der Sache ist auch, dass es manchmal funktioniert und dann wieder nicht. Leider ist es so, dass es häufiger nicht funktioniert und deshalb das Vertrauen in die Telefonie von den Benutzern verloren gegangen ist.

Und der Traffic über den IPSec Tunnel ist auch nicht so gross, dass wir ein Bandbreiten Problem haben. Beim zweiten Standort sind zwischen 2 - 5 Personen.

Habt ihr hier irgendwelche Erfahrungen und Tipps für mich?

Grüsse
Joel
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 283486

Url: https://administrator.de/contentid/283486

Printed on: April 20, 2024 at 03:04 o'clock

11 Comments
Latest comment
Goto Top
Member: Neomatic
Neomatic Sep 21, 2015 at 08:28:25 (UTC)
Goto Top
Guten Morgen,

habt ihr QoS für VoIP aktiviert?

Gruß
Neomatic
Member: jompsi
jompsi Sep 21, 2015 at 08:53:04 (UTC)
Goto Top
Hallo Neomatic

Ich habe auf der FortiGate einmal Traffic Shaping(QOS) konfiguriert. Aber das ist zur Zeit wieder inaktiv, da ich sehe, dass so ein Telefonat nur 300 KBytes Bandbreite benötigt. Und die Mitarbeiter greifen sonst nur auf Office Dokumente vom Hauptstandort zu.

Wenn ich QOS einrichte, reicht es, wenn ich es nur auf der FG mache, oder muss es auf dem Edge Router und der FortiGate parallel eingerichtet sein?

Danke und Gruss
Joel
Member: Neomatic
Neomatic Sep 21, 2015 updated at 09:09:58 (UTC)
Goto Top
Hallo,

muss auf beiden konfiguriert sein. Sonst wird der Traffic nur von der Fortigate richtung Außenstelle prioritisiert.

Da VoIP und ISDN over IP sehr Zeitkritisch sind, sollte dieser Traffic allem anderen vorgezogen werden.

Gruß
Neomatic
Member: jompsi
jompsi Sep 21, 2015 at 11:32:52 (UTC)
Goto Top
Hallo

Danke für den Input. Werde es versuchen umzusetzen, aber etwas ist mir nicht ganz klar.

Wenn jemand vom Hauptstandort mit jemandem vom zweiten Standort telefonieren will, klingelt das Telefon und kann abgenommen werden, die beiden Gesprächspartner hören sich aber trotzdem nicht.

Wenn aber der zweite Standort mit jemandem externen telefoniert, funktioniert es. Was für ein Einfluss hat QoS auf dieses verhalten? Wenn die Bandbreite das Problem wäre, müsste doch beides nicht gehen?

Der VOIP Traffic geht immer über unseren Hauptstandort, da sich dort der Swyx Server befindet. Egal ob der Anruf intern oder extern ist.

Danke und Gruss
Joel
Member: Dirmhirn
Dirmhirn Sep 21, 2015 updated at 11:49:59 (UTC)
Goto Top
Hi,

die Verbindung würd über SIP aufgebaut, aber die Daten laufen dann über RTP.
Die SIP Pakete schaffen es wohl durch euer VPN, aber die RTP Daten nicht. Die RTP Daten laufen in der Außenstelle nicht über eure Hauptniederlassung, wenn ihr an der Außenstelle einen direkt Internetzugang habt.

ev. spielen IPS Regeln rein - UDP flood Detection zb. ev. gibt es mehrere Logfiles für die Firewall.

Das komische an der Sache ist auch, dass es manchmal funktioniert und dann wieder nicht. Leider ist es so, dass es häufiger nicht funktioniert und deshalb das Vertrauen in die Telefonie von den Benutzern verloren gegangen ist.

kann es sein, dass es einen Unterschied macht ob ihr die Externe oder interne Durchwahl/Nummer wählt?

Da VoIP und ISDN over IP sehr Zeitkritisch sind, sollte dieser Traffic allem anderen vorgezogen werden.
Wie Neomatic schon sagt, es geht um die Übertragungszeit/Qualität und nicht die Bandbreite. Du kannst 100 Mbit haben, aber wenn die Paketlauzeit extrem schwankt, dann hat VoIP Probleme da Pakete zu spät ankommen. Für normale Datenübertragungen ist das egal. Hier werden am Ende einfach alle Pakete sortiert.
Ev. ist die Internetanbindung in der Außenstelle gerade so an der Kippe und der zusätzliche VPN overhead, macht ein telefonieren dann unmöglich.

sg Dirm
Member: aqui
aqui Sep 21, 2015 updated at 13:02:58 (UTC)
Goto Top
Die Kardinalsfrage ist ob im Tunnel selber NAT (IP Adress Translation) gemacht wird. In der Regel ist das vollkommen überflüssig, viele machen aber diesen grundlegenden Fehler bei der VPN Konfiguration und aktivieren NAT.
NAT ist der Todesstoß für RTP, da dort dynamische Portnummern verwendet werden die dann folglich an der NAT Firewall hängenbleiben.
Solche Dinge wie "sie hören sich nicht" oder "man hört nur eine Seite" sind typische Symptome dafür. Kollege Dirmhirn ist vermutlich auf der richtigen Fährte.
Du solltest also bei der korrekten VPN Konfig ansetzen.
Ich habe auf der FortiGate einmal Traffic Shaping(QOS) konfiguriert.
Das ist natürlich auch Blödsinn und lässt leider befürchten das du nicht wirklich weisst was du da machst. VoIP erfordert eine Priorisierung ! Niemals ein Traffic Shaping. Vergiss den Unsinn.
Da du routest musst du die Priorisierung zwangsläufig über DSCP im Layer 3 machen. Vermutlich nutzen die Swyx Telefone schon eine Art von Priorisierung. Entweder L2 oder L3.
Leider kommt dazu von dir ja keinerlei Infos, was eine zielgerichtet Hilfe wieder erschwert.
In der Regel setzen die Telefone einen DSCP CoS Wert, denn du in der Firewall entsprechend Priorisieren musst in einer der Outgoing Queue.
Auch wenn du genügend Bandbreite hast zahlt sich die VoIP Priorisierung immer aus.
Nur um das nochmal klar zu machen: Die fehlende Priorisierung ist NICHT Ursache der Kommunikationsstörung. Das ist vermutlich ein fälschlich konfiguriertes NAT im VPN Tunnel. Aber auch das ist erstmal nur geraten aufgrund der fehlenden Konfig Infos face-sad
Member: jompsi
jompsi Sep 21, 2015 at 15:08:45 (UTC)
Goto Top
Hallo

Es ist schon so, dass ich in dieser Materie noch nicht so erfahren bin, deshalb melde ich mich auch hier im Forum und erhoffe mir, mein Wissen möglichst schnell zu verbessern. Deshalb tut es mir leid, wenn ich euch zu wenige Angaben gebe oder mich ungeschickt anstelle, aber ich bin für die Hilfe sehr dankbar und reiche die gewünschten Informationen auch sehr gerne nach.

Beim FortiGate Traffic Shaping gibt man die Priority mit an, mit welcher das Protokoll gehandhabt werden soll. Meines Erachtens nach, fliesst bei FortiGate das QoS ins Traffic Shaping mitein.
http://docs-legacy.fortinet.com/fos50hlp/50/index.html#page/FortiOS%252 ...

VPN Konfiguration FortiGate:
config vpn ipsec phase1-interface
    edit "SG"  
        set interface "wan1"  
        set nattraversal disable
        set keylife 28800
        set proposal aes256-sha512
        set dpd disable
        set dhgrp 16
        set remote-gw PUBLIC-IP
        set psksecret dfjsvdsl
    next
end
config vpn ipsec phase2-interface
    edit "SG"  
        set phase1name "SG"  
        set proposal aes256-sha1
        set dhgrp 16
        set keylifeseconds 3600
        set src-subnet 172.200.1.0 255.255.255.0
        set dst-subnet 172.190.1.0 255.255.255.0
    next
end

Firewall für VPN auf der FortiGate:
config firewall policy
    edit 17
        set uuid 05e77718-20b8-51e5-fca6-956d779eb92f
        set srcintf "SRC"  
        set dstintf "IPSEC"  
        set srcaddr "172....."  
        set dstaddr "172....."  
        set action accept
        set schedule "always"  
        set service "RDP" "SMB" "ALL_ICMP" "VNC" "SIP" "Outlook Messenger LAN" "Swyx Anmeldung am Server" "DNS" "HTTPS" "HTTP" "Swyx! CallControl" "Swyx! Audio" "SSH" "iperf"  
        set logtraffic all
    next
end
config firewall policy
    edit 15
        set uuid f40a56c8-20b7-51e5-a4b5-a239a77c555a
        set srcintf "IPSEC"  
        set dstintf "SRC"  
        set srcaddr "172....."  
        set dstaddr "172....."  
        set action accept
        set schedule "always"  
        set service "RDP" "SMB" "ALL_ICMP" "VNC" "SIP" "Outlook Messenger LAN" "Swyx Anmeldung am Server" "DNS" "HTTPS" "HTTP" "Swyx! CallControl" "Swyx! Audio" "SSH" "iperf"  
    next
end
Bei diesen Rules ist das NATing deaktiviert.

VPN Konfiguration des Edge Routers:
authentication {
         mode pre-shared-secret
         pre-shared-secret gnfnhgnd
     }
     connection-type initiate
     default-esp-group zh
     description SG-ZH
     ike-group zh
     local-address PUBLIC-IP
     tunnel 1 {
         allow-nat-networks disable
         allow-public-networks disable
         esp-group zh
         local {
             prefix 172.190.1.0/24
         }
         remote {
             prefix 172.200.1.0/24
         }
     }

Ich hoffe, dass dies die richtigen Informationen sind. Wenn nicht, könnt ihr mir bitte sagen, was ihr explizit braucht?

Vielen Dank an alle, welche sich die Zeit nehmen und mir helfen face-smile

Freundliche Grüsse
Joel
Member: aqui
aqui Sep 21, 2015 at 15:44:59 (UTC)
Goto Top
Fehlt irgendwie "set service "RTP" ???
RTP (Realtime tRansaction Protocol" transportiert die Sprachdaten !!! SIP stell nur die Verbindung her.
Ohne RTP keine Sprache ! Kein Wunder das es dann nicht geht !

Tip:
Installiere ein kostenloses Softphone wie "Phoner" http://www.phoner.de und zusätzlich den Wireshark.
Dann rufst du das Softphone an und lässt den Wireshark laufen.
Hebst ab und checkst die Kommunikation.
Hier kannst du dann sehen ob SIP UND auch RTP Daten eingehen !
Außerdem zeigt dir der Wireshark wie einfach du VoIP Gespräche mitschnüffeln kannst...das aber nur nebenbei.
Member: jompsi
jompsi Sep 22, 2015 updated at 08:03:30 (UTC)
Goto Top
Guten Morgen

Vielen Dank @aqui. Den Phoner brauche ich gar nicht, da unsere Swyx Anlage mit Softphones läuft. Bei unserem Hauptstandort sehe ich in Wireshark den RTP Traffic.

Muss zu unserem zweiten Standort gehen um diesen Test auch dort durchzuführen. Werde versuchen das morgen zu machen.

Auch vielen Dank an dich @Dirmhirn
kann es sein, dass es einen Unterschied macht ob ihr die Externe oder interne Durchwahl/Nummer wählt?
Werde ich versuchen, wenn ich beim Aussenstandort bin.

Gruss
Joel
Member: jompsi
jompsi Sep 23, 2015 updated at 08:33:44 (UTC)
Goto Top
Hallo zusammen

Habe nun ein paar Tests vom zweiten Standort aus gemacht.

Tests:
1. Habe vom zweiten Standort her vier Benutzer beim Hauptstandort angerufen. Das Telefonat hat mit drei Benutzern funktioniert und nur mit einem Benutzer funktioniert es nicht. Das ist sehr komisch. In Wireshark sehe ich bei allen Telefonaten RTP Packete. Was mir aber aufgefallen ist, ist dass ich beim Telefonat mit dem Benutzer, mit welchem es nicht funktioniert, nur meine RTP Audiospur habe. Die Audiospur von der Gegenseite ist nicht vorhanden(Wireshark -> Telephony -> RTP -> Stream Analysis -> Player -> Decode -> Es ist nur eine Audiospur vorhanden).

2. Es macht keinen Unterschied, ob ich die externe oder interne Durchwahl nehme. Der eine Benutzer funktioniert einfach nicht.

3. Das Telefonat funktioniert aber, wenn mich der Benutzer anruft. Das heisst: "Aussenstandort -> Hauptstandort" = Telefonie funktioniert nicht. "Hauptstandort -> Aussenstandort" = Telefonie funktioniert.

4. Der Aussenstandort kann Mobiltelefone anrufen und auch von jenen angerufen werden.

5. Scheint, als ob es mit einzelnen internen Anrufen nicht funktioniert. Hauptsächlich Aussenstandort -> Hauptstandort.

Könnt Ihr hieraus eine Schlussfolgerung ziehen? Mir fällt es schwer.

Vielen Dank und freundliche Grüsse
Joel
Member: aqui
aqui Sep 23, 2015 at 17:23:00 (UTC)
Goto Top
Die Schlussfolgerung ist doch eindeutig:
Wenn von 4 Telefonen 3 in allen Konstellationen telefonieren können und nur eins mit den selben Rahmendebingungen nicht, dann ist:
a.) das Telefon falsch konfiguriert
b.) das Telefon defekt.
Andere Optionen hast du nicht.
GermanQuestionVoice over IPNetworks
Hotly discussed
gleixnerdCheck of ZFW Firewallgleixnerd - 3 CommentsAlexWishaHow to set up and configure a Linux GRE tunnelAlexWisha - 3 CommentsjstrickerWIREGUARD VPN ON UDM PRO BEHIND FRITZBOX - HANDSHAKE DID NOT COMPLETEjstricker - 3 CommentsDaniEnd of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment