6
UDP 4500 von ISP für eine einzige Adresse geblockt?
Hallöchen,
Ich bin neu hier und stelle mich am besten erst mal kurz vor:
Mein Name ist Max, ich arbeite in einem kleineren Unternehmen in München und beschäftige mich dort hauptsächlich mit Networking und VoIP.
Seit einiger Zeit arbeiten wir auch an dem Thema SD-WAN (derzeit hauptsächlich mit Riverbed) und betreuen unseren ersten großen Kunden in diesem Feld,
für den wir derzeit Firewalls in allen Standorten austauschen.
Die implementierung läuft recht gut, nur kleine Fehler die alle auf fehlerhafte informationen und co zurückzuführen sind.
Nun schlage ich mich aber mit einem Problem herum, das mir einfach nur unerklärlich bleibt.
Der Kunde hat weltweit Standorte und dazu zwei Rechenzentren in Deutschland.
Das sind etwas über 60 Firewalls der Firma Riverbed, die wir für den Kunden verwalten und die untereinander VPN-mäßig vollvermascht sind (Tunnel werden automatisch ausgehandelt).
seit gestern ist jedoch exakt ein Tunnel zwischen dem Standort in Chennai (Indien) und dem RZ in Hamburg auf einmal weggefallen.
Nach einem schönen Abend voller Troubleshooting mit dem Support von Riverbed stellte sich heraus, das einseitig, also nur von Deutschland nach Indien UDP 4500 Pakete nicht durchkommen.
Befund seitens Riverbed: Netzwerkfehler, irgendetwas blockt UDP 4500.
Das wäre auch plausibel, würden nicht alle anderen Tunnel in beiden locations (immerhin jeweils über 60) anstandslos ihre Aufgabe verrichten.
Die einzige Möglichkeit, die ich sehe: einer der ISPs blockt eine spezifische Adresse. Es kann auch nicht länderspezifisch sein.
Wir haben in beiden Ländern mehrere Standorte, in Hamburg sogar zwei direkt nebeneinander.
Ich wollte den Fall hier einfach mal einstellen um zu erfragen, ob ihr schon ähnliche Probleme hattet.
Sperren Provider einfach einzelne IP-Adressen?
Habt ihr noch eine Idee, was genau den Port von UDP 4500 für exakt eine route blocken könnte?
Vielen Dank schon mal, sollte noch etwas unklar sein, fragt einfach.
Ich bin für jede Idee dankbar.
Ich bin neu hier und stelle mich am besten erst mal kurz vor:
Mein Name ist Max, ich arbeite in einem kleineren Unternehmen in München und beschäftige mich dort hauptsächlich mit Networking und VoIP.
Seit einiger Zeit arbeiten wir auch an dem Thema SD-WAN (derzeit hauptsächlich mit Riverbed) und betreuen unseren ersten großen Kunden in diesem Feld,
für den wir derzeit Firewalls in allen Standorten austauschen.
Die implementierung läuft recht gut, nur kleine Fehler die alle auf fehlerhafte informationen und co zurückzuführen sind.
Nun schlage ich mich aber mit einem Problem herum, das mir einfach nur unerklärlich bleibt.
Der Kunde hat weltweit Standorte und dazu zwei Rechenzentren in Deutschland.
Das sind etwas über 60 Firewalls der Firma Riverbed, die wir für den Kunden verwalten und die untereinander VPN-mäßig vollvermascht sind (Tunnel werden automatisch ausgehandelt).
seit gestern ist jedoch exakt ein Tunnel zwischen dem Standort in Chennai (Indien) und dem RZ in Hamburg auf einmal weggefallen.
Nach einem schönen Abend voller Troubleshooting mit dem Support von Riverbed stellte sich heraus, das einseitig, also nur von Deutschland nach Indien UDP 4500 Pakete nicht durchkommen.
Befund seitens Riverbed: Netzwerkfehler, irgendetwas blockt UDP 4500.
Das wäre auch plausibel, würden nicht alle anderen Tunnel in beiden locations (immerhin jeweils über 60) anstandslos ihre Aufgabe verrichten.
Die einzige Möglichkeit, die ich sehe: einer der ISPs blockt eine spezifische Adresse. Es kann auch nicht länderspezifisch sein.
Wir haben in beiden Ländern mehrere Standorte, in Hamburg sogar zwei direkt nebeneinander.
Ich wollte den Fall hier einfach mal einstellen um zu erfragen, ob ihr schon ähnliche Probleme hattet.
Sperren Provider einfach einzelne IP-Adressen?
Habt ihr noch eine Idee, was genau den Port von UDP 4500 für exakt eine route blocken könnte?
Vielen Dank schon mal, sollte noch etwas unklar sein, fragt einfach.
Ich bin für jede Idee dankbar.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 339962
Url: https://administrator.de/forum/udp-4500-von-isp-fuer-eine-einzige-adresse-geblockt-339962.html
Ausgedruckt am: 14.04.2025 um 16:04 Uhr
6 Kommentare
Neuester Kommentar
Hi,
Sind die State Tables auf beiden Firewalls geprüft und ggf. zurückgesetzt worden ? (Vorsicht ein Zurücksetzen killt alle bestehenden Tunnel).
Ist der Provider vor Ort kontaktiert worden ? vielleicht ist es ein Fehler in dem Router beim Kunden.
Was passiert wenn ihr die Rolle Initiator / Responder tauscht ?
Gruß
CH
Sperren Provider einfach einzelne IP-Adressen?
Üblicherweise: NeinHabt ihr noch eine Idee, was genau den Port von UDP 4500 für exakt eine route blocken könnte?
Nein, vielleicht aber noch ein paar Anregungen zur Fehlersuche.Sind die State Tables auf beiden Firewalls geprüft und ggf. zurückgesetzt worden ? (Vorsicht ein Zurücksetzen killt alle bestehenden Tunnel).
Ist der Provider vor Ort kontaktiert worden ? vielleicht ist es ein Fehler in dem Router beim Kunden.
Was passiert wenn ihr die Rolle Initiator / Responder tauscht ?
Gruß
CH
1
Erstmal Danke für deine Antwort.
Anregungen sind immer gerne gesehen.
Riverbed ist leider etwas verschlossen, was den Aufbau der Tunnel angeht.
Diese werden komplett automatisiert verhandelt ohne das man eingreifen kann.
Das ist zwar bei so vielen Standorten nicht unpraktisch, schränkt aber ein.
Rollentausch ist damit leider nicht möglich. Wer zuerst kommt, malt zuerst.
State Tables wurden gesäubert, das Problem bleibt bestehen. Bleibt auch der exakt gleiche Tunnel.
Mit dem Provider bin ich gerade im Gespräch, hätte aber gerne erst ein paar Ideen, nach was ich überhaupt suchen soll.
Ich hatte an eine automatisierte Blacklist oder so gedacht. (Sehr unwahrscheinlich)
die Sprachbarriere verlangsamt die Sache aber natürlich auch ein wenig.
Hier noch ein dump bezüglich der des Aufbaus, falls das hilft. 118 ist Indien, 194 ist Deutschland
[I] Init
[R] Response
root@XNBE4AB0XXX:~# tcpdump -nnr case_863609_XNBE4AB0XXX.pcap reading from file case_863609_XNBE4AB0XXX.pcap, link-type EN10MB (Ethernet)
01:15:42.484678 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
01:15:46.484206 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
01:15:53.684667 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
01:16:06.644944 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
01:16:29.973160 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
root@XNF28572XXX:~# tcpdump -nnr case_863609_XNF28572XXX.pcap reading from file case_863609_XNF28572XXX.pcap, link-type EN10MB (Ethernet)
21:45:01.515622 IP 194.15.xxx.xxx.4500 > 118.102.xxx.xx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
21:45:42.590569 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
21:45:42.628655 IP 194.15.xxx.xxx.4500 > 118.102.xxx.xx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[R]
21:45:43.505927 IP 194.15.xxx.xxx.4500 > 118.102.xxx.xx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
21:45:46.589982 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
21:45:46.590549 IP 194.15.xxx.xxx.4500 > 118.102.xxx.xx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[R]
21:45:53.790471 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
21:45:53.791012 IP 194.15.xxx.xxx.4500 > 118.102.xxx.xx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[R]
21:46:06.750647 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
21:46:06.751195 IP 194.15.xxx.xxx.4500 > 118.102.xxx.xx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[R]
21:46:30.078771 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
21:46:30.116450 IP 194.15.xxx.xxx.4500 > 118.102.xxx.xx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[R]
Wie man sieht, antwortet Deutschland auf die Initialisierungsversuche von Indien, aber das Paket verschwindet wohl auf dem Weg.
Anregungen sind immer gerne gesehen.
Riverbed ist leider etwas verschlossen, was den Aufbau der Tunnel angeht.
Diese werden komplett automatisiert verhandelt ohne das man eingreifen kann.
Das ist zwar bei so vielen Standorten nicht unpraktisch, schränkt aber ein.
Rollentausch ist damit leider nicht möglich. Wer zuerst kommt, malt zuerst.
State Tables wurden gesäubert, das Problem bleibt bestehen. Bleibt auch der exakt gleiche Tunnel.
Mit dem Provider bin ich gerade im Gespräch, hätte aber gerne erst ein paar Ideen, nach was ich überhaupt suchen soll.
Ich hatte an eine automatisierte Blacklist oder so gedacht. (Sehr unwahrscheinlich)
die Sprachbarriere verlangsamt die Sache aber natürlich auch ein wenig.
Hier noch ein dump bezüglich der des Aufbaus, falls das hilft. 118 ist Indien, 194 ist Deutschland
[I] Init
[R] Response
root@XNBE4AB0XXX:~# tcpdump -nnr case_863609_XNBE4AB0XXX.pcap reading from file case_863609_XNBE4AB0XXX.pcap, link-type EN10MB (Ethernet)
01:15:42.484678 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
01:15:46.484206 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
01:15:53.684667 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
01:16:06.644944 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
01:16:29.973160 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
root@XNF28572XXX:~# tcpdump -nnr case_863609_XNF28572XXX.pcap reading from file case_863609_XNF28572XXX.pcap, link-type EN10MB (Ethernet)
21:45:01.515622 IP 194.15.xxx.xxx.4500 > 118.102.xxx.xx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
21:45:42.590569 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
21:45:42.628655 IP 194.15.xxx.xxx.4500 > 118.102.xxx.xx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[R]
21:45:43.505927 IP 194.15.xxx.xxx.4500 > 118.102.xxx.xx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
21:45:46.589982 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
21:45:46.590549 IP 194.15.xxx.xxx.4500 > 118.102.xxx.xx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[R]
21:45:53.790471 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
21:45:53.791012 IP 194.15.xxx.xxx.4500 > 118.102.xxx.xx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[R]
21:46:06.750647 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
21:46:06.751195 IP 194.15.xxx.xxx.4500 > 118.102.xxx.xx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[R]
21:46:30.078771 IP 118.102.xxx.xx.4500 > 194.15.xxx.xxx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[I]
21:46:30.116450 IP 194.15.xxx.xxx.4500 > 118.102.xxx.xx.4500: NONESP-encap: isakmp: parent_sa ikev2_init[R]
Wie man sieht, antwortet Deutschland auf die Initialisierungsversuche von Indien, aber das Paket verschwindet wohl auf dem Weg.
UDP 4500 ist NAT Traversal und ein Teil der IPsec Protokollsuite, damit ESP Pakete (IP Protokoll Nummer 50) problemlos NAT (IP Adress Translation) Router und Firewalls überwinden kann. Ohne NAT-T wäre das unmöglich und IPsec basierte VPNs würden an jedem NAT Prozess scheitern.
In der Regel blockt das kein Provider, jedenfalls nicht in freien Gesellschaften. Bei Providern in totalitären Staaten muss man aber davon ausgehen das die das machen um so VPNs zu verhindern mit dem staatlich kontrollierte Firewall Politik umgangen wird.
Indien dürfte eigentlich nicht dazu gehören... Hamburg als freie und Hansestadt schonmal gar nicht
Die andere Option sind Mobilfunkprovider. Hat man dort einen billigen nur Surf Account, dann blocken die Provider diesen Port denn VPNs sind oft den teureren Business Tarifen vorenthalten.
Auch das ist ja sicher nicht bei dir der Fall da du ja sicherlich kabelgebundene Netze einsetzt.
Vermutlich kannst du dich da nur an den Provider direkt wenden wenn das wirklich gefiltert wird. Oder....
Du schlägst ihm ein Schnippchen und verwendest ein SSL basiertes VPN wie z.B. OpenVPN
Nebenbei: Bei IPsec ESP werden VPN Tunnel niemals "automatisch" ausgehandelt. Das ist IP technischer Quatsch.
Woher hast du diesen Unsinn ?
In der Regel blockt das kein Provider, jedenfalls nicht in freien Gesellschaften. Bei Providern in totalitären Staaten muss man aber davon ausgehen das die das machen um so VPNs zu verhindern mit dem staatlich kontrollierte Firewall Politik umgangen wird.
Indien dürfte eigentlich nicht dazu gehören... Hamburg als freie und Hansestadt schonmal gar nicht
Die andere Option sind Mobilfunkprovider. Hat man dort einen billigen nur Surf Account, dann blocken die Provider diesen Port denn VPNs sind oft den teureren Business Tarifen vorenthalten.
Auch das ist ja sicher nicht bei dir der Fall da du ja sicherlich kabelgebundene Netze einsetzt.
Vermutlich kannst du dich da nur an den Provider direkt wenden wenn das wirklich gefiltert wird. Oder....
Du schlägst ihm ein Schnippchen und verwendest ein SSL basiertes VPN wie z.B. OpenVPN
Nebenbei: Bei IPsec ESP werden VPN Tunnel niemals "automatisch" ausgehandelt. Das ist IP technischer Quatsch.
Woher hast du diesen Unsinn ?
Hi Aqui,
Erstmal Danke für deine Antwort.
Ich denke auch, dass das Land Indien hier nicht der Problemfaktor ist.
Wir haben selber noch mehrere Standorte dort und die machen keine Probleme.
Ich werde jetzt erstmal mit dem Provider reden, vielleicht ergibt sich was und die können die Pakete nachvollziehen.
Und wegen der automatischen Aushandlung irrst du dich tatsächlich selber.
Gerade das ist ja die Idee hinter SD-WAN.
Alle Geräte von Riverbed haben eine Verbindung mit der Management-Cloud.
Dort werden die Konfigs bearbeitet, die anschließend dann auf die einzelnen Geräte geshipped werden.
Die Geräte selber sind eigentlich relativ dumm und wird nicht angefasst.
Tunnel werden nach IKEv2 komplett eigenständig über das Management ausgehandelt.
So werden dann alle Standorte vollvermascht.
Will man einen Tunnel zu einem nicht-Riverbed Gerät aufbauen, muss der natürlich manuell eingerichtet werden.
Aber in einer homogenen Umgebung funktioniert das echt gut. Der Fehlerfaktor Mensch fällt weg.
Außer natürlich in Fällen wie diesem...
Danke dir und wünscht mir Glück.
Erstmal Danke für deine Antwort.
Ich denke auch, dass das Land Indien hier nicht der Problemfaktor ist.
Wir haben selber noch mehrere Standorte dort und die machen keine Probleme.
Ich werde jetzt erstmal mit dem Provider reden, vielleicht ergibt sich was und die können die Pakete nachvollziehen.
Und wegen der automatischen Aushandlung irrst du dich tatsächlich selber.
Gerade das ist ja die Idee hinter SD-WAN.
Alle Geräte von Riverbed haben eine Verbindung mit der Management-Cloud.
Dort werden die Konfigs bearbeitet, die anschließend dann auf die einzelnen Geräte geshipped werden.
Die Geräte selber sind eigentlich relativ dumm und wird nicht angefasst.
Tunnel werden nach IKEv2 komplett eigenständig über das Management ausgehandelt.
So werden dann alle Standorte vollvermascht.
Will man einen Tunnel zu einem nicht-Riverbed Gerät aufbauen, muss der natürlich manuell eingerichtet werden.
Aber in einer homogenen Umgebung funktioniert das echt gut. Der Fehlerfaktor Mensch fällt weg.
Außer natürlich in Fällen wie diesem...
Danke dir und wünscht mir Glück.
Alle Geräte von Riverbed haben eine Verbindung mit der Management-Cloud.
Igitt...die telefonieren also nach Hause ? Und das nennt sich dann sicher ?? Fatal bei VPNs. Vermutlich stehen dann die Passwörter dort in der Konfig und das dann bei einem US Unternehmen die die "Cloud" ganz sicher nicht in Europa hat. Dann auch noch den "Fehlerfaktor" Mensch bei sowas auszuschliessen ist schon ziemlich grotesk, aber nundenn. Ein Schelm wer Böses dabei denkt...Normal ein ziemliches NoGo in einem Sicherheitsumfeld wie VPN aber die Bequemlichkeit schreibt manchmal schon komische Blüten...und jeder muss halt wissen was er tut.
Das das über solchen Workaround Trick dann natürlich funktioniert ist klar, denn das ist recht unüblich.
Riverbed ist ja auch bekannt als führender Security Hersteller....kein Wunder also das sowas dabei rauskommt wenn sich fachfremde Firmen über so ein Thema hermachen ?!?
Aber egal...jeden Morgen steht einer auf der so einen Unsinn kauft. No comment.
Naja, grundsätzlich gebe ich dir bezüglich der Gefährdung solcher Cloud-Systeme durchaus recht.
Aber langfristig geht der IT-Markt derzeit auf solche Lösungen zu und auch Vermutungen über die Speicherung von Passwörtern sind nicht gerechtfertigt, solange das nicht fundiert ist. Genauso gut können Kennwörter auch bei anderen Firmen gesnifft werden, obwohl Sie manuell eingetragen sind. Schau dir nur Juniper an.
Die Abteilung, die sich bei Riverbed um Netzwerktechnik kümmert wurde übrigens aus Deutschland aufgekauft, das frühere Ocedo.
Die sitzen auch weiterhin in Deutschland.
Man kann das Management auch self hosted betreiben,
dann liegt die Verantwortung bezüglich Sicherheit halt bei dem jeweiligen Systemhaus oder dem Distributor.
Riverbed-Technik kann ich zum jetzigen Zeitpunktaber aber aus anderen Gründen nicht wirklich empfehlen.
Die Geräte haben derzeit noch massive interne Probleme bezüglich memory etc.
Lancom arbeitet übrigens an einer eigenen SD-WAN Lösung,
die dann komplett in Deutschland gehostet ist und sich nach den Vorgaben der BSI richtet.
Auf die warten wir derzeit sehnlichst.
Naja, ist aber im Endeffekt ja gar nicht das Thema. Ich wollte das nur mal etwas aufdröseln, damit nicht einfach Dinge im Raum stehen.
Und ich finde es auch gerechtfertigt, dass du auf die Sicherheitsfragen hinweißt, ist bei nem amerikanischen Unternehmen ja wirklich ein Punkt.
Nur ein wenig freundlicher hättest du es schon formulieren können.
Aber langfristig geht der IT-Markt derzeit auf solche Lösungen zu und auch Vermutungen über die Speicherung von Passwörtern sind nicht gerechtfertigt, solange das nicht fundiert ist. Genauso gut können Kennwörter auch bei anderen Firmen gesnifft werden, obwohl Sie manuell eingetragen sind. Schau dir nur Juniper an.
Die Abteilung, die sich bei Riverbed um Netzwerktechnik kümmert wurde übrigens aus Deutschland aufgekauft, das frühere Ocedo.
Die sitzen auch weiterhin in Deutschland.
Man kann das Management auch self hosted betreiben,
dann liegt die Verantwortung bezüglich Sicherheit halt bei dem jeweiligen Systemhaus oder dem Distributor.
Riverbed-Technik kann ich zum jetzigen Zeitpunktaber aber aus anderen Gründen nicht wirklich empfehlen.
Die Geräte haben derzeit noch massive interne Probleme bezüglich memory etc.
Lancom arbeitet übrigens an einer eigenen SD-WAN Lösung,
die dann komplett in Deutschland gehostet ist und sich nach den Vorgaben der BSI richtet.
Auf die warten wir derzeit sehnlichst.
Naja, ist aber im Endeffekt ja gar nicht das Thema. Ich wollte das nur mal etwas aufdröseln, damit nicht einfach Dinge im Raum stehen.
Und ich finde es auch gerechtfertigt, dass du auf die Sicherheitsfragen hinweißt, ist bei nem amerikanischen Unternehmen ja wirklich ein Punkt.
Nur ein wenig freundlicher hättest du es schon formulieren können.
