Linux-Gateway und komische Verbindungs-Probleme

[MrToiz]

Hallo!

Nachdem vor einer Woche mein Netgear-Router den Geist aufgegeben hat, musste ich Hals-über-Kopf meinen (unter Debian Etch laufenden) Server zum Gateway für das LAN umfunktionieren.
Nun hab ich jedoch ein komisches Problem: Versuche ich von einem der Clients eine Verbindung eine Verbindung zur Seite meiner Bank aufzubauen, scheitert dies. Vom Server hingegen funktioniert's!
Außer der Bank-Seite haben bis jetzt alle funktioniert, so dass ich echt nicht weiß, woran das liegen könnte. (Update 4.4.: Nicht nur die Bank ist betroffen, sondern z.B. auch microsoft.com und ein paar andere Seiten, die offensichtlich nichts gemein haben).

Probiert habe ich das ganze mit einer iptables-Minimalkonfiguration, die so aussah:

$IPT -P INPUT DROP
$IPT -P OUTPUT ACCEPT
$IPT -P FORWARD DROP

# INPUT Chain
$IPT -A INPUT -s 194.127.84.106 -j LOG --log-prefix "DresdnerBank INPUT: "
$IPT -A INPUT -i $LO_IFACE -j ACCEPT
$IPT -A INPUT -i $LOCAL_IFACE -j ACCEPT
$IPT -A INPUT -i $INET_IFACE -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -m limit --limit 10/minute --limit-burst 10 -j LOG --log-prefix "INPUT packet died: "

# FORWARD Chain
$IPT -A FORWARD -s 194.127.84.106 -j LOG --log-prefix "DresdnerBank FORWARD: "
$IPT -A FORWARD -d 194.127.84.106 -j LOG --log-prefix "DresdnerBank FORWARD: "
$IPT -A FORWARD -i $LOCAL_IFACE -j ACCEPT
$IPT -A FORWARD -i $INET_IFACE -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A FORWARD -m limit --limit 10/minute --limit-burst 10 -j LOG --log-prefix "FORWARD packet died: "

# OUTPUT Chain
$IPT -A OUTPUT -d 194.127.84.106 -j LOG --log-prefix "DresdnerBank OUTPUT: "

# nat table
# POSTROUTING chain
$IPT -t nat -A POSTROUTING -o $INET_IFACE -j MASQUERADE

Das ergibt folgende Logs:
Zugriff vom Server (funktioniert):

Sep 13 20:15:29 Geisbutler kernel: DresdnerBank OUTPUT: IN= OUT=ppp1000 SRC=92.228.66.220 DST=194.127.84.106 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=7790 DF PROTO=TCP SPT=4489 DPT=443 WINDOW=5808 RES=0x00 SYN URGP=0 
Sep 13 20:15:29 Geisbutler kernel: DresdnerBank INPUT: IN=ppp1000 OUT= MAC= SRC=194.127.84.106 DST=92.228.66.220 LEN=64 TOS=0x00 PREC=0x00 TTL=58 ID=34213 DF PROTO=TCP SPT=443 DPT=4489 WINDOW=33120 RES=0x00 ACK SYN URGP=0 
Sep 13 20:15:29 Geisbutler kernel: DresdnerBank OUTPUT: IN= OUT=ppp1000 SRC=92.228.66.220 DST=194.127.84.106 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7791 DF PROTO=TCP SPT=4489 DPT=443 WINDOW=726 RES=0x00 ACK URGP=0 
Sep 13 20:15:29 Geisbutler kernel: DresdnerBank OUTPUT: IN= OUT=ppp1000 SRC=92.228.66.220 DST=194.127.84.106 LEN=170 TOS=0x00 PREC=0x00 TTL=64 ID=7792 DF PROTO=TCP SPT=4489 DPT=443 WINDOW=726 RES=0x00 ACK PSH URGP=0 
Sep 13 20:15:31 Geisbutler kernel: DresdnerBank INPUT: IN=ppp1000 OUT= MAC= SRC=194.127.84.106 DST=92.228.66.220 LEN=52 TOS=0x00 PREC=0x00 TTL=58 ID=34214 DF PROTO=TCP SPT=443 DPT=4489 WINDOW=33120 RES=0x00 ACK URGP=0 
Sep 13 20:15:31 Geisbutler kernel: DresdnerBank INPUT: IN=ppp1000 OUT= MAC= SRC=194.127.84.106 DST=92.228.66.220 LEN=1492 TOS=0x00 PREC=0x00 TTL=58 ID=34215 DF PROTO=TCP SPT=443 DPT=4489 WINDOW=33120 RES=0x00 ACK URGP=0 
Sep 13 20:15:31 Geisbutler kernel: DresdnerBank INPUT: IN=ppp1000 OUT= MAC= SRC=194.127.84.106 DST=92.228.66.220 LEN=1492 TOS=0x00 PREC=0x00 TTL=58 ID=34216 DF PROTO=TCP SPT=443 DPT=4489 WINDOW=33120 RES=0x00 ACK PSH URGP=0 
Sep 13 20:15:31 Geisbutler kernel: DresdnerBank INPUT: IN=ppp1000 OUT= MAC= SRC=194.127.84.106 DST=92.228.66.220 LEN=1492 TOS=0x00 PREC=0x00 TTL=58 ID=34217 DF PROTO=TCP SPT=443 DPT=4489 WINDOW=33120 RES=0x00 ACK PSH URGP=0 
Sep 13 20:15:31 Geisbutler kernel: DresdnerBank OUTPUT: IN= OUT=ppp1000 SRC=92.228.66.220 DST=194.127.84.106 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7793 DF PROTO=TCP SPT=4489 DPT=443 WINDOW=1086 RES=0x00 ACK URGP=0 
Sep 13 20:15:31 Geisbutler kernel: DresdnerBank OUTPUT: IN= OUT=ppp1000 SRC=92.228.66.220 DST=194.127.84.106 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7794 DF PROTO=TCP SPT=4489 DPT=443 WINDOW=1446 RES=0x00 ACK URGP=0 
Sep 13 20:15:31 Geisbutler kernel: DresdnerBank OUTPUT: IN= OUT=ppp1000 SRC=92.228.66.220 DST=194.127.84.106 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7795 DF PROTO=TCP SPT=4489 DPT=443 WINDOW=1806 RES=0x00 ACK URGP=0 

Sep 13 20:15:31 Geisbutler kernel: DresdnerBank INPUT: IN=ppp1000 OUT= MAC= SRC=194.127.84.106 DST=92.228.66.220 LEN=1199 TOS=0x00 PREC=0x00 TTL=58 ID=34218 DF PROTO=TCP SPT=443 DPT=4489 WINDOW=33120 RES=0x00 ACK PSH URGP=0 
Sep 13 20:15:31 Geisbutler kernel: DresdnerBank OUTPUT: IN= OUT=ppp1000 SRC=92.228.66.220 DST=194.127.84.106 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7796 DF PROTO=TCP SPT=4489 DPT=443 WINDOW=2166 RES=0x00 ACK URGP=0 
Sep 13 20:15:31 Geisbutler kernel: DresdnerBank OUTPUT: IN= OUT=ppp1000 SRC=92.228.66.220 DST=194.127.84.106 LEN=250 TOS=0x00 PREC=0x00 TTL=64 ID=7797 DF PROTO=TCP SPT=4489 DPT=443 WINDOW=2166 RES=0x00 ACK PSH URGP=0 
Sep 13 20:15:32 Geisbutler kernel: DresdnerBank INPUT: IN=ppp1000 OUT= MAC= SRC=194.127.84.106 DST=92.228.66.220 LEN=52 TOS=0x00 PREC=0x00 TTL=58 ID=34219 DF PROTO=TCP SPT=443 DPT=4489 WINDOW=33120 RES=0x00 ACK URGP=0 
Sep 13 20:15:32 Geisbutler kernel: DresdnerBank INPUT: IN=ppp1000 OUT= MAC= SRC=194.127.84.106 DST=92.228.66.220 LEN=111 TOS=0x00 PREC=0x00 TTL=58 ID=34220 DF PROTO=TCP SPT=443 DPT=4489 WINDOW=33120 RES=0x00 ACK PSH URGP=0 
Sep 13 20:15:32 Geisbutler kernel: DresdnerBank OUTPUT: IN= OUT=ppp1000 SRC=92.228.66.220 DST=194.127.84.106 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7798 DF PROTO=TCP SPT=4489 DPT=443 WINDOW=2166 RES=0x00 ACK URGP=0 
Sep 13 20:15:38 Geisbutler kernel: DresdnerBank OUTPUT: IN= OUT=ppp1000 SRC=92.228.66.220 DST=194.127.84.106 LEN=142 TOS=0x00 PREC=0x00 TTL=64 ID=7799 DF PROTO=TCP SPT=4489 DPT=443 WINDOW=2166 RES=0x00 ACK PSH URGP=0 
Sep 13 20:15:38 Geisbutler kernel: DresdnerBank INPUT: IN=ppp1000 OUT= MAC= SRC=194.127.84.106 DST=92.228.66.220 LEN=52 TOS=0x00 PREC=0x00 TTL=58 ID=34221 DF PROTO=TCP SPT=443 DPT=4489 WINDOW=33120 RES=0x00 ACK URGP=0 
Sep 13 20:15:39 Geisbutler kernel: DresdnerBank OUTPUT: IN= OUT=ppp1000 SRC=92.228.66.220 DST=194.127.84.106 LEN=126 TOS=0x00 PREC=0x00 TTL=64 ID=7800 DF PROTO=TCP SPT=4489 DPT=443 WINDOW=2166 RES=0x00 ACK PSH URGP=0 
Sep 13 20:15:40 Geisbutler kernel: DresdnerBank INPUT: IN=ppp1000 OUT= MAC= SRC=194.127.84.106 DST=92.228.66.220 LEN=52 TOS=0x00 PREC=0x00 TTL=58 ID=34222 DF PROTO=TCP SPT=443 DPT=4489 WINDOW=33120 RES=0x00 ACK URGP=0 
Sep 13 20:15:40 Geisbutler kernel: DresdnerBank INPUT: IN=ppp1000 OUT= MAC= SRC=194.127.84.106 DST=92.228.66.220 LEN=377 TOS=0x00 PREC=0x00 TTL=58 ID=34223 DF PROTO=TCP SPT=443 DPT=4489 WINDOW=33120 RES=0x00 ACK PSH URGP=0 
Sep 13 20:15:40 Geisbutler kernel: DresdnerBank OUTPUT: IN= OUT=ppp1000 SRC=92.228.66.220 DST=194.127.84.106 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7801 DF PROTO=TCP SPT=4489 DPT=443 WINDOW=2526 RES=0x00 ACK URGP=0 
Sep 13 20:15:40 Geisbutler kernel: DresdnerBank INPUT: IN=ppp1000 OUT= MAC= SRC=194.127.84.106 DST=92.228.66.220 LEN=89 TOS=0x00 PREC=0x00 TTL=58 ID=34224 DF PROTO=TCP SPT=443 DPT=4489 WINDOW=33120 RES=0x00 ACK PSH URGP=0 
Sep 13 20:15:40 Geisbutler kernel: DresdnerBank OUTPUT: IN= OUT=ppp1000 SRC=92.228.66.220 DST=194.127.84.106 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7802 DF PROTO=TCP SPT=4489 DPT=443 WINDOW=2526 RES=0x00 ACK URGP=0 
Sep 13 20:15:40 Geisbutler kernel: DresdnerBank INPUT: IN=ppp1000 OUT= MAC= SRC=194.127.84.106 DST=92.228.66.220 LEN=52 TOS=0x00 PREC=0x00 TTL=58 ID=34225 DF PROTO=TCP SPT=443 DPT=4489 WINDOW=33120 RES=0x00 ACK FIN URGP=0 
Sep 13 20:15:40 Geisbutler kernel: DresdnerBank OUTPUT: IN= OUT=ppp1000 SRC=92.228.66.220 DST=194.127.84.106 LEN=89 TOS=0x00 PREC=0x00 TTL=64 ID=7803 DF PROTO=TCP SPT=4489 DPT=443 WINDOW=2526 RES=0x00 ACK PSH URGP=0 
Sep 13 20:15:40 Geisbutler kernel: DresdnerBank OUTPUT: IN= OUT=ppp1000 SRC=92.228.66.220 DST=194.127.84.106 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7804 DF PROTO=TCP SPT=4489 DPT=443 WINDOW=2526 RES=0x00 ACK FIN URGP=0 
Sep 13 20:15:40 Geisbutler kernel: DresdnerBank INPUT: IN=ppp1000 OUT= MAC= SRC=194.127.84.106 DST=92.228.66.220 LEN=52 TOS=0x00 PREC=0x00 TTL=58 ID=34226 DF PROTO=TCP SPT=443 DPT=4489 WINDOW=33120 RES=0x00 ACK URGP=0 
Sep 13 20:15:41 Geisbutler kernel: DresdnerBank INPUT: IN=ppp1000 OUT= MAC= SRC=194.127.84.106 DST=92.228.66.220 LEN=52 TOS=0x00 PREC=0x00 TTL=58 ID=34227 DF PROTO=TCP SPT=443 DPT=4489 WINDOW=33120 RES=0x00 ACK URGP=0

Zugriff vom Client (funktioniert nicht):

Sep 13 20:16:36 Geisbutler kernel: DresdnerBank FORWARD: IN=eth1 OUT=ppp1000 SRC=192.168.255.2 DST=194.127.84.106 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=44911 DF PROTO=TCP SPT=4360 DPT=443 WINDOW=5840 RES=0x00 SYN URGP=0 
Sep 13 20:16:36 Geisbutler kernel: DresdnerBank FORWARD: IN=ppp1000 OUT=eth1 SRC=194.127.84.106 DST=192.168.255.2 LEN=64 TOS=0x00 PREC=0x00 TTL=57 ID=29115 DF PROTO=TCP SPT=443 DPT=4360 WINDOW=33304 RES=0x00 ACK SYN URGP=0 
Sep 13 20:16:37 Geisbutler kernel: DresdnerBank FORWARD: IN=eth1 OUT=ppp1000 SRC=192.168.255.2 DST=194.127.84.106 LEN=52 TOS=0x00 PREC=0x00 TTL=62 ID=44912 DF PROTO=TCP SPT=4360 DPT=443 WINDOW=2920 RES=0x00 ACK URGP=0 
Sep 13 20:16:37 Geisbutler kernel: DresdnerBank FORWARD: IN=eth1 OUT=ppp1000 SRC=192.168.255.2 DST=194.127.84.106 LEN=170 TOS=0x00 PREC=0x00 TTL=62 ID=44913 DF PROTO=TCP SPT=4360 DPT=443 WINDOW=2920 RES=0x00 ACK PSH URGP=0 
Sep 13 20:16:37 Geisbutler kernel: DresdnerBank FORWARD: IN=ppp1000 OUT=eth1 SRC=194.127.84.106 DST=192.168.255.2 LEN=52 TOS=0x00 PREC=0x00 TTL=57 ID=29116 DF PROTO=TCP SPT=443 DPT=4360 WINDOW=33304 RES=0x00 ACK URGP=0 
Sep 13 20:17:37 Geisbutler kernel: DresdnerBank FORWARD: IN=ppp1000 OUT=eth1 SRC=194.127.84.106 DST=192.168.255.2 LEN=40 TOS=0x00 PREC=0x00 TTL=248 ID=0 PROTO=TCP SPT=443 DPT=4360 WINDOW=0 RES=0x00 RST URGP=0

Habe auch schon mit wireshark am ppp1000 gelauscht, da kommt wirklich nicht mehr an

Getestet ist das alles mit mehreren Clients (3xWin XP, 1xLinux in einem Virtuellen PC), überall sieht's gleich aus
Mitschneiden auf diesen PCs ergab ebenfalls, dass diese nach dem ACK des Servers nichts mehr empfangen oder senden...

Update 14.09./14:42: Trotzdem kann ich einen Fehler an den Clients ausschließen. Habe eben zum Test einen SSH-Tunnel aufgebaut (Client -> Gateway) und durch diesen den HTTPS-Verkehr geleitet, das hat dann funktioniert. Also muss der Gateway irgendwelche Pakete verschlucken, NUR WELCHE? Denn Sniffen auf dem Gateway zeichnet ja exakt dieselben Pakete auf wie Sniffen auf einem Client, nur halt mit unterschiedlicher Ziel-IP wegen dem Masquerading...

Bin da mittlerweile echt ratlos und bitte daher euch um Hilfe!

Update 14.09./15:42: Ein einfacher Neustart des Gateways hat das Problem behoben. Fragt mich nicht, was es war, evtl. irgendeine Einstellung in /proc oder einfach nur eine böse Laune des Pinguins, aber jetzt läuft es wieder. Vielen Dank an alle

Update 04.04.: Leider tritt das Problem wieder auf! Mittlerweile hab ich rausgefunden, dass ein Neu-Aufbau der Verbindung ausreicht, das Problem zu beheben (ifdown dsl-provider && ifup dsl-provider), aber so wirklich zufriedenstellend ist das natürlich nicht.

Vielen Dank,
MrToiz

 

[MrToiz]

Ich erlaube mir mal zu schieben, nachdem das Problem erneut auftritt.

 

[Kampforca]

Wenn es nach dem ifdown & ifup wieder funktioniert, würde ich als erstes ein defektes MASQUERADE Modul vermuten, was aber keinen Sinn macht, da der TCP-Handshake + SSL-client_hello ja scheinbar durchkommt.
Da der SSL-Server auf den Handshake vom Gateway aus antwortet, würde eine defekte SSL-Implementation auf deinem Client nahelegen, dann hätte der Workaround mit dem SSH-Tunnel aber nicht funktionieren dürfen.
Das RST-Paket, dass dein Client zuletzt erhält und eine abweichend grosse TTL hat, würde nahelegen, dass du chinesischer Dissident, iranischer Blogger oder ähnliches bist und die grosse Firewall deine Verbindungen abschiesst ... Das oder dein ISP schließt eigenmächtig Verbindungen, über die 60 Sekunden nichts gelaufen ist, was er meines Wissens nach nicht tun sollte.

Schreib mal bitte deine Kernelversion, deine Kernelconfig, dein iptables -L und Details, die du eventuell ausgelassen hast ugly, hier rein.

 

[MrToiz]

Wenn es nach dem ifdown & ifup wieder funktioniert, würde ich als erstes ein defektes MASQUERADE Modul vermuten, was aber keinen Sinn macht, da der TCP-Handshake + SSL-client_hello ja scheinbar durchkommt.

Ein defektes Modul halte ich für unwahrscheinlich, da ich keine selbst kompilierten Pakete verwende sondern nur die offiziellen Debian-Pakete. Dazu kommt, dass diese wahrscheinlich mittlerweile auch noch aktualisiert wurden, denn im September war ja noch Etch aktuell, mittlerweile läuft das ganze unter Lenny.

Da der SSL-Server auf den Handshake vom Gateway aus antwortet, würde eine defekte SSL-Implementation auf deinem Client nahelegen, dann hätte der Workaround mit dem SSH-Tunnel aber nicht funktionieren dürfen.

Windows traut man ja so einiges zu, aber wie gesagt tritt der Fehler bei mehr als 5 (Windows) Clients auf und außerdem auch noch bei einem Linux, das auf einem virtuellen PC läuft (wenn auch auf einem Windows-Host, aber der hat ja mit der SSL-Implementation nix zu tun).

Das RST-Paket, dass dein Client zuletzt erhält und eine abweichend grosse TTL hat, würde nahelegen, dass du chinesischer Dissident, iranischer Blogger oder ähnliches bist und die grosse Firewall deine Verbindungen abschiesst ... Das oder dein ISP schließt eigenmächtig Verbindungen, über die 60 Sekunden nichts gelaufen ist, was er meines Wissens nach nicht tun sollte.

Nein, eigentlich sitze ich in Mittelhessen und vermeide politische Inhalte im Internet Der Provider ist übrigens Alice.

Schreib mal bitte deine Kernelversion, deine Kernelconfig, dein iptables -L und Details, die du eventuell ausgelassen hast ugly, hier rein.

Kernelversion und Kernelconfig? Wie find ich das raus?

moritz@Geisbutler:~$ uname -a
Linux Geisbutler 2.6.26-1-486 #1 Fri Mar 13 17:25:45 UTC 2009 i686 GNU/Linux

Meine /boot/config-2.6.26-1-486

iptables sehen im Moment so aus, allerdings tritt das Problem auch mit der oben geposteten Minimal-Konfiguration auf. Die ganzen "anywhere" kommen daher, dass ich hauptsächlich nach Interface filtere, was ja leider nicht angezeigt wird.
Ausgabe von iptables -L
Das Script, das die Regeln erstellt (basierend auf dem Easy Firewall Generator).

Sonstige Details fallen mir jetzt nicht wirklich ein, das ist ja gerade das Problem: Ich sehe absolut keinen Ansatzpunkt und der Fehler ist nicht reproduzierbar. Gelegentlich tritt er auf, aber hervorrufen kann ich ihn nicht.