# https Seiten sind nicht erreichbar

## LL0rd

Hallo Leute,

ich kämpfe gerade mit einem Problem. Seit kurzem ist von meinem Server und meinem Desktop einige https Seiten nicht erreichbar. Andere wiederum gehen problemlos. Was absolut erstaunlich ist, ist dass von meinem Notebook aus alles funktioniert. 

Erreichbar ist z.B. https://secure.sipgate.de

Nicht erreichbar ist z.B. die Seite meiner Bank.  https://www.dresdner-privat.de/

tcpdump hat folgendes geliefert:

```
11:42:10.526114 IP tau.38968 > www.advance-bank.co.uk.https: S 1250037107:1250037107(0) win 17920 <mss 8960,sackOK,timestamp 267877979 0,nop,wscale 5>

11:42:10.557632 IP www.advance-bank.co.uk.https > tau.38968: S 2328535632:2328535632(0) ack 1250037108 win 33304 <nop,nop,timestamp 2075183723 267877979,nop,wscale 0,nop,nop,sackOK,mss 1460>

11:42:10.557669 IP tau.38968 > www.advance-bank.co.uk.https: . ack 1 win 560 <nop,nop,timestamp 267877987 2075183723>

11:42:10.559814 IP tau.38968 > www.advance-bank.co.uk.https: P 1:106(105) ack 1 win 560 <nop,nop,timestamp 267877987 2075183723>

11:42:10.592363 IP www.advance-bank.co.uk.https > tau.38968: . ack 106 win 33304 <nop,nop,timestamp 2075183726 267877987>

11:42:10.593735 IP www.advance-bank.co.uk.https > tau.38968: P 1449:2165(716) ack 106 win 33304 <nop,nop,timestamp 2075183726 267877987>

11:42:10.593746 IP tau.38968 > www.advance-bank.co.uk.https: . ack 1 win 560 <nop,nop,timestamp 267877996 2075183726,nop,nop,sack 1 {1449:2165}>

11:42:55.624884 IP tau.38968 > www.advance-bank.co.uk.https: F 106:106(0) ack 1 win 560 <nop,nop,timestamp 267889253 2075183726,nop,nop,sack 1 {1449:2165}>

11:42:55.656680 IP www.advance-bank.co.uk.https > tau.38968: . ack 107 win 33304 <nop,nop,timestamp 2075188233 267889253>

11:42:55.657799 IP www.advance-bank.co.uk.https > tau.38968: F 2165:2165(0) ack 107 win 33304 <nop,nop,timestamp 2075188233 267889253>

11:42:55.657815 IP tau.38968 > www.advance-bank.co.uk.https: R 1250037214:1250037214(0) win 0
```

Hat von euch jemand eine Idee oder einen Ansatz, wie man herausfinden kann, woran es liegt?

----------

## big-birdy

Hi.

Ich kenne das problem nur vom Internet Explorer. Überprüf mal ob du alle SSL Versionen aktiviert hast. Im IE hilft das meistens. 

mfg

big-birdy

----------

## schachti

Hast Du verschiedene Browser durchprobiert?

----------

## LL0rd

Ja, hab ich... Auf meinem Notebook läuft unter Windows alles. Egal welcher Browser, egal welche Netzwerkkarte, egal welche IP Adresse.

Auf den restlichen Rechnern sind die Seiten nicht erreichbar. Komischerweise sind es "nur" die Banking Portale, auf die ich nicht zugreifen kann.

----------

## LL0rd

Achso, hab noch vergessen zu sagen, dass wenn ich einen SOCKS Proxy angebe, der außerhalb meines Netzes steht, die Seiten dann mit dem Browser aufgerufen werden können.

Ich hab mir auch schon gedacht, ich hätte mir irgendetwas eingefangen... Aber auch mit einer Linux Boot CD konnte ich nicht auf die Banking Portale zugreifen. Ich weiß nicht genau wieso, aber es sind wirklich nur die Banking Portale betroffen...

----------

## dakjo

Verwendest du einen proxy?

----------

## LL0rd

 *dakjo wrote:*   

> Verwendest du einen proxy?

 

Nein.

Mir ist gerade noch aufgefallen, dass ich http://golem.de auch nicht aufrufen kann.

----------

## schachti

Kannst Du ausschliessen, dass Du einen transparenten Zwangsproxy von $provider nutzt? Wird Dir auf http://www.heise.de/netze/tools/ip die korrekte IP angezeigt?

----------

## LL0rd

 *schachti wrote:*   

> Kannst Du ausschliessen, dass Du einen transparenten Zwangsproxy von $provider nutzt? Wird Dir auf http://www.heise.de/netze/tools/ip die korrekte IP angezeigt?

 

Hmm... also ausschließen kann ich das nicht... aber zumindest wird mir auf der Seite meine IP angezeigt

----------

## schachti

Zeigen route -n oder for name in $(cat /proc/net/ip_tables_names); do iptables -vnL -t $name; done irgendwelche Auffaelligkeiten?

----------

## dakjo

Sind die Nameserver aus der /etc/resolv.conf alle erreichbar?

----------

## LL0rd

ja, die nameserver lösen alle hostnames richtig auf. Also den Grund hab ich gefunden. Der Router scheint das ganze irgendwie zu blocken, ich weiß aber nicht wieso....

Worin unterscheidet sich denn z.B. golem von einer anderen seite?

----------

## think4urs11

'riecht' irgendwie nach blackhole router bzw. etwas professioneller gesprochen Path MTU Discovery

Hast du evtl. irgendetwas an den MTU-Sizes gedreht? (am Router, am PC)

und/oder blockst du neuerdings ICMP?

----------

## LL0rd

Ja, hab ich....

Das Notebook hat normale 1492er MTU, die anderen Rechner fahren mit Jumbo Frames

----------

## think4urs11

normal im LAN wäre aber 1500  :Wink: 

Du hast einen DSL-Router mit PPPoE?

Dieser hat auf WAN/LAN-Seite welche Einstellung für MTU?

Setzt du die Größe(n) für MTU/MRU dort explizit oder passiert das automatisch?

----------

## LL0rd

 *Think4UrS11 wrote:*   

> normal im LAN wäre aber 1500 

 

Mein Fehler

 *Think4UrS11 wrote:*   

> Du hast einen DSL-Router mit PPPoE?
> 
> Dieser hat auf WAN/LAN-Seite welche Einstellung für MTU?

 

Ja, ist ein PPPoE Router... 

```
br0       Link encap:Ethernet  HWaddr 00:18:39:CE:99:2C

          inet addr:10.2.0.70  Bcast:10.2.255.255  Mask:255.255.0.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:32788 errors:0 dropped:0 overruns:0 frame:0

          TX packets:7924070 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:3342203 (3.1 MiB)  TX bytes:1493340313 (1.3 GiB)

eth0      Link encap:Ethernet  HWaddr 00:18:39:CE:99:2C

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:1528001 errors:0 dropped:0 overruns:0 frame:0

          TX packets:8776902 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1693166778 (1.5 GiB)  TX bytes:1604305286 (1.4 GiB)

          Interrupt:4

eth1      Link encap:Ethernet  HWaddr 00:18:39:CE:99:2E

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:850606 errors:0 dropped:0 overruns:0 frame:77

          TX packets:1487854 errors:3765 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:48941669 (46.6 MiB)  TX bytes:1682370729 (1.5 GiB)

          Interrupt:2 Base address:0x5000

ppp0      Link encap:Point-to-Point Protocol

          inet addr:62.214.233.124  P-t-P:213.30.192.78  Mask:255.255.255.255

          UP POINTOPOINT RUNNING MULTICAST  MTU:1492  Metric:1

          RX packets:31210 errors:0 dropped:0 overruns:0 frame:0

          TX packets:26625 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:3

          RX bytes:19100496 (18.2 MiB)  TX bytes:2871357 (2.7 MiB)
```

Die MTU des Routers wird automatisch gesetzt.

Das hier ist jetzt einer der Rechner

```
eth0      Link encap:Ethernet  HWaddr 00:0E:0C:BD:01:FA

          inet addr:10.2.0.200  Bcast:10.2.0.255  Mask:255.255.0.0

          UP BROADCAST RUNNING MULTICAST  MTU:9000  Metric:1

          RX packets:14402872 errors:2 dropped:2 overruns:0 frame:1

          TX packets:17096634 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:3969043658 (3785.1 Mb)  TX bytes:234694942 (223.8 Mb)

          Base address:0xd400 Memory:dc000000-dc020000
```

Hier habeich die MTU natürlich per Hand geändert. Auf den anderen Rechnern siehts genauso aus

----------

## bbgermany

Hi,

da du ja an der MTU rumgespielt hast, kann denn dein Switch mit Jumboframes umgehen? Ich hab hier nämlich auch Gigabit und mit eingeschalteten Jumboframes habe ich mehr Stress als ohne. Der äußerst sich aber stärker als bei dir. Ich kann dann z.B. nichtmal mehr im LAN Dateien via scp/ftp/nfs/smb/cifs kopieren ohne dass ich nur Fehler und Verbindungsabbrüche habe.

MfG. Stefan

----------

## LL0rd

 *bbgermany wrote:*   

> 
> 
> da du ja an der MTU rumgespielt hast, kann denn dein Switch mit Jumboframes umgehen? Ich hab hier nämlich auch Gigabit und mit eingeschalteten Jumboframes habe ich mehr Stress als ohne. Der äußerst sich aber stärker als bei dir. Ich kann dann z.B. nichtmal mehr im LAN Dateien via scp/ftp/nfs/smb/cifs kopieren ohne dass ich nur Fehler und Verbindungsabbrüche habe.
> 
> 

 

Ich hatte bis neulich keine Probleme... Und im Netzwerk funzt auch alles super.... Übertragungsraten von ca. 100MB/s werden erreicht... In den Kisten stecken Intel Pro/1000PT PCIe Karten drinn und sind mit 5m cat6 kabeln an einem HP ProCurve 1800-8G Switch angeschlossen (Jumboframes selbstverständlich eingeschaltet)

----------

## think4urs11

PMTU Discovery auf allen Geräten ist an/aus? (/proc/sys/net/ipv4/ip_no_pmtu_disc)

was gibt (jeweils auf Router, Notebook und Server) ping -sXXXX -M do forums.gentoo.org

wobei XXXX = 1464, 1465

alternativ: was passiert wenn du die MTU testhalber auf 1500 heruntersetzt? Welche Kernelversionen sind jeweils im Einsatz?

Mehr Fragen sobald sie mir einfallen  :Wink: 

----------

## LL0rd

Also, wo fang ich denn an? Okay, kernel Versionen:

Desktop PC: 2.6.19-gentoo-r5

Router: 2.4.34-pre2

Ein einfacher Ping ist aktuell von den Desktop Rechnern nicht möglich. Ein Ping mit ping -s1465 -M do  lieferte ein paar tausend Mal folgendes:

```
From 10.2.0.200 icmp_seq=2 Frag needed and DF set (mtu = 1492)
```

Nach dem ändern der MTU war es wieder möglich nach außen zu pingen, allerdings waren die Seiten immer noch nicht erreichbar.

/proc/sys/net/ipv4/ip_no_pmtu_disc

ist sowohl auf dem Router, als auch auf dem Desktop 0

----------

## think4urs11

betreibst du MSS-Clamping auf deinem Router? Wenn nein pack das mal in deine FW-Rules

Prinzip: 

```
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss -j TCPMSS --clamp-mss-to-pmtu
```

----------

## LL0rd

 *Think4UrS11 wrote:*   

> betreibst du MSS-Clamping auf deinem Router? Wenn nein pack das mal in deine FW-Rules
> 
> Prinzip: 
> 
> ```
> ...

 

Danke für den Tipp.... Ich hatte es aber schon im ruleset drinn..... Allerdings ist mir jedoch aufgefallen, dass im Vergleich zu dem default ruleset ein paar Optionen fehlen.

Nachdem ich

```
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss -j TCPMSS --mss 1453:65535 --set-mss 1452
```

am Anfang des Rulesets eingefügt habe, funktioniert wieder alles. Vielen Dank für die Unterstützung!!

(

Eine Frage hab ich jedoch noch: Wieso tritt das Problem nur bei wenigen Websites auf? Bisher war ich immer davon ausgegangen, dass MSS <= MTU sein muss, dann funktionierts schon.

----------

## psyqil

 *LL0rd wrote:*   

> Eine Frage hab ich jedoch noch: Wieso tritt das Problem nur bei wenigen Websites auf?

  *Alan Cox wrote:*   

> If the MTU of the two links is different you should look for outgoing
> 
> frames through the router with no reply when the size of reply would be
> 
> large. Thats a clear indication that the remote site has firewalls set up
> ...

 Auch erkennbar an einem nicht funktionierendem ping golem.de...

----------

## think4urs11

 *LL0rd wrote:*   

> Wieso tritt das Problem nur bei wenigen Websites auf? Bisher war ich immer davon ausgegangen, dass MSS <= MTU sein muss, dann funktionierts schon.

 

Gerne geschehen  :Smile: 

Das Problem tritt auf weil leider viele Admins faul/unwissend/lernresistend sind und ICMP auf ihren Firewalls komplett blocken - deswegen geht z.B. auch kein ping.

Richtig wäre aber nur die ICMP-Messages zu droppen wie z.B. type 0 (echo reply sprich ping) und andere wie type3, code 4 (fragmentation needed&DF set) weiterhin zuzulassen. Letzterer ist genau für diesen Effekt zuständig - der Webserver geht davon aus das er mit 1500 schicken kann weil ihn die genau für den Fall 'unterschiedliche MTU auf der Strecke' vorgesehenen ICMP-Messages nie erreichen.

In dem Fall ist also der FW-Admin schuld; es gibt aber z.B. ähnlich nette Effekte wenn mit TCP-Window-Sizing gearbeitet wird - dann ist i.d.R. aber der Serveradmin schuld  :Wink: 

MSS<=MTU ist nur halb richtig: MSS ist immer kleiner MTU, nie gleich (jedenfalls bei 'normalen' Protokollen).

Der Wert 1452 bei deinem Clamp kommt durch '1500  - 8 Byte PPPoE-Header - 40 Byte TCP-Header' zustande.

----------

## LL0rd

Eine Frage hab ich da noch: Wenn ein Switch keine Jumbo Frames unterstützt, was macht er dann? Verwirft er das Paket?

http://rootix.de/mtu9000.png

Wie man sieht, hau ich die MTU durch das ganze Netz durch, bedeutet das, dass die anderen Router / Switches auch alle Jumbo Frames unterstützen müssen?

----------

## think4urs11

 *LL0rd wrote:*   

> Eine Frage hab ich da noch: Wenn ein Switch keine Jumbo Frames unterstützt, was macht er dann? Verwirft er das Paket?

 

Ja, siehe z.B. http://www.nwlab.net/art/jumboframes/jumbo-frames.html

----------

