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

      Das ist natürlich interessant! Eine andere Seite die bei mir nicht funktioniert ist openrouteservice.org. Traceroute ergibt interessantes: das Paket geht irgendwo unterwegs verloren.

      root@gateway:~# traceroute telekom.de
      traceroute to telekom.de (46.29.100.76), 64 hops max
        1   62.155.241.158  11,410ms  3,824ms  1,342ms 
        2   217.5.69.10  15,071ms  11,897ms  11,970ms 
        3   217.5.69.10  16,576ms  15,953ms  15,916ms 
        4   *  *  * 
        5   *  87.190.235.69  12,665ms !X  * 
      
      root@gateway:~# ping maps.openrouteservice.org
      PING maps.openrouteservice.org (129.206.7.180) 56(84) bytes of data.
      ^C
      --- maps.openrouteservice.org ping statistics ---
      12 packets transmitted, 0 received, 100% packet loss, time 11246ms
      
      root@gateway:~# traceroute maps.openrouteservice.org
      traceroute to maps.openrouteservice.org (129.206.7.180), 64 hops max
        1   62.155.241.158  13,327ms  2,918ms  1,381ms 
        2   217.5.118.38  5,854ms  6,066ms  6,141ms 
        3   62.157.251.158  5,846ms  5,943ms  5,861ms 
        4   81.95.2.174  6,207ms  6,148ms  6,087ms 
        5   129.143.60.56  7,792ms  7,621ms  7,685ms 
        6   129.143.79.114  7,282ms  7,321ms  7,336ms 
        7   129.206.216.209  7,551ms  7,411ms  7,556ms 
        8   129.206.215.66  7,305ms  *  * 
        9   129.206.7.105  7,389ms  *  * 
       10   *  *  * 
       11   *  *  * 
       12   *  *  * 
       13   *  *  * 
       14   *  *  * 
       15   *  *  * 
       16   *  *  * 
       17   *  *  * 
       18   *  *  * 
       19   *  *  * 
       20   *  *  * 
       21   *  *  * 
       22   *  *  * 
       23   *  *  * 
       24   *  *  * 
       25   *  * ^C
      root@gateway:~# 

      Answer

      from

      7 years ago

      @Dr. Arno Nym

      An meinem funktionierenden Anschluß ist das nicht anders.

      Ein ping auf telekom.de und maps.openrouteservice.org funktioniert nicht.

      Stört mich auch nicht.

       

      Answer

      from

      7 years ago

      @wari1957

      Das eigentliche Problem ist ja auch nicht, dass der Ping nicht funktioniert, sondern, dass ich die Webseite nicht aufrufen kann. Weinend Ich dachte lediglich, dass das Pingen Hinweise auf das Problem bieten könnte. Vielleicht haben ja auch andere das Problem, daher dachte ich, hier wäre ein gute Ort darüber zu reden.

       

      Ich werde ein paar weitere Dinge ausprobieren und mich dann wieder hier melden.

      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