3
Sophos XG VPN IPSec und Site 2 Site
Guten Morgen zusammen,
ich bin mit meinem Netzwerk Latein aktuell leider am Ende und kann vor lauter IP Subnetzen nicht mehr klar denken.
Unser aktueller Sophos Dienstleister ist derzeit verhindert und kann leider nicht unterstützen.
Mal eine kleine Zeichnungs des Konstruktes. (Leider sehr unübersichtlich bei uns)
Wir haben derzeit 5 Außenstandorte und einen Hauptstandort.
Die Subnetze sind entsprechend beschrieben und es handelt sich jeweils um das große /16 Netz, welches in viele kleine /22 und /24 Netze geteilt ist.
Am Freitag den 29.11.19 haben wir unsere bisherige MPLS Standortvernetzung mit einem Dienstleister aufgelöst und die Vernetzung nun selber übernommen.
Grundlegend ist an jedem Standort eine Telekom 250/100 MBit Leitung vorhanden, wo ein DrayTek Vigor 165 das Modem bereitstellt und die Sophos XG115w die Netzeinwahl macht.
Am Hauptstandort steht eine Sophos XG310 (2. soll als passiv HA konfiguriert werden) mit einer LWL Standeitung mit 250/250 MBit.
Unsere Telefonie läuft derzeit in der Cloud (Avaya Aura) und muss daher via VPN angesprochen werden.
Die alten 10.0.108/22 etc. Netze wurden vom MPLS Betreiber übernommen, da weniger Konfig Anpassung bei unserem TK Dienstleister.
Soweit so gut.
Der IPSec VPN Tunnel zur TK Anlage steht und die Telefone können telefonieren.
Nun aber zu den Problemen.....
- teilweise kein Freizeichen
- Telefonbuch am Endgerät funktioniert nicht
- Außenstandort 5/6 können sich nicht gegenseitig intern anrufen
- Routing Probleme im Hauptstandort und Außenstandort
Ich vermute mal dass das Anliegen hier im Forum den Rahmen sprengen wird.
Daher nehme ggf. auch gerne Untersützung eines DL an. (PLZ: 30916)
Der TK Dienstleister teilte mir folgendes mit:
Damit die "Browser Funktion" im Avaya Telefon funktioniert, müssen die Telefone das 10.100er Netz (16er Maske) von "Hauptstandort" aus erreichen.
Das müssen sie bei sich im Routing einstellen (freigeben).
Jetzt komme ich und denke mir....hm der IPSec Tunnel steht und die Telefone kommunizieren alle mit den IP-Adressen:
10.100.101.33 & 10.100.101.115
(Callserver)
Warum sollte dann also nur die "Browser Funktion" gestört sein?!
Am Routing selbst an der XG310 kann ich nichts machen, da die Routen ja automatisch mit dem iPSec Tunnel kommen.
Ein Route Lookup von der XG310 zeigt folgendes auf:
10.100.101.33 is located on the ipsec0
10.100.101.33 is not behind a router.
Von einer XG115w (Außenstelle):
10.100.101.33 is located on the tun1
10.100.101.33 is reached through the router 10.10.190.1 [XG 310 S2S VPN]
Ein Ping auf die Adressen: 10.100.101.33 & 10.100.101.115 ist nicht möglich.
Ein Traceroute der Firewall landet im timeout.
Sobald ich nun versuche von einem Client im VLAN 12 am Hauptstandort (XG 310) einen Tracert zu fahren kommen ich wie folgt raus:
PS C:\WINDOWS\system32> tracert 10.100.101.33
Routenverfolgung zu 10.100.101.33 über maximal 30 Hops
1 3 ms 3 ms 2 ms 10.10.23.253 [Gateway für VLAN12 / Core Switche]
2 8 ms 2 ms 3 ms 10.10.250.1 [Transfer VLAN 250 zwischen Core Switchen und XG310]
3 21 ms 17 ms 19 ms 81.XX.XXX.145 [Unsere WAN IP-Adresse?????]
4 *
Was kann hier der Fehler sein?
Ich weiß ich hole sehr weit aus und das ist leider nichtmal das gesamte Netzwerk. (Wie oben erwähnt haben wir auch noch 4 Core Switche, welche div. Netze am Hauptstandort routen)
Unter anderen Routen die Core Switche auch das VLAN 50 (10.0.108.0/22) am Hauptstandort.
Ich bin für jeden Gedankenanstoß DANKBAR!!!
Liebe Grüße
ich bin mit meinem Netzwerk Latein aktuell leider am Ende und kann vor lauter IP Subnetzen nicht mehr klar denken.
Unser aktueller Sophos Dienstleister ist derzeit verhindert und kann leider nicht unterstützen.
Mal eine kleine Zeichnungs des Konstruktes. (Leider sehr unübersichtlich bei uns)
Wir haben derzeit 5 Außenstandorte und einen Hauptstandort.
Die Subnetze sind entsprechend beschrieben und es handelt sich jeweils um das große /16 Netz, welches in viele kleine /22 und /24 Netze geteilt ist.
Am Freitag den 29.11.19 haben wir unsere bisherige MPLS Standortvernetzung mit einem Dienstleister aufgelöst und die Vernetzung nun selber übernommen.
Grundlegend ist an jedem Standort eine Telekom 250/100 MBit Leitung vorhanden, wo ein DrayTek Vigor 165 das Modem bereitstellt und die Sophos XG115w die Netzeinwahl macht.
Am Hauptstandort steht eine Sophos XG310 (2. soll als passiv HA konfiguriert werden) mit einer LWL Standeitung mit 250/250 MBit.
Unsere Telefonie läuft derzeit in der Cloud (Avaya Aura) und muss daher via VPN angesprochen werden.
Die alten 10.0.108/22 etc. Netze wurden vom MPLS Betreiber übernommen, da weniger Konfig Anpassung bei unserem TK Dienstleister.
Soweit so gut.
Der IPSec VPN Tunnel zur TK Anlage steht und die Telefone können telefonieren.
Nun aber zu den Problemen.....
- teilweise kein Freizeichen
- Telefonbuch am Endgerät funktioniert nicht
- Außenstandort 5/6 können sich nicht gegenseitig intern anrufen
- Routing Probleme im Hauptstandort und Außenstandort
Ich vermute mal dass das Anliegen hier im Forum den Rahmen sprengen wird.
Daher nehme ggf. auch gerne Untersützung eines DL an. (PLZ: 30916)
Der TK Dienstleister teilte mir folgendes mit:
Damit die "Browser Funktion" im Avaya Telefon funktioniert, müssen die Telefone das 10.100er Netz (16er Maske) von "Hauptstandort" aus erreichen.
Das müssen sie bei sich im Routing einstellen (freigeben).
Jetzt komme ich und denke mir....hm der IPSec Tunnel steht und die Telefone kommunizieren alle mit den IP-Adressen:
10.100.101.33 & 10.100.101.115
(Callserver)
Warum sollte dann also nur die "Browser Funktion" gestört sein?!
Am Routing selbst an der XG310 kann ich nichts machen, da die Routen ja automatisch mit dem iPSec Tunnel kommen.
Ein Route Lookup von der XG310 zeigt folgendes auf:
10.100.101.33 is located on the ipsec0
10.100.101.33 is not behind a router.
Von einer XG115w (Außenstelle):
10.100.101.33 is located on the tun1
10.100.101.33 is reached through the router 10.10.190.1 [XG 310 S2S VPN]
Ein Ping auf die Adressen: 10.100.101.33 & 10.100.101.115 ist nicht möglich.
Ein Traceroute der Firewall landet im timeout.
Sobald ich nun versuche von einem Client im VLAN 12 am Hauptstandort (XG 310) einen Tracert zu fahren kommen ich wie folgt raus:
PS C:\WINDOWS\system32> tracert 10.100.101.33
Routenverfolgung zu 10.100.101.33 über maximal 30 Hops
1 3 ms 3 ms 2 ms 10.10.23.253 [Gateway für VLAN12 / Core Switche]
2 8 ms 2 ms 3 ms 10.10.250.1 [Transfer VLAN 250 zwischen Core Switchen und XG310]
3 21 ms 17 ms 19 ms 81.XX.XXX.145 [Unsere WAN IP-Adresse?????]
4 *
Was kann hier der Fehler sein?
Ich weiß ich hole sehr weit aus und das ist leider nichtmal das gesamte Netzwerk. (Wie oben erwähnt haben wir auch noch 4 Core Switche, welche div. Netze am Hauptstandort routen)
Unter anderen Routen die Core Switche auch das VLAN 50 (10.0.108.0/22) am Hauptstandort.
Ich bin für jeden Gedankenanstoß DANKBAR!!!
Liebe Grüße
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 521289
Url: https://administrator.de/contentid/521289
Printed on: April 24, 2024 at 14:04 o'clock
3 Comments
Latest comment
Bitte bei den embeddeten Bildern das "+" zeichen an die richtige Stelle setzen, dann erscheinen sie auch im richtigen Kontext des Threads hier !
(Kann man mit dem "Bearbeiten" Button auch noch nachträglich korrigieren !)
Zurück zum Thema...
Die Fehler des Telefons und die 5 und 6er Erreichbarkeit zeigen sehr wahrscheinlich auf ein Firewall Regel Problem. Da all diese Infos fehlen von dir kann man erstmal nur im freien Fall raten.
Das schon ein Anruf scheitert zeigt entweder das SIP (TCP/UDP Port 5060) nicht durchkommt oder die Regeln dafür fehlen. Fehlt das Audio ein- oder beidseitig stimmt was mit der RTP Regel nicht. RTP transportiert die reinen Telefonie Audio Daten.
Normal sollte man in den Tunnel Interfaces erstmal Schrotschussregeln implementieren die alles erlauben und dann später wenn alles rennt dann langsam dichtziehen um sich nicht beim Aufbau vorab selber Fallen zu stellen. Also immer strategisch vorgehen ist hier die Devise.
Das Ping und Traceroute Timeout hat vermutlich ähnliche Ursachen.
Ping und Traceroute basieren, wie du als Netzwerker ja weisst, auf dem ICMP Protokoll. So gut wie immer ist das in Firewalls immer deaktiviert im Regelwerk ! Hier solltest du also mal genau hinsehen das ICMP erstmal erlaubt ist um das Troubleshooting zu vereinfachen.
Der zweite Grund könnte ein fehlerhaftes Routing sein !!!
Da ihr noch L3 Core Switches betreibt die routen müssen hier natürlich logischerweise statische Routen auf alle Firewall Netze eingetragen sein. Ebenso natürlich die Routen auf den Firewalls selber.
Heisser Tip:
Mit deinen vielen Außenstellen, einen Core Switch/Router vermutlich in HA oder Stack und einem redundanten Firewall Cluster ist es vollkommen kontraproduktiv wenn du statisch routest. Das ist in so einem Design eigentlich ein völliges NoGo, denn all deine Redundanz Bemühungen mit Core und FW Cluster werden damit konterkariert, da in einem Failover ggf. manuelle Route Anpassungen zwingend sind. Wie gesagt ein NoGo in einem Firmennetz, denn keiner will in so einem Redundanz Design händisch frickeln im Failover logischerweise.
Dort sollte die Routing Konvergenz immer dynamisch sein.
Sprich du solltest hier immer auf ein dynamisches Routing Konzept mit RIPv2 oder OSPF setzen was dir auch das Troubleshooting erheblich erleichtert.
Wie so ein Konzept aussehen kann kannst du hier nachlesen !
Das ist aber nur mal ein Denkanstoß für die Zukunft und hier jetzt erstmal nicht das Thema !
Ein weiteres gravierendes IP Adressproblem hast du ebenso nach deiner Zeichnung !
Das VoIP Netz an Standort 3 hat die 10.0.148.0 /16 was dann sämtliche 10.0.x.y IP Netze inkludiert !
Damit sind alle anderen VoIP Netze nicht mehr routebar, was dann auch Ping und Connectivity Probleme bei den VoIP Netzen erklärt.
Um dich nicht zu verzetteln solltest du vom Hauptstandort immer Standort für Standort vorgehen. Also immer einen Standort vollständig und getestet zum laufen bringen, dann den nächsten. So kannst du auch sukzessive Fehler vermeiden, denn sowie es Problem gibt weisst du ja dann sicher das nur der neu zugeschaltete Standort der Verursacher sein kann !
Jede Standort Konfig ist ja immer ein Klon der anderen mit Ausnahme ihrer individuellen IP.
Das nur mal als erster Schrotschuss ohne detailierte Infos von deiner Seite....
(Kann man mit dem "Bearbeiten" Button auch noch nachträglich korrigieren !)
Zurück zum Thema...
und kann vor lauter IP Subnetzen nicht mehr klar denken.
Dann solltest du erstmal tief durchatmen an der frischen Luft und dir dann einen Kaffee holen !Ich vermute mal dass das Anliegen hier im Forum den Rahmen sprengen wird.
Kommt drauf an....Die Fehler des Telefons und die 5 und 6er Erreichbarkeit zeigen sehr wahrscheinlich auf ein Firewall Regel Problem. Da all diese Infos fehlen von dir kann man erstmal nur im freien Fall raten.
Das schon ein Anruf scheitert zeigt entweder das SIP (TCP/UDP Port 5060) nicht durchkommt oder die Regeln dafür fehlen. Fehlt das Audio ein- oder beidseitig stimmt was mit der RTP Regel nicht. RTP transportiert die reinen Telefonie Audio Daten.
Normal sollte man in den Tunnel Interfaces erstmal Schrotschussregeln implementieren die alles erlauben und dann später wenn alles rennt dann langsam dichtziehen um sich nicht beim Aufbau vorab selber Fallen zu stellen. Also immer strategisch vorgehen ist hier die Devise.
Das Ping und Traceroute Timeout hat vermutlich ähnliche Ursachen.
Ping und Traceroute basieren, wie du als Netzwerker ja weisst, auf dem ICMP Protokoll. So gut wie immer ist das in Firewalls immer deaktiviert im Regelwerk ! Hier solltest du also mal genau hinsehen das ICMP erstmal erlaubt ist um das Troubleshooting zu vereinfachen.
Der zweite Grund könnte ein fehlerhaftes Routing sein !!!
Da ihr noch L3 Core Switches betreibt die routen müssen hier natürlich logischerweise statische Routen auf alle Firewall Netze eingetragen sein. Ebenso natürlich die Routen auf den Firewalls selber.
Heisser Tip:
Mit deinen vielen Außenstellen, einen Core Switch/Router vermutlich in HA oder Stack und einem redundanten Firewall Cluster ist es vollkommen kontraproduktiv wenn du statisch routest. Das ist in so einem Design eigentlich ein völliges NoGo, denn all deine Redundanz Bemühungen mit Core und FW Cluster werden damit konterkariert, da in einem Failover ggf. manuelle Route Anpassungen zwingend sind. Wie gesagt ein NoGo in einem Firmennetz, denn keiner will in so einem Redundanz Design händisch frickeln im Failover logischerweise.
Dort sollte die Routing Konvergenz immer dynamisch sein.
Sprich du solltest hier immer auf ein dynamisches Routing Konzept mit RIPv2 oder OSPF setzen was dir auch das Troubleshooting erheblich erleichtert.
Wie so ein Konzept aussehen kann kannst du hier nachlesen !
Das ist aber nur mal ein Denkanstoß für die Zukunft und hier jetzt erstmal nicht das Thema !
Am Routing selbst an der XG310 kann ich nichts machen, da die Routen ja automatisch mit dem iPSec Tunnel kommen.
Das ist richtig aber dennoch solltest du die Routen am Layer 3 Switch Core wasserdicht checken, denn der Switch Core ist das Default Gateway für alle lokalen VLAN Endgeräte ! (Hoffentlich ?!)Ein weiteres gravierendes IP Adressproblem hast du ebenso nach deiner Zeichnung !
Das VoIP Netz an Standort 3 hat die 10.0.148.0 /16 was dann sämtliche 10.0.x.y IP Netze inkludiert !
Damit sind alle anderen VoIP Netze nicht mehr routebar, was dann auch Ping und Connectivity Probleme bei den VoIP Netzen erklärt.
Um dich nicht zu verzetteln solltest du vom Hauptstandort immer Standort für Standort vorgehen. Also immer einen Standort vollständig und getestet zum laufen bringen, dann den nächsten. So kannst du auch sukzessive Fehler vermeiden, denn sowie es Problem gibt weisst du ja dann sicher das nur der neu zugeschaltete Standort der Verursacher sein kann !
Jede Standort Konfig ist ja immer ein Klon der anderen mit Ausnahme ihrer individuellen IP.
Das nur mal als erster Schrotschuss ohne detailierte Infos von deiner Seite....
Moin,
danke für deinen Input.
Das Bild habe ich nochmal neu eingefügt.
Das Netzwerk am Standort 3 soll auch ein /22 sein, da habe ich mich in der Zeichnung verzettelt.
Folgende Routen sind auf dem VDX Core (4x Brocade VDX 6740 (2x2 Fabric) eingerichtet.
Der Punkt mit den Firewall Regeln....klar die habe ich komplett vergessen.
Auch wenn es sich blöd anhört aber aktuell sind die Standorte via VPN und der IPSec Tunnel via "Any to Any" Regel offen für alles.
Somit existieren keine expliziten Regeln für SIP oder ICMP etc.
danke für deinen Input.
Das Bild habe ich nochmal neu eingefügt.
Das Netzwerk am Standort 3 soll auch ein /22 sein, da habe ich mich in der Zeichnung verzettelt.
Folgende Routen sind auf dem VDX Core (4x Brocade VDX 6740 (2x2 Fabric) eingerichtet.
Destination Gateway Port Cost Type Uptime
0.0.0.0/0 10.10.250.1 Ve 250 1/1 S 3d17h
10.0.108.0/22 DIRECT Ve 50 0/0 D 3d18h
10.0.108.1/32 DIRECT Ve 50 0/0 D 3d17h
10.0.111.251/32 DIRECT Ve 50 0/0 D 3d18h
10.10.0.0/22 DIRECT Ve 2 0/0 D 61d14h
10.10.3.250/32 DIRECT Ve 2 0/0 D 61d14h
10.10.3.251/32 DIRECT Ve 2 0/0 D 61d14h
10.10.8.0/22 DIRECT Ve 8 0/0 D 61d14h
10.10.11.250/32 DIRECT Ve 8 0/0 D 61d14h
10.10.11.251/32 DIRECT Ve 8 0/0 D 61d14h
10.10.12.0/22 DIRECT Ve 12 0/0 D 61d14h
10.10.15.250/32 DIRECT Ve 12 0/0 D 61d14h
10.10.15.251/32 DIRECT Ve 12 0/0 D 61d14h
10.10.16.0/22 DIRECT Ve 16 0/0 D 61d14h
10.10.19.250/32 DIRECT Ve 16 0/0 D 61d14h
10.10.19.251/32 DIRECT Ve 16 0/0 D 61d14h
10.10.20.0/22 DIRECT Ve 20 0/0 D 61d14h
10.10.23.250/32 DIRECT Ve 20 0/0 D 61d14h
10.10.23.251/32 DIRECT Ve 20 0/0 D 61d14h
10.10.24.0/22 DIRECT Ve 24 0/0 D 61d14h
10.10.27.250/32 DIRECT Ve 24 0/0 D 61d14h
10.10.27.251/32 DIRECT Ve 24 0/0 D 61d14h
10.10.42.0/24 DIRECT Ve 42 0/0 D 61d14h
10.10.42.250/32 DIRECT Ve 42 0/0 D 61d14h
10.10.42.251/32 DIRECT Ve 42 0/0 D 61d14h
10.10.82.0/24 DIRECT Ve 82 0/0 D 61d14h
10.10.82.250/32 DIRECT Ve 82 0/0 D 61d14h
10.10.82.251/32 DIRECT Ve 82 0/0 D 61d14h
10.10.101.0/24 DIRECT Ve 101 0/0 D 61d14h
10.10.101.250/32 DIRECT Ve 101 0/0 D 61d14h
10.10.101.251/32 DIRECT Ve 101 0/0 D 61d14h
10.10.250.0/24 DIRECT Ve 250 0/0 D 61d14h
10.10.250.250/32 DIRECT Ve 250 0/0 D 61d14h
10.10.250.251/32 DIRECT Ve 250 0/0 D 61d14h
10.10.254.0/24 DIRECT Ve 254 0/0 D 61d14h
10.10.254.250/32 DIRECT Ve 254 0/0 D 61d14h
10.10.254.251/32 DIRECT Ve 254 0/0 D 61d14hDer Punkt mit den Firewall Regeln....klar die habe ich komplett vergessen.
Auch wenn es sich blöd anhört aber aktuell sind die Standorte via VPN und der IPSec Tunnel via "Any to Any" Regel offen für alles.
Somit existieren keine expliziten Regeln für SIP oder ICMP etc.
Hallo,
vermute, dass die Routingeinträge nicht passen,
Der Block spricht dafür. Aber wie du schon sagst, das sprengt das Forum, wenn man sich da rein verkopfen soll, klopf mal an, soweit Remote gewünscht wird bzw OK ist.
VG,
Christian
vermute, dass die Routingeinträge nicht passen,
Die alten 10.0.108/22 etc. Netze wurden vom MPLS Betreiber übernommen, da weniger Konfig Anpassung bei unserem TK Dienstleister.
Soweit so gut.
Der IPSec VPN Tunnel zur TK Anlage steht und die Telefone können telefonieren.
Nun aber zu den Problemen.....
- teilweise kein Freizeichen - tw. falsches Routing
- Telefonbuch am Endgerät funktioniert nicht - dito oder FW
- Außenstandort 5/6 können sich nicht gegenseitig intern anrufen - Routing oder TK?
- Routing Probleme im Hauptstandort und Außenstandort - ganz klar...VG,
Christian
