Unitymedia Portsperren bei UM

[Jolander]

Hi

Es ist wohl so, dass UM einige Ports aus Sicherheitsgründen gesperrt hat. Über diese Ports verbreiten sich z.B. Würmer und mit diesen Sperren können fremde User auch nicht mehr auf (irrtümlich) freigegebene Ordner zugreifen.

Es handelt sich um die Ports:
135, 137, 139, 445, 3127, 9898, 4444

Für den Privatanwender sollen sich keinerlei negative Auswirkungen bemerkbar machen.

Ich finde so Massnahmen ja nicht unbedingt verkehrt, aber laut Hotline gibt es keine Portsperren im UM-Netz :super: Komisch nur, dass man auf schriftliche Nachfrage dann doch eine andere Auskunft bekommt. Dies finde ich nicht gerade gelungen.

Die AGB's sichern so Massnahmen ab und danach ist es vollkommen legitim.

Wie steht Ihr dazu?

Wer mit dem Thema "Ports" nichts anfangen kann und Infos braucht
*Wiki*
*Erklärung 1*
*Erklärung 2*

*Sorry! Wusste ich nicht... Durch eine Änderung sind die 4 bisher abgegebenen Votings leider gelöscht worden. Bitte noch einmal voten :traurig: *

 

[avenue]

Das ist aber keine Lösung, da der Virenprogrammierer auf andere Ports ausweicht...
:kafffee:

 

[timmey]

Das ist aber keine Lösung, da der Virenprogrammierer auf andere Ports ausweicht...
:kafffee:

Darum gehts überhaupt nicht. Die genannten Ports sind allesamt well-known Ports, hinter denen sich gewisse (Windows)Services befinden, die in der Vergangenheit oft Einfallstore für Malware waren. Daher könnte man beigehen und die Sperren, damit diese Services grundsätzlich nicht übers Internet ansprechbar sind.

Meine Meinung:
Ein solches Vorgehen hat nichts mehr mit Netzneutralität zu tun und lehne ich daher grundsätzlich ab, auch wenn es bei 99% der Kunden zu keinen Einschränkungen führen wird und ein wenig für Sicherheit sorgen kann

 

[herrsimon]

Anscheinend werden nicht nur Ports gesperrt, sondern auch intern nicht geroutet (siehe auch https://www.unitymediaforum.de/viewtopic.php?f=53&t=5839).
Ich halte diese Praxis für sehr fragwürdig, ein ISP sollte sich eigentlich nicht darum scheren, was auf den Rechnern der Kunden vorgeht. Allerdings ergibt sich seitens Unitymedia natürlich auch das Problem des durch die Würmer etc. verursachten Traffics, der je nach Wurm teilweise mit erheblichen Überlastungen (und damit Beeinträchtigungen aller Nutzer) einhergeht. Bei uns im Netzwerk werden verseuchte Rechner ohne Vorwarnung gesperrt und erst nach Beseitigung des entsprechenden Schadprogramms wieder entsperrt, so eine Praxis wäre natürlich für Unitymedia undenkbar. Alternativ könnte man auch durch Einsatz entsprechender (teurer) Gateways den Traffic auf Applikationsebene filtern, was sich aber meines Wissens kein ISP leisten kann. Unitymedia greift deshalb zur Holzhammer-Methode: Bestimmte Ports werden erst gar nicht geöffnet, also können sich dort auch keine Würmer verbreiten. Falls sich mein Verdacht mit dem internen Routing bewahrheiten sollte geht Unitymedia sogar noch einen Schritt weiter und spielt (Unitymedia-Netz interne) Firewall für den Kunden.
Die meisten gängigen Viren- und Trojanerprobleme des Durchschnittsusers lassen sich damit beheben, der verstümmelte Anschluß kann aber leider nicht mehr für Nicht-Standard-Dinge (Offsite-Backups, VPN etc.) benutzt werden.
Alles in allem finde ich dieses Verhalten nicht in Ordnung.

Simon

 

[Moses]

Ich halte diese Praxis für sehr fragwürdig, ein ISP sollte sich eigentlich nicht darum scheren, was auf den Rechnern der Kunden vorgeht.

Das ist leider Unfung... ein ISP, der sich nicht darum kümmert, was in "seinem" Netz so vor sich geht, läuft ganz schnell Gefahr von anderen ISPs (vollkommen zurecht) ausgesperrt zu werden... gerade kleinere Provider, wie UM, müssen mit dieser Gefahr leben. Bei der Telekom interessiert das natürlich keinen, denn wer die Telekom sperrt, sperrt Deutschland...

Bei uns im Netzwerk werden verseuchte Rechner ohne Vorwarnung gesperrt und erst nach Beseitigung des entsprechenden Schadprogramms wieder entsperrt, so eine Praxis wäre natürlich für Unitymedia undenkbar.

Warum? Genau das macht UM auch... man wird dann von der Hotline angerufen, die mit einem versuchen den PC wieder grade zu biegen, danach gibt's dann auch wieder Internet.

Vernünftige VPN Verbindungen lassen sich übrigens ohne weiteres mit dem UM Anschluss aufbauen und darauf sind dann auch die Ports natürlich wieder zu nutzen, womit dann ein Office-Backup oder die Verbindung zum Exchange Server möglich ist. Klar, geht der MS eingebaute VPN Tunnel auch nicht... aber das ist auch gut, denn der ist ja absolut nicht vernünftig gesichert.

Im übrigen muss man sich fragen, welche privat Personen ein "Office Backup" machen müssen. Denn: UM verkauft nur an Privatkunden, für geschäftliche Zwecke ist der Anschluss nicht gedacht.

 

[piotr]

Klar, geht der MS eingebaute VPN Tunnel auch nicht... aber das ist auch gut, denn der ist ja absolut nicht vernünftig gesichert.

Auf Port 135 ist kein MS VPN.
Das ist der RPC/DCOM Port auf dem viele Dienste in der MS-Welt lauschen, u.a. Exchange.

MS VPN ist entweder PPTP (TCP 1723, GRE-Protokoll) oder L2TP/IPsec ohne NAT-T (UDP 500, UDP 1701, ESP-Protokoll) bzw. L2TP/IPSec mit NAT-T (UDP 500, UDP 1701, UDP 4500).

Der Exchange-Zugriff kann ab Exchange 2003 SP2 mit Outlook ab 2003 SP1 auch ohne VPN hergestellt werden, das laeuft dann ueber einen HTTPS-Tunnel. Das muss nur von den Exchange-Admins konfiguriert werden.

 

[Dr.Spoon]

hmm...könnte das rein theoretisch der grund sein, wieso ich über meinen torrentclient keine verbindung mehr bekomme und wenn dann maximal 10-30kb/s im download da nicht genügend user connecten können.

andersrum, z.B. über den downloadtest von qsc.de kriege ich volle geschwidigkeit.

 

[Moses]

Wenn dein Torrent-Client zufällig auf einem der gesperrten Ports liegt, dann kann das durchaus sein... dann wird sich das ganze durch eine Portänderung im Client ändern lassen. Ansonsten hat das ganze nix damit zu tun.

 

[rallis]

Hallo,

weiss jemand ob es mittlerweile eine komplette Liste gibt? Die man vielleicht per Mail bekommen kann? Oder sind das die oben aufgefuehrten Ports alle?

Edit\ hatte noch ein Portproblem mit meinem DLink Router, was gluecklicherweise nun geloest ist...

 

[Moses]

Das oben sind alle bekannten... mehr machen aber auch keinen Sinn.

 

[ecosys]

Vernünftige VPN Verbindungen lassen sich übrigens ohne weiteres mit dem UM Anschluss aufbauen und darauf sind dann auch die Ports natürlich wieder zu nutzen, womit dann ein Office-Backup oder die Verbindung zum Exchange Server möglich ist. Klar, geht der MS eingebaute VPN Tunnel auch nicht... aber das ist auch gut, denn der ist ja absolut nicht vernünftig gesichert.

Hallo

Ich will mich mal als Leichenschänder betätigen :zwinker:

Was sind vernünftige VPN Verbindungen?
Ich versuche schon seit drei Wochen eine VPN Verbindung von meinem Anschluß zur Firma herzustellen.
Das klappt leider nur bedingt. Der Tunnel selbst ist OK nur geht kein Ping darüber oder irgendwelche anderen Sachen.
Das der Tunnel funktioniert bedeutet ja schon einmal, daß Port 500 von UM nicht gesperrt wird.
Wie siehts mit Port 50(UDP) aus? Der ist nach Aussage von Netgear und TheGreenBow nötig um nach erfolgreichem Tunnel auch etwas machen zu können.

Und NEIN, es liegt nicht an einer Firewall oder ähnlichem.
Gehe ich zu Nachbarn und probiere es aus (1&1 / Telekom) dann funktioniert alles so wie es soll.

Ich habe auch bei UM angerufen um Probleme mit Double-NAT auszuschließen. Aber da hies es, dass das Modem "Bridged" ist und auch keine Ports gesperrt sind. Jetzt finde ich den Thread hier und frage mich mal: Wer oder was sitzt da in der Hotline?

Wie geht also eine "vernünftige" VPN Verbindung über Unitymedia?

Gruß
Frank

 

[piotr]

Lies bitte Deine VPN-Infos nochmal.

Gemeint ist nicht der UDP-Port 50, sondern das IP-Protokoll Nr. 50 (ESP - Encapsulated Security Payload) - ein Teil vom IPsec.

Dann suche mal in Deinem VPN die Einstellung NAT-Traversal (NAT-T) und aktiviere diese sowohl auf Server- als auch auf Clientseite. NAT-T wurde von den IPsec-Entwicklern nachtraeglich "eingebaut", um die Probleme mit ESP zu verringern.

 

[FieserKiller]

Also hier klappt OpenVPN (@ecosys: das ist ein vernünftiges VPN) zuverlässig und der komische cisco vpn auch..

 

[ecosys]

Hi

Ok, ich muss mich noch etwas verbessern.
VPN im "Agressive Mode" funktioniert bei mir am UM Anschluß nicht. Bei Telekom oder 1&1 kein Problem.

Kontrollieren brauche ich eigentlich nicht mehr, denke ich.
Der Support von Netgear sowie TheGreenBow sind seit ca. 3 Wochen dran zu verstehen wo das Problem liegt.
Und nicht nur nach dem Schema "Du Kunde mach mal und gib bescheid", nein, die waren selbst Remote auf dem VPN Router und meinem Rechner.

Da, wie bereits geschrieben, der Tunnel bei Telekom sowie 1&1 funktioniert bleibt halt nur der Schluß übrig, dass irgendetwas am Anschluß seitens UM nicht korrekt läuft.

Gruß

 

[maikel_night]

Ich halte diese Praxis für sehr fragwürdig, ein ISP sollte sich eigentlich nicht darum scheren, was auf den Rechnern der Kunden vorgeht. Allerdings ergibt sich seitens Unitymedia natürlich auch das Problem des durch die Würmer etc. verursachten Traffics, der je nach Wurm teilweise mit erheblichen Überlastungen (und damit Beeinträchtigungen aller Nutzer) einhergeht. Bei uns im Netzwerk werden verseuchte Rechner ohne Vorwarnung gesperrt und erst nach Beseitigung des entsprechenden Schadprogramms wieder entsperrt, so eine Praxis wäre natürlich für Unitymedia undenkbar. Alternativ könnte man auch durch Einsatz entsprechender (teurer) Gateways den Traffic auf Applikationsebene filtern, was sich aber meines Wissens kein ISP leisten kann. Unitymedia greift deshalb zur Holzhammer-Methode: Bestimmte Ports werden erst gar nicht geöffnet, also können sich dort auch keine Würmer verbreiten. Falls sich mein Verdacht mit dem internen Routing bewahrheiten sollte geht Unitymedia sogar noch einen Schritt weiter und spielt (Unitymedia-Netz interne) Firewall für den Kunden.
Die meisten gängigen Viren- und Trojanerprobleme des Durchschnittsusers lassen sich damit beheben, der verstümmelte Anschluß kann aber leider nicht mehr für Nicht-Standard-Dinge (Offsite-Backups, VPN etc.) benutzt werden.
Alles in allem finde ich dieses Verhalten nicht in Ordnung.

Simon

Ich schliesse mich dem an....Nebenbei, es gibt Provider die Filterungen, bzw. malicious Traffic analysieren, siehe: http://www.modelco.de/mblog/?p=28 und 1 $ 1 stand vor einigen Tagen ganz groß in der Presse mit seinen neuen Methoden gegen Botnetze vorzugehen, siehe: http://www.heise.de/security/1-1-will-gegen-Bot-Netze-vorgehen--/news/meldung/132261
Hier ist mal wieder die Frage nach der Herrschaft und dem Zwang durch einen Provider offensichtlich und vor allem die Macht die ein solcher hat, damit winkt nämlich auch mal wieder die Zensurkeule....prinzipiell ist der Ansatz ja ganz nett, aber die Umsetzung schlecht, denn man nimmt dem User die Eigenverantwortung..Und traffic??? Naja, solange Terrabytes am Tag durch die Leitungen gehen via Perr to Peer sollte das wohl nicht so das Problem sein..!? Ich fühle mich bei Portsperren und Provider Firewalls sowie Content der für mich gefiltert wird in meiner Freiheit auf selbstbestimmung beschnitten und das suckt gewaltig!

 

[piotr]

Der Support von Netgear sowie TheGreenBow sind seit ca. 3 Wochen dran zu verstehen wo das Problem liegt.

Gib Deinem "Support" mal das Stichwort NAT-Traversal, dass bereits oefter gefallen ist.

NAT-T sollte mittlerweile von allen gaengigen auf IPsec basierenden VPN-Loesungen beherrscht werden.

Denn Dein Problem ist das bei VPN ueber IPsec benoetigte ESP-Protokoll, dass gerne komplett unveraenderte IP-Header haben moechte.
Nur macht das UM vermutlich wegen den Sprachpaketen auf derselben Leitung nicht und schiebt die Datenpakete mit anderen DSCP-Werten (ehem. "TOS"-Feld im IP-Header) durchs Netz.
Bei Telekom wird zum groessten Teil jeweils ein separates Netz fuer Sprache und DSL genutzt und damit funktioniert es dann dort.
Genauso koennte die Erweiterung ECN (Explizit congestion notification - Ueberlastbenachrichtigung von Routern) schuld sein, die auch IP-Header aendern kann (wieder das ehem. TOS-Feld).

Mit NAT-Traversal wird das eigenstaendige ESP-Protokoll in ein UDP-Paket eingepackt und dann ueber Port 4500 versendet, damit ist das dann egal ob der IP-Header geaendert wird oder nicht.

Aggressive oder Main Mode hat auf das ESP-Problem keine Auswirkung, nur auf den Anschluss selbst. Bei Main Mode brauchst Du zwingend eine statische IP, bei Aggressive Mode kann auch ein Dyn.DNS-Name genutzt werden.

 

[ecosys]

Gib Deinem "Support" mal das Stichwort NAT-Traversal, dass bereits oefter gefallen ist.
Mit NAT-Traversal wird das eigenstaendige ESP-Protokoll in ein UDP-Paket eingepackt und dann ueber Port 4500 versendet, damit ist das dann egal ob der IP-Header geaendert wird oder nicht.

Das brauche ich wohl nicht, da hier die erste Vermutung des Supports lag.

2009-03-02 : INFO: For 62.143.XXX.XXX[500], Selected NAT-T version: draft-ietf-ipsec-nat-t-ike-02
2009-03-02 : INFO: Floating ports for NAT-T with peer 62.143.XXX.XXX[4500]
2009-03-02 : INFO: NAT-D payload does not match for 87.XXX.XXX.XXX[4500]
2009-03-02 : INFO: NAT-D payload does not match for 62.143.XXX.XXX[4500]
2009-03-02 : INFO: NAT detected: Local is behind a NAT device. and alsoPeer is behind a NAT device

NAT-T Erkennung und Ausführung funktioniert wunderbar.

Genauso koennte die Erweiterung ECN (Explizit congestion notification - Ueberlastbenachrichtigung von Routern) schuld sein, die auch IP-Header aendern kann (wieder das ehem. TOS-Feld).

Zumindest macht das kein Router im Heim- bzw. Firmennetz.

Aggressive oder Main Mode hat auf das ESP-Problem keine Auswirkung, nur auf den Anschluss selbst. Bei Main Mode brauchst Du zwingend eine statische IP, bei Aggressive Mode kann auch ein Dyn.DNS-Name genutzt werden.

Ich kam nur darauf, da die Testverbindug von TheGreenBow nicht auf Aggressive gestellt ist und die Verbindung per dyndns funktioniert.
Mit eingestelltem Aggressive Mode funktioniert halt nur der Tunnel und dann ist Sense.

Ich kann mir echt nichts anderes mehr vorstellen als ein Problem aufgrund des UM Anschlusses.
Es ist doch wirklich seltsam, dass es hier nicht funktioniert aber wenn ich mit meinem Lappi zum Nachbarn renne der nunmal 1&1 hat, funktioniert es mit der exakt gleichen Config...

Gruß

 

[piotr]

Die Logs koennten darauf hindeuten: nat-d payload does not match...
Neben ESP koennte zusaetzlich AH an sein. AH (Authentication Header) besteht aber wie ESP auf unveraenderte IP-Packete, kann aber im Gegensatz zu ESP nicht per NAT-T in ein UDP-Packet eingepackt werden.
Das Aktivieren von AH siehst Du oft nur, wenn Du Deinen Traffic z.B. bei Windows mit Wireshark (auf anderen Betriebssystemen: snoop/tcpdump) mitschneidest.

Eine andere Ursache koennte eine unterschiedliche IKE-Version sein, denn in IKEv1 war bei der ESP nur die DES-Verschluesselung erlaubt (56bit). In IKEv2 ist es bei der ESP 3DES (168bit) oder optional AES (128-256bit).

Die Meldung: NAT detected: Local is behind a NAT device. and alsoPeer is behind a NAT device.
sagt, dass Dein VPN auf beiden Seiten jeweils hinter einem NAT-Router ist.
Wenn die Moeglichkeit besteht vielleicht mal den VPN-Client direkt am Modem bzw. den VPN-Server direkt an dessen Internetzugang testen, um NAT-Probleme auszuschliessen.

Die Meldung: Selected NAT-T version: draft-ietf-ipsec-nat-t-ike-02
sagt, dass Du eine Entwurfsversion vom IKEv2 verwendest.
Vielleicht mal nach einem Update der VPN-Software/-Firmware schauen, denn IKEv2 ist seit Dez 2005 offiziell standardisiert (RFC4305). Im IKEv2 gibt es keinen Main und Aggressive Mode mehr, vielleicht ist die GUI wegen der Draft noch nicht aktualisiert worden.
Vielleicht wird das draft IKEv2 automatisch aktiviert, wenn Du die NAT-T Option einschaltest.

Wenn Dein Laptop Windows XP hat, dann schau auch mal in der MS KB nach:
http://support.microsoft.com/?scid=kb%3Ben-us%3B818043&x=15&y=4
http://support.microsoft.com/?scid=kb%3Ben-us%3B885407&x=13&y=9



Eine Alternative zu Deinem auf IPsec basierendem VPN waere das bereits erwaehnte OpenVPN, denn das laeuft wirklich ueberall. Weil es nicht das IPsec mit all seinen Stolperfallen enthaelt.

 

[Frostfall]

:kafffee: Ich habe mir alles durchgelesen...... worum geht es? :kafffee: Ach vergesst es ich :mussweg: aus den Beitrag

 

[addicted]

Es ist wohl so, dass UM einige Ports aus Sicherheitsgründen gesperrt hat. Über diese Ports verbreiten sich z.B. Würmer und mit diesen Sperren können fremde User auch nicht mehr auf (irrtümlich) freigegebene Ordner zugreifen.

Es handelt sich um die Ports:
135, 137, 139, 445, 3127, 9898, 4444

Test gerade eben: Port 4444 ist in allen Kombinationen offen, UM IP in 109.90.0.0/15 (lokales Subnetz ist 109.91.24.0/22).
Die anderen Ports sind aber dicht.


Nebenbei: Meine Meinung ist, dass auf Netzebene nicht gefiltert werden sollte. Da man dem Kunden aber Hardware liefert, kann man diese so einstellen, dass sie die Netzwerkfreigabe mit den Urlaubsfotos des Kunden nicht ins WAN exportiert.

 

[Andreas1969]

Gibt es eigentlich mittlerweile eine Lösung?
Ich bekomme es einfach nicht hin, 2 Fritz Boxen per VPN im Unitymedia Netz zu koppeln.
Es ist alles korrekt konfiguriert, da selbige Konfiguration
mit 2 Fritz Boxen im Telekom Netz funktioniert.
Der Tunnel wird zwar aufgebaut, es fließen aber
keine Daten, weder Ping noch irgendetwas anderes.

Gruß Andreas

 

[GoaSkin]

Unitymedia filtert doch garkeine Ports Netzwerk-seitig. Die Fritzboxen sind so vorkonfiguriert, dass sie Ports 135-139, etc.pp. filtern, weil AVM meint, das so machen zu müssen. Leider ist es sehr trickreich, diesen Filter inder Fritzbox zu deaktivieren.
Gibt nur zwei Möglichkeiten:

1.) Mit dem Browser die Firewall-Config-Seite der Fritzbox aufrufen und mit den Web-Debug-Funktionen des Browsers die rausgefilterte Checkbox für den Netbios-Filter wieder einbauen - vorausgesetzt, man kennt die HTML-Tags ganz genau, die hier früher mal drin waren.

2.) Man bedient sich an FBEdit und bearbeitet eine gesicherte Konfiguration. An drei Stellen gibt es eine Einstellung für "Netbios Filter", die man dort jeweils negieren muss.

 

[Andreas1969]

Danke für die Info.
Werde dann mal bei beiden Boxen den Netbios Filter mit dem FB EDITOR negieren. Warum bekommt man da eigentlich keine Info vom AVM Support oder vom Unitymedia Kundenservice, die lassen einen im Regen stehen. Immer die Aussage: Muss funktionieren, die FB zurücksetzen, die VPN Verbindung nochmals neu einrichten usw.

Gruß Andreas

 

[hajodele]

Bei mir funktioniert VPN in einer Umgebung
- 7390 (1und1 über Telekom DS) mit 6340 (UM BaWü DS)
und
- 7390 (1und1 über Telekom DS) mit 6360 (UM BaWü IPv4)

Sowie mehreren CLient-VPNs
seit Jahren ohne dass ich den Filter irgendwo entfernen musste.

 

[Andreas1969]

Mit 2 Boxen im Telekom Netz (7390 und 7490, beide IPV4 only) habe ich das ja auch hinbekommen, ohne den Filter zu deaktivieren.
Bloß mit den 2 Boxen (6360 DSLIGHT und 6490 IVP4 only)
im Unitymedia Netz bekomme ich keine VPN Verbindung zum laufen. Laut AVM Support soll das aber gehen, auch wenn nur eine der beiden Boxen echtes UPV 4 hat.
Hat vielleicht jemand diese Konstellation am Laufen?

Gruß Andreas