Een website onbereikbaar

[Trema]

Bij een klant van me speelt het volgende probleem: vanaf hun netwerk is de website voor telebankieren van de ING sinds een maand of 2 niet meer te bereiken. De algemene website van ING doet het wel normaal, maar zodra je klikt op de link om te telebankieren gebeurt er een tijd niets en volgt alleen nog een time-out. Ook als je de bewuste URL direct intypt gebeurt er niets.

Meer details: klant heeft een zakelijke ADSL-aansluiting van XS4ALL met een vast IP-adres, intern netwerk achter NAT-router. De bewuste site is https://mijn.ing.nl (SSL). Andere sites (waaronder SSL) zijn normaal te bereiken.

Ik heb al een keer met een gloednieuw ADSL-modem met daaraan alleen m'n eigen laptop in de serverruimte gezeten, maar ook dan werkt het niet. De technische helpdesk van ING komt niet verder dan het nalopen van de browserinstellingen, maar daar ligt het zeker niet aan (ik bankier zelf ook bij ING, ook op deze laptop, en op m'n kantoor werkt dat gewoon). Tevens beweren zij dat het IP-adres van de klant niet geblokkeerd wordt.

Verder heb ik met de helpdesk van XS4ALL gebeld. Ook zij zeggen dan zij geen verkeer van de klant blokkeren. Wel deden zij nog de suggestie om het via hun proxyserver (wwwproxy.xs4all.nl) te proberen, en inderdaad, alleen dan werkt het wel!

Dat is natuurlijk een mooie work-around, maar laat onverlet dat er dus ergens "onderweg" iets fout zit. Wat kan dat zijn? Vanaf de klant, kantoor (Online) en thuis (Telfort) heb ik nog een traceroute uitgevoerd, maar deze komen allemaal tot static.kpn.net (193.172.170.10) en time-out-en daarna.

Ik heb even geen ideeën meer, wie wel?

[Yohost!]

Traceroute loopt bij mij ook dood, waarschijnlijk geblokkeerd dus.

Kan je wel telnetten naar poort 80/443 ?

[Verwijderd]

Wat doet het niet?
- Connectie niet tot stand komen
- Webserver van ING sluit de connectie
- Webserver van ING geeft een responsecode anders dan 2XX of 3XX terug

Debuggen:
- Doe eens "dig mijn.ing.nl" in terminal (of nslookup of host), hier zou 145.221.55.11 uit moeten komen
- Sniff het eens met firebug of wireshark
- Doet Zakelijk het wel?
- Al eens geprobeerd met een andere browser zoals "lynx https://mijn.ing.nl/"?
- Al eens geprobeerd met een ander OS, kan zijn dat Windows niet de juiste certificaten vertrouwt

[Trema]

Bedankt voor de suggesties en het meedenken!

Yohost! schreef op dinsdag 27 oktober 2009 @ 16:45:
Traceroute loopt bij mij ook dood, waarschijnlijk geblokkeerd dus.

Kan je wel telnetten naar poort 80/443 ?

Nee, net geprobeerd: het blijft stil na "Trying 145.221.55.11...".

Verwijderd schreef op dinsdag 27 oktober 2009 @ 16:55:
Wat doet het niet?
- Connectie niet tot stand komen
- Webserver van ING sluit de connectie
- Webserver van ING geeft een responsecode anders dan 2XX of 3XX terug

Dat eerste, er komt helemaal niets terug.

Debuggen:
- Doe eens "dig mijn.ing.nl" in terminal (of nslookup of host), hier zou 145.221.55.11 uit moeten komen
- Sniff het eens met firebug of wireshark
- Doet Zakelijk het wel?
- Al eens geprobeerd met een andere browser zoals "lynx https://mijn.ing.nl/"?
- Al eens geprobeerd met een ander OS, kan zijn dat Windows niet de juiste certificaten vertrouwt

code:

# dig mijn.ing.nl

; <<>> DiG 9.4.2-P2 <<>> mijn.ing.nl
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15147
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mijn.ing.nl.                   IN      A

;; ANSWER SECTION:
mijn.ing.nl.            190     IN      A       145.221.55.11

;; Query time: 17 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Tue Oct 27 21:57:32 2009
;; MSG SIZE  rcvd: 45

Wireshark laat zien dat er alleen SYN-pakketjes naar buiten gaan.

code:

No.     Time        Source                Destination           Protocol Info
      1 0.000000    (servernaam) 145.221.55.11         TCP      7963 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460
      2 2.965739    (servernaam) 145.221.55.11         TCP      7963 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460
      3 8.898937    (servernaam) 145.221.55.11         TCP      7963 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460
      4 21.004811   (servernaam) 145.221.55.11         TCP      7964 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460
      5 23.986457   (servernaam) 145.221.55.11         TCP      7964 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460
      6 29.920883   (servernaam) 145.221.55.11         TCP      7964 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460

(Hieronder het eerste stukje van de pakketten-"lawine" als ik vanaf dezelfde machine naar www.ing.nl ga:)

code:

No.     Time        Source                Destination           Protocol Info
      1 0.000000    (servernaam) www.ing.nl            TCP      8094 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460
      2 0.017868    www.ing.nl            (servernaam) TCP      http > 8094 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1402
      3 0.017877    (servernaam) www.ing.nl            TCP      8094 > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
      4 0.018255    (servernaam) www.ing.nl            HTTP     GET / HTTP/1.1 
      5 0.040240    www.ing.nl            (servernaam) HTTP     HTTP/1.1 302 Object moved 
      6 0.040275    (servernaam) www.ing.nl            TCP      8094 > http [ACK] Seq=479 Ack=81 Win=65456 [TCP CHECKSUM INCORRECT] Len=0
      7 0.041033    (servernaam) www.ing.nl            TCP      8094 > http [FIN, ACK] Seq=479 Ack=81 Win=65456 [TCP CHECKSUM INCORRECT] Len=0
      8 0.058724    www.ing.nl            (servernaam) TCP      http > 8094 [ACK] Seq=81 Ack=480 Win=65456 Len=0
      9 0.072767    (servernaam) www.ing.nl            TCP      8095 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460
     10 0.090824    www.ing.nl            (servernaam) TCP      http > 8095 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1402
     11 0.090835    (servernaam) www.ing.nl            TCP      8095 > http [ACK] Seq=1 Ack=1 Win=65535 [TCP CHECKSUM INCORRECT] Len=0
     12 0.091211    (servernaam) www.ing.nl            HTTP     GET / HTTP/1.1 
     13 0.117818    www.ing.nl            (servernaam) HTTP     HTTP/1.1 302 Found  (text/html)
     14 0.169249    (servernaam) www.ing.nl            HTTP     GET /particulier/index.aspx HTTP/1.1 
     15 0.222875    www.ing.nl            (servernaam) TCP      [TCP segment of a reassembled PDU]

mijnzakelijk.ing.nl kende ik nog niet. Ander IP zag ik (145.221.55.9), helaas ook geen succes.

Andere browser (in dit geval elinks) op een Ubuntu 8.04 server geeft ook dezelfde uitkomst. (Had ik inderdaad al geprobeerd, vergeten te melden in openingspost.) Voor de zekerheid net nog eens overgedaan, maar het blijft muisstil.

[leuk_he]

mijn.ing.nl kan ik ook niet pingen, maar wel met de browser benaderen. Ik heb ook xs4all.

traceroute stopt ook bij mij met (ik heb xs4all)

code:

 8   284 ms   288 ms   157 ms  static.kpn.net [139.156.113.137]
 9   282 ms   285 ms    76 ms  195.190.233.57
10   287 ms   265 ms   165 ms  rt-dc2-ias-arg17.nl.kpn.net [195.190.227.144]
11   270 ms   287 ms   264 ms  static.kpn.net [193.172.170.10]
12     *        *        *     Request timed out.

"telnet mijn.ing.nl 443" maakt connectie... telnet mijn.ing.nl (poort 80) niet.

Ping is dus geen goed diagnose middel.

[yassine]

Welk modem ?

[Trema]

leuk_he schreef op dinsdag 27 oktober 2009 @ 22:58:
"telnet mijn.ing.nl 443" maakt connectie... telnet mijn.ing.nl (poort 80) niet.

Ping is dus geen goed diagnose middel.

Dat klopt - in dit geval.

yassine schreef op dinsdag 27 oktober 2009 @ 23:02:
Welk modem ?

Het modem is een Draytek Vigor2800. Ik heb ook een ander modem gebruikt, dat was Zyxel P-2602H-D1A. Maar dat maakte, zoals gezegd, geen verschil.

Moet ik opnieuw XS4ALL vragen ernaar te kijken of zie ik ergens nog iets over het hoofd?

[gertvdijk]

Ik heb iets soortgelijks meegemaakt (zelfde soort tcpdumps) met bepaalde websites wat bleek te liggen aan de foutieve instelling in de router met betrekking tot MTU waarden naar de WAN interface. Een zogenaamde Clamp MSS op enabled zetten verhielp alles.
Het komt erop neer dat de PPP interface naar buiten toe met een MTU van bijv. 1492 is en je interne netwerk op de standaard MTU van 1500 draait en daarmee moet wel rekening worden gehouden. Dus: heb je zo'n instelling op de router? Wat gebruik je als router (niet modem)? En is de router op de hoogte van de MTU van de WAN interface? Bij PPP** verbindingen is dat meestal 14xx namelijk.
Bij jou lijkt hetzelfde van toepassing omdat ik kan zien dat jij geen MTU van 1500 naar buiten hebt (je MSS is kleiner dan 1460).
Laat eens de gehele tcpdump/wireshark dump zien van een bezoek aan de betreffende website. Paste op pastebin, want direct hier plaatsen is niet zo aan te raden.

[ Voor 31% gewijzigd door gertvdijk op 28-10-2009 00:46 ]

[Verwijderd]

Mensen, dit is een KPN probleem. DNS werkt goed (vandaag dat hij het IP vindt). Een ping hoeft niet per se te werken. Het kan ook dat ING dat heeft afgesloten (bij mij werkt hij ook niet, en ik zit via Compuserve)

Dit is een route probleem op hoger nivo. Ik heb een tijdje als netwerk controller gewerkt bij BT, en als een klant zeurde over bepaalde websites, was het 9 van de 10 keer een verkeerde route tabel (bij BT dus). De klanten waren dus ISP's over heel Europa. M.a.w. xs4all moet een beetje beter zijn best doen (richting KPN). Ze zijn niet de goedkoopste, en daar loopt wel volk rond dat weet wat internet inhoudt. Niet van die domme call center miepjes die een standaard script afdreunen.

Gewoon klagen tot zij het opgelost hebben.

[Trema]

gertvdijk schreef op woensdag 28 oktober 2009 @ 00:35:
Ik heb iets soortgelijks meegemaakt (zelfde soort tcpdumps) met bepaalde websites wat bleek te liggen aan de foutieve instelling in de router met betrekking tot MTU waarden naar de WAN interface. Een zogenaamde Clamp MSS op enabled zetten verhielp alles.
Het komt erop neer dat de PPP interface naar buiten toe met een MTU van bijv. 1492 is en je interne netwerk op de standaard MTU van 1500 draait en daarmee moet wel rekening worden gehouden. Dus: heb je zo'n instelling op de router? Wat gebruik je als router (niet modem)? En is de router op de hoogte van de MTU van de WAN interface? Bij PPP** verbindingen is dat meestal 14xx namelijk.
Bij jou lijkt hetzelfde van toepassing omdat ik kan zien dat jij geen MTU van 1500 naar buiten hebt (je MSS is kleiner dan 1460).
Laat eens de gehele tcpdump/wireshark dump zien van een bezoek aan de betreffende website. Paste op pastebin, want direct hier plaatsen is niet zo aan te raden.

Het netwerk van de klant bestaat uit het ADSL-modem met daaraan twee HP Procurve 2650 switches. Naast het ADSL-modem verder geen routers dus.

Telnet met modem:

code:

> wan ppp_mss ?
% wan ppp_mss <MSS size: 1000 ~ 1500>
% Now: 1442

Wireshark-dump van het openen van de normale ING-pagina.

[Verwijderd]

Staat er bij jou een Draytek router? Ik zie namelijk in de Wireshark dum een volgende regel:

Ethernet II, Src: Draytek_b4:27:68 (00:50:7f:b4:27:68)

Het kan ook zijn, dat het van de Postbank is.

[gertvdijk]

Trema schreef op woensdag 28 oktober 2009 @ 09:59:
Wireshark-dump van het openen van de normale ING-pagina.

Die bedoelde ik niet
Het gaat natuurlijk om de dump bij het laden van de pagina die niet lukt! (mijn.ing.nl)

Maar sowieso horen er niet zoveel TCP checksum errors te zijn. Lijkt me toch wel duiden op ofwel:

• verkeerde MTU instellingen
• brakke netwerkverbindingen/NICs
• brak modem

Heb je het bij het bezoeken van meer pagina's (die TCP checkum errors)?

[ Voor 29% gewijzigd door gertvdijk op 28-10-2009 13:57 ]

[Trema]

Verwijderd schreef op woensdag 28 oktober 2009 @ 13:15:
Staat er bij jou een Draytek router? Ik zie namelijk in de Wireshark dum een volgende regel:

Ethernet II, Src: Draytek_b4:27:68 (00:50:7f:b4:27:68)

Het kan ook zijn, dat het van de Postbank is.

Klopt, een Draytek Vigor 2800 series (voorzien van de meest recente firmware.

gertvdijk schreef op woensdag 28 oktober 2009 @ 13:54:
[...]

Die bedoelde ik niet
Het gaat natuurlijk om de dump bij het laden van de pagina die niet lukt! (mijn.ing.nl)

Sorry hoor, die staat hier.

Maar sowieso horen er niet zoveel TCP checksum errors te zijn. Lijkt me toch wel duiden op ofwel:

• verkeerde MTU instellingen
• brakke netwerkverbindingen/NICs
• brak modem

Heb je het bij het bezoeken van meer pagina's (die TCP checkum errors)?

Ik begin het idee te krijgen dat het modem "een beetje" kapot is, helaas niet kapot genoeg om er helemaal mee te stoppen. Ik heb net wat rondgesurfd (diverse websites) en met Wireshark gecaptured. Van de 3152 frames staan er bij 737 TCP CHECKSUM ERROR.

Een medewerker van XS4ALL vroeg me vanochtend tcptraceroute eens te proberen. Ik kende het nog niet, erg handig! Normaal zou de output er zo uit kunnen zien:

code:

~$ tcptraceroute mijn.ing.nl 443
Selected device eth1, address 192.168.2.2, port 51897 for outgoing packets
Tracing the path to mijn.ing.nl (145.221.55.11) on TCP port 443 (https), 30 hops max
 1  192.168.2.1  1.237 ms  0.647 ms  0.679 ms
 2  xxx-xxx-xxx-xxx.ip.telfort.nl (xxx.xxx.xxx.xxx)  59.123 ms  19.321 ms  19.499 ms
 3  xxx.yyy.zzz.ip.telfort.nl (yyy.yyy.yyy.yyy)  20.976 ms  21.484 ms  21.203 ms
 4  xxx.yyy.zzz.ip.telfort.nl (zzz.zzz.zzz.zzz)  21.821 ms  21.286 ms  21.269 ms
 5  xxx.yyy.zzz.ip.telfort.nl (qqq.qqq.qqq.qqq)  21.210 ms  21.285 ms  21.225 ms
 6  rt-dc2-ias-csg01.nl.kpn.net (193.172.66.193)  23.243 ms  23.049 ms  23.222 ms
 7  * * *
 8  static.kpn.net (139.156.113.137)  23.914 ms  24.870 ms  23.936 ms
 9  rt-dc2-ipc-dr01.nl.kpn.net (195.190.233.41)  25.224 ms  23.124 ms  25.129 ms
10  nl-rt-dc2-ias-arg17.kpn.net (195.190.227.124)  23.680 ms  24.069 ms  24.195 ms
11  static.kpn.net (193.172.170.10)  25.936 ms  25.030 ms  24.929 ms
12  * * *
13  145.221.55.11 [open]  24.892 ms  26.088 ms *

Bij de klant gebeurt er dus dit:

code:

$ tcptraceroute mijn.ing.nl 443
Selected device eth0, address 192.168.1.3, port 43411 for outgoing packets
Tracing the path to mijn.ing.nl (145.221.55.11) on TCP port 443 (https), 30 hops max
 1  * * *
 2  * * *
 3  * * *

en dat gaat dan zo nog een tijdje door. Tenminste het ADSL-modem zou als eerste moeten staan, maar niks.

Goed, morgen ga ik er (opnieuw) met een ander modem naartoe. Ben benieuwd wat er dan gebeurt. De vorige keer lostte dat niets op...

[DukeBox]

Evt. kan je xs4all nog vragen de traceroute te doen vanaf jouw gateway (dus jouw eerste hop na je modem). Dan is de kans dat het aan je modem ligt nog groter.
Overigens, heb je je HP's in routing mode staan ?

[gertvdijk]

Trema schreef op woensdag 28 oktober 2009 @ 16:17:
Ik begin het idee te krijgen dat het modem "een beetje" kapot is, helaas niet kapot genoeg om er helemaal mee te stoppen. Ik heb net wat rondgesurfd (diverse websites) en met Wireshark gecaptured. Van de 3152 frames staan er bij 737 TCP CHECKSUM ERROR.

Ik denk dat dit de kern van het probleem is. Het hoeft overigens niet eens een probleem te zijn aan jouw kant van de routering, wat haik01 ook terecht opmerkt.

Probeer eens de router in bridging mode te zetten, zodat je op het syteem waarvan je test direct een extern IP hebt. Dan kan je de lokale routering uitsluiten.

[RobIII]

Trema schreef op woensdag 28 oktober 2009 @ 16:17:
Ik heb net wat rondgesurfd (diverse websites) en met Wireshark gecaptured. Van de 3152 frames staan er bij 737 TCP CHECKSUM ERROR.

Dat is niet per sé een "een beetje kapot modem":

quote: http://wiki.wireshark.org/TCP_Checksum_Verification

TCP checksum offloading (lots of checksum errors)

There are causes where you might see lots of checksum errors.

If you capture on a recent Ethernet NIC, you may see many such "checksum errors". This is due to TCP Checksum offloading often being implemented on those NICs and thus, for packets being transmitted by the machine. The checksum will not be calculated until the packet is sent out by the NIC hardware, long long after your capture tool intercepted the packet from the network stack.

As this may be confusing and will prevent Wireshark from reassemble TCP segments it's a good idea to switch checksum verification off in these cases.

To disable checking of the TCP checksum validity, go to the TCP preferences and untick the box for checksum verification

[Verwijderd]

"Ik heb al een keer met een gloednieuw ADSL-modem met daaraan alleen m'n eigen laptop in de serverruimte gezeten, maar ook dan werkt het niet. De technische helpdesk van ING komt niet verder dan het nalopen van de browserinstellingen, maar daar ligt het zeker niet aan"

Dat betekent, dat het probleem niet aan jou kant ligt, maar bij XS4ALL.

[leuk_he]

Het feit dat de proxy van xs4allwel , en andere mensen van xs4all wel kunnen wil het zeggen dat je bij xs4all moet zijn. Wijs ze maar op dit topic lijkt me.

Die checksum error komt bij mij ook als ik checksum offloading aan heb staan.

[ Voor 20% gewijzigd door leuk_he op 28-10-2009 17:30 ]

[Trema]

RobIII schreef op woensdag 28 oktober 2009 @ 16:27:
[...]

Dat is niet per sé een "een beetje kapot modem":

[...]

Het gekke is wel dat ik vanochtend het modem vervangen heb en dat tcptraceroute nu wél bruikbare output produceert. Maar je hebt gelijk, dat bewijst nog niks. (En de TCP checksum errors zijn inderdaad gebleven.)

code:

$ tcptraceroute mijn.ing.nl 443
Selected device eth0, address 192.168.1.3, port 40279 for outgoing packets
Tracing the path to mijn.ing.nl (145.221.55.11) on TCP port 443 (https), 30 hops max
 1  192.168.1.2  1.044 ms  0.811 ms  0.797 ms
 2  195.190.242.1  17.096 ms  17.288 ms  14.864 ms
 3  42.ge-2-1-0.xr3.3d12.xs4all.net (194.109.5.113)  16.725 ms  16.574 ms  17.601 ms
 4  42.ge-2-1-0.xr3.3d12.xs4all.net (194.109.5.113)  16.473 ms  17.003 ms  16.185 ms
 5  asd2-rou-1002.NL.eurorings.net (134.222.97.17)  16.730 ms  16.649 ms  56.472 ms
 6  obl-rou-1021.NL.eurorings.net (134.222.231.201)  17.625 ms  18.184 ms  17.937 ms
 7  * * *
 8  * * *
 9  static.kpn.net (139.156.113.139)  18.112 ms  18.224 ms  18.636 ms
10  * * *
11  * * *
12  static.kpn.net (193.172.170.10)  18.174 ms  19.888 ms  19.189 ms
13  * * *
<knip>
30  * * *
Destination not reached

[Trema]

Verwijderd schreef op woensdag 28 oktober 2009 @ 16:30:
[...]

Dat betekent, dat het probleem niet aan jou kant ligt, maar bij XS4ALL.

leuk_he schreef op woensdag 28 oktober 2009 @ 17:29:
Het feit dat de proxy van xs4allwel , en andere mensen van xs4all wel kunnen wil het zeggen dat je bij xs4all moet zijn. Wijs ze maar op dit topic lijkt me.

Dat heb ik bij het (hernieuwd) aanmelden van dit probleem ook gedaan en ik heb het gevoel dat ze er nu ook serieus mee bezig zijn.