11
VOIP Problem über IPSec
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
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 283486
Url: https://administrator.de/contentid/283486
Ausgedruckt am: 05.11.2024 um 12:11 Uhr
11 Kommentare
Neuester Kommentar
Guten Morgen,
habt ihr QoS für VoIP aktiviert?
Gruß
Neomatic
habt ihr QoS für VoIP aktiviert?
Gruß
Neomatic
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
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
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
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
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
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
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.
kann es sein, dass es einen Unterschied macht ob ihr die Externe oder interne Durchwahl/Nummer wählt?
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
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
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.
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
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
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:
Firewall für VPN auf der FortiGate:
Bei diesen Rules ist das NATing deaktiviert.
VPN Konfiguration des Edge Routers:
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
Freundliche Grüsse
Joel
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
endFirewall 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
endVPN 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
Freundliche Grüsse
Joel
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.
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.
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
Gruss
Joel
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
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
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
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.
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.
