Solved

Packet Filtered -- telekom.de und manche andere Seiten nicht erreichbar

7 years ago

Liebe Telekom-Community,

ich habe seit ein paar Tagen ein seltsames Problem mit meinem Internetzugang. Die Telekom-Hotline und der technische Support konnten mir nicht weiterhelfen. Daher versuche ich es einmal hier.

 

Problembeschreibung

Zahlreiche Internetseiten sind für mich nicht mehr erreichbar, darunter auch telekom.de. Rufe ich die Webseite mit Firefox auf, erhalte ich nur eine weiße Seite und ein Warte-Symbol, sonst passiert nichts. Andere Seiten, wie zum Beispiel tagesschau.de funktionieren jedoch hingegen einwandfrei. Witziger weise ist es mir daher nur möglich mittels des Tor-Browsers auf dieses Forum zuzugreifen. Das ganze begann vor etwa einer Woche, bis dahin funktionierte alles einwandfrei. Ich habe an meiner Konfiguration in der Zwischenzeit nichts geändert.

 

Ein Ping auf die Telekom-Seite ergibt folgendes:

root@gateway:~# ping www.telekom.de
PING www.telekom.de (46.29.100.76) 56(84) bytes of data.
From 87.190.235.69 (87.190.235.69) icmp_seq=1 Packet filtered
From 87.190.235.69 (87.190.235.69) icmp_seq=5 Packet filtered
From 87.190.235.69 (87.190.235.69) icmp_seq=7 Packet filtered
^C
--- www.telekom.de ping statistics ---
7 packets transmitted, 0 received, +3 errors, 100% packet loss, time 6082ms

Man beachte die hohe Verlustrate und dass eine andere IP als die angepingte antwortet. Ein Ping auf die Tagesschau-Seite funktioniert hingegen wie gewünscht:

root@gateway:~# ping www.tagesschau.de
PING e8178.e6.akamaiedge.net (23.51.114.159) 56(84) bytes of data.
64 bytes from a23-51-114-159.deploy.static.akamaitechnologies.com (23.51.114.159): icmp_seq=1 ttl=61 time=3.94 ms
64 bytes from a23-51-114-159.deploy.static.akamaitechnologies.com (23.51.114.159): icmp_seq=2 ttl=61 time=3.95 ms
64 bytes from a23-51-114-159.deploy.static.akamaitechnologies.com (23.51.114.159): icmp_seq=3 ttl=61 time=4.14 ms
64 bytes from a23-51-114-159.deploy.static.akamaitechnologies.com (23.51.114.159): icmp_seq=4 ttl=61 time=3.93 ms
64 bytes from a23-51-114-159.deploy.static.akamaitechnologies.com (23.51.114.159): icmp_seq=5 ttl=61 time=3.92 ms
^C
--- e8178.e6.akamaiedge.net ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 3.924/3.979/4.145/0.115 ms

 

Konfiguration

Ich habe einen Glasfaser-Anschluss und einen „ DeutschlandLAN IP“-Vertrag. Um mich mit dem Internet zu verbinden, benutze ich einen als Router konfigurierten PC unter Debian GNU/Linux. Das Glasfasermodem ist direkt mit der Netzwerkkarte eth0 verbunden. Ich wähle mich direkt über PPPoE ein. Hier eine übersicht über die relevanten Abschnitte der Konfigurationsdateien.

 

/etc/network/interfaces:

auto eth0
iface eth0 inet manual

auto eth0.7
iface eth0.7 inet manual

auto ppp0
iface ppp0 inet ppp
    provider telekom
    post-up  echo "1" > /proc/sys/net/ipv4/ip_forward
    post-up  iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
    pre-down iptables -t nat -D POSTROUTING -o ppp0 -j MASQUERADE
    pre-down echo "0" > /proc/sys/net/ipv4/ip_forward

/etc/ppp/peers/telekom:

plugin rp-pppoe.so eth0.7
noipdefault
defaultroute
usepeerdns
persist
user "ZENSIERT@t-online.de"
noauth
noaccomp

Der Verbindungsaufbau scheint auch reibungsfrei zu funktionieren. Der entsprechende Abschnitt aus /var/log/syslog:

May 26 15:01:12 gateway pppd[1860]: PPP session is 83
May 26 15:01:12 gateway pppd[1860]: Connected to dc:38:e1:17:10:c4 via interface eth0.7
May 26 15:01:12 gateway pppd[1860]: Using interface ppp0
May 26 15:01:12 gateway pppd[1860]: Connect: ppp0 <--> eth0.7
May 26 15:01:12 gateway pppd[1860]: Remote message: SRU=100000#SRD=200000#
May 26 15:01:12 gateway pppd[1860]: PAP authentication succeeded
May 26 15:01:12 gateway pppd[1860]: peer from calling number DC:38:E1:17:10:C4 authorized
May 26 15:01:12 gateway pppd[1860]: local  IP address 80.ZEN.SIE.RT
May 26 15:01:12 gateway pppd[1860]: remote IP address 62.155.241.158
May 26 15:01:12 gateway pppd[1860]: primary   DNS address 217.0.43.33
May 26 15:01:12 gateway pppd[1860]: secondary DNS address 217.0.43.17

Default route und DNS-Server werden auch korrekt eingetragen:

root@gateway:~# route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
62.155.241.158  0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
root@gateway:~# cat /etc/resolv.conf
nameserver 217.0.43.33
nameserver 217.0.43.17
root@gateway:~# 

 

Meine Diagnose und der technische Support

Vor ein paar Wochen erhielt ich einen Brief, dass mein Anschluss „umgestellt“ werde. Für mich würde sich nichts ändern, lediglich das Internet sei für ein paar Stunden nicht verfügbar. Seit diesem Umstellungstermin besteht das Problem. An meiner Konfiguration habe ich nichts geändert. Da einige Seiten funktionieren und ich dank Tor auch im Internet surfen kann, liegt das Problem scheinbar im Netz der Telekom und nicht bei mir. Ich habe bereits eine andere Netzwerkkarte ausprobiert, allerdings auch ohne Erfolg.

 

Ich habe eine Störungsmeldung aufgegeben, letzten Endes wurde mir gesagt, dass auf Seiten der Telekom keine Störung vorliege und ich mich an den kostenpflichtigen Support wenden solle. Die Störungsmeldung wurde daraufhin einfach geschlossen. Ich habe mich auch an den kostenpflichtigen technischen Support gewendet, dort wurde mir dann lediglich gesagt, dass Linux nicht unterstützt werde. Aber wie gesagt, so weit wie ich das sehe liegt das Problem ohnehin nicht auf meiner Seite. Bevor ich mich nun noch mal eine Stunde von Hotline zu Hotline hangele, stelle ich meine Frage mit detaillierten Informationen nun einfach hier. Ich wäre froh, wenn mir jemand helfen könnte.

1275

8

    • 7 years ago

      @Dr. Arno Nym

      Ist mir bis jetzt noch gar nicht aufgefallen, aber beim ping habe ich das identische Problem:

      ping telekom.de
      PING telekom.de (46.29.100.76) 56(84) bytes of data.
      From 87.190.235.69 icmp_seq=7 Packet filtered
      From 87.190.235.69 icmp_seq=10 Packet filtered
      From 87.190.235.69 icmp_seq=17 Packet filtered
      From 87.190.235.69 icmp_seq=22 Packet filtered
      From 87.190.235.69 icmp_seq=23 Packet filtered
      ^C
      --- telekom.de ping statistics ---
      24 packets transmitted, 0 received, +5 errors, 100% packet loss, time 23395ms

       

      Im Browser, hier chrome, kann ich aber die telekom.de Seite ganz normal öffnen.

      6

      Answer

      from

      7 years ago

      @Dr. Arno Nym

      Das eine Seite auf ICMP Pakete nicht antwortet ist doch völlig normal und bedeutet für sich alleine genommen gar nichts.

      Solange die Seite auf die eigentlichen Protokolle antwortet ist alle normal.

       

      Das eine andere IP als die gepingte antwortet ist auch nichts ungewöhnliches.

      www.telekom.de ist mit Sicherheit ein Loadbalancer und nicht ein Rechner mit einer IP.

      Je nach eingesetztem Verfahren kann da auch ein anderer Server antworten

      Answer

      from

      7 years ago

      Hallo liebe Community,

       

      vielen Dank für Eure Hilfe. Ich habe tatsächlich vom gateway selbst aus immer nur gepingt und gedacht, dass das immer funktionieren müsste. @Stefan: vielen Dank. Ist mir schon fast peinlich, darauf hätte ich auch selbst kommen müssen. Auf Grund Deines Hinweises habe ich einfach mal lynx auf dem gateway installiert und konnte damit die Telekom-Seite auch besuchen.

       

      Das Problem lag letzten endes an den MTU-Einstellungen. Und zwar an denen der Clients im meinem Netzwerk, und nicht an der zum Modem! Egal was ich als MTU an der Verbindung zum Modem oder beim pppd angegeben habe, das änderte nichts. Aber sobald ich die MTU der Clients in meinem Netzwerk auf 1492 herabgesetzt habe, funktionierte wieder alles.

       

      Ist dies ein Bug? Ich dachte immer, dass das ip_forwarding und das masquerading zu große Pakete aus dem internen Netzwerk "aufgestückelt" ans Modem durchreichen würde.

      Answer

      from

      7 years ago

      @Dr. Arno Nym

      Da macht dein Router etwas noch nicht korrekt.

      Für IPv4 ist bei meinen clients die MTU auf 1500 gesetzt.

      Für IPv6 hängt es vom Router ab, ein Speedport setzt die MTU auf 1492, eine Digitalisierungsbox auf 1500.

      Unlogged in user

      Answer

      from

    • Accepted Solution

      accepted by

      7 years ago

      Hallo liebe Community,

       

      vielen Dank für Eure Hilfe. Ich habe tatsächlich vom gateway selbst aus immer nur gepingt und gedacht, dass das immer funktionieren müsste. @Stefan: vielen Dank. Ist mir schon fast peinlich, darauf hätte ich auch selbst kommen müssen. Auf Grund Deines Hinweises habe ich einfach mal lynx auf dem gateway installiert und konnte damit die Telekom-Seite auch besuchen.

       

      Das Problem lag letzten endes an den MTU-Einstellungen. Und zwar an denen der Clients im meinem Netzwerk, und nicht an der zum Modem! Egal was ich als MTU an der Verbindung zum Modem oder beim pppd angegeben habe, das änderte nichts. Aber sobald ich die MTU der Clients in meinem Netzwerk auf 1492 herabgesetzt habe, funktionierte wieder alles.

       

      Ist dies ein Bug? Ich dachte immer, dass das ip_forwarding und das masquerading zu große Pakete aus dem internen Netzwerk "aufgestückelt" ans Modem durchreichen würde.

      0

      Unlogged in user

      Ask

      from

      This could help you too

      Solved

      in  

      1082

      14

      7

      Solved

      260

      0

      3

      Solved

      2706

      2

      4