telekom verhindert manche TCP-verbindungen - WTF?
Verfasst: Di 22 Mär, 2011 09:52
hallo,
da sitzt ich letztens bei freunden in kärnten, werd zuerst mit einem feinen abendessen bestochen und bekomm dann ein notebook auf den tisch gestellt mit der bitte, mir anzuschauen, warum da eine remote desktop-verbindung ins büro nicht mehr klappt.
herausgestellt hat sich nach einer ausführlichen debugging-session, daß ein gerät bei der telekom auf bestimmte TCP-SYN-pakete ein RST zurückschickt, den verbindungsaufbau also verhindert. konkret schaut das so aus:
(hier werden SYN-pakete mit ansteigender TTL gesendet, also so wie's traceroute tut). offenbar sabotiert das gerät hinter 10.0.0.138 diese verbindung, indem es ein RST-ACK-paket vom echten server fälscht.
der auslöser für dieses verhalten scheint der source-port des SYN-paketes zu sein -- wenn der niedrig (also ab 1024) ist, gibt's die resets, wenn er hoch ist (wie bei einem linux ab 49000), geht die verbindung durch.
außerdem scheint für die ports 25, 53, 80, 110, 443 diese sabotage-funktion ganz abgeschaltet zu sein.
zwei fragen dazu:
a) hat das schon mal wer gesehen und weiß genaueres?
b) wie bringt man der telekom bei, das abzudrehen? beim support anzurufen wird wenig chancen auf erfolg haben, befürchte ich.
ciao,
cm.
da sitzt ich letztens bei freunden in kärnten, werd zuerst mit einem feinen abendessen bestochen und bekomm dann ein notebook auf den tisch gestellt mit der bitte, mir anzuschauen, warum da eine remote desktop-verbindung ins büro nicht mehr klappt.
herausgestellt hat sich nach einer ausführlichen debugging-session, daß ein gerät bei der telekom auf bestimmte TCP-SYN-pakete ein RST zurückschickt, den verbindungsaufbau also verhindert. konkret schaut das so aus:
- Code: Alles auswählen
$ sudo hping3 -S -T -p 3389 123.456.789.123
HPING 123.456.789.123 (wlan0 123.456.789.123) S set, 40 headers + 0 data bytes
hop=1 TTL 0 during transit from ip=192.168.1.1 name=UNKNOWN
hop=1 hoprtt=1.6 ms
hop=2 TTL 0 during transit from ip=10.0.0.138 name=UNKNOWN
hop=2 hoprtt=1.5 ms
len=40 ip=123.456.789.123 ttl=125 id=40718 sport=3389 flags=RA seq=2 win=0 rtt=2
(hier werden SYN-pakete mit ansteigender TTL gesendet, also so wie's traceroute tut). offenbar sabotiert das gerät hinter 10.0.0.138 diese verbindung, indem es ein RST-ACK-paket vom echten server fälscht.
der auslöser für dieses verhalten scheint der source-port des SYN-paketes zu sein -- wenn der niedrig (also ab 1024) ist, gibt's die resets, wenn er hoch ist (wie bei einem linux ab 49000), geht die verbindung durch.
außerdem scheint für die ports 25, 53, 80, 110, 443 diese sabotage-funktion ganz abgeschaltet zu sein.
zwei fragen dazu:
a) hat das schon mal wer gesehen und weiß genaueres?
b) wie bringt man der telekom bei, das abzudrehen? beim support anzurufen wird wenig chancen auf erfolg haben, befürchte ich.
ciao,
cm.