Cisco dropt verkeer van www.ov-chipkaart.nl

[TNW]

De laatste dagen kan ik www.ov-chipkaart.nl niet vanaf mijn netwerk bereiken. Ik heb al een tijd een Cisco 851W staan die het verder prima doet.

Vandaag ben ik dit probleem eens gaan onderzoeken.

Eerst was het om de een of andere reden niet mogelijk www.ov-chipkaart te pingen vanaf 2 verschillende windows machines in het netwerk. Ik kreeg dan Destination net unknown, wat door de Cisco gegenereerd leek te zijn want pingen vanaf de Cisco zelf werkte wel prima.

Nu kan ik opeens wel weer pingen naar de site, maar als ik hem opvraag in de browser zie ik dit in de debug langsrollen:

Feb  9 13:18:34.467: %FW-3-RESPONDER_WND_SCALE_INI_NO_SCALE: Dropping packet - Invalid Window Scale option for session 192.168.64.2:2604 to 80.79.42.79:80 [Initiator(flag 0,factor 0) Responder (flag 1, factor 4)]

Dit is trouwens het enige wat ik zie langsrollen wat gerelateerd is, er worden geen firewallregels getriggerd.

Nu heb ik een goede basiskennis van netwerken maar wat er hier gebeurt snap ik niet. Volgens webpagina's over deze error komt het omdat een tussenliggende router een optie in de packets veranderd waardoor deze niet meer aan een bepaalde RFC voldoen, en daarom dropt de Cisco het.

Hoe kan je dit oplossen, of het laten negeren? Alle andere websites werken gewoon...

ps: softwareversie uitvoer:

ruthenium#sh version
Cisco IOS Software, C850 Software (C850-ADVSECURITYK9-M), Version 12.4(15)T7, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Thu 14-Aug-08 07:18 by prod_rel_team

ROM: System Bootstrap, Version 12.3(8r)YI4, RELEASE SOFTWARE

ruthenium uptime is 59 minutes
System returned to ROM by reload at 13:30:33 UTC Tue Feb 9 2010
System restarted at 13:31:13 UTC Tue Feb 9 2010
System image file is "flash:c850-advsecurityk9-mz.124-15.T7.bin"

<snip>

Cisco 851W (MPC8272) processor (revision 0x300) with 59392K/6144K bytes of memory.
Processor board ID FHK12392DJ4
MPC8272 CPU Rev: Part Number 0xC, Mask Number 0x10
5 FastEthernet interfaces
1 802.11 Radio
128K bytes of non-volatile configuration memory.
20480K bytes of processor board System flash (Intel Strataflash)

Configuration register is 0x2922

[Kabouterplop01]

Kun je wat vertellen over het type wan verbinding waar dit aan hangt?
misschien een show run van je cisco zonder pwasswd's enzo

[Rendier2710]

CSCsc37281 Bug Details
CBAC - TCP window scale option checking enhancement
Symptoms: TCP connections may not be established between an end device that
has TCP stacks that are not RFC-compliant and a platform that has a Cisco IOS
firewall enabled.

Conditions: This symptom is observed when the platform that has the Cisco IOS
firewall enabled enforces strict checking for a TCP Window Scale option per
RFC1323 section 2.

Workaround: There is no workaround. Note that the Cisco IOS firewall
functions properly.

Further Problem Description: This is an enhancement request. For Cisco IOS
software images that implement this enhancement, the Cisco IOS firewall makes
an exception to RFC1323 section 2 so TCP connections can be established
between the platform that has the Cisco IOS firewall enabled and an end
device has TCP stacks that are not RFC-compliant.

Fixed-In
12.4(7.23)M
12.4(4)T3
12.4(4)XD2
12.4(6)T1
12.4(6.6)T
12.4(22.3.4)PIC1
12.4(24.5.2)PIC1

Maar gek genoeg zou het dan opgelost moeten zijn in jou IOS versie...

[ Voor 3% gewijzigd door Rendier2710 op 09-02-2010 20:19 ]

[serkoon]

Ik heb eens zitten turen. RFC 1323 zegt over de window scale option:

It may also be sent in a <SYN,ACK> segment, but only if a Window Scale option was received in the initial <SYN> segment.

In een Wireshark dump zie ik echter dat 80.79.42.79 (www.ov-chipkaart.nl) in de SYN/ACK dus wel een window scale option meestuurt, terwijl in de SYN vanaf mijn systeem die optie niet meegestuurd werd. Hun stack is dus gewoon niet RFC-compliant bezig. Misschien een idee om ze daar even op te wijzen zodat ze dat eventueel kunnen fixen.

[TrailBlazer]

Interessant probleem. Ik vraag me af op welk exotisch platform ze dan draaien. Het lijkt me niet echt een optie die je aanzet op je server.

[CyBeR]

TrailBlazer schreef op woensdag 10 februari 2010 @ 19:13:
Interessant probleem. Ik vraag me af op welk exotisch platform ze dan draaien. Het lijkt me niet echt een optie die je aanzet op je server.

Klinkt meer als een firewall die iets loopt te manglen. 't zal in dit geval wel niet, maar Cisco maakt zich daar ook schuldig aan bij PIX en SMTP mangling bijvoorbeeld. Met een mailserver achter zo'n ding valt geen fatsoenlijk ESMTP te praten.

[TrailBlazer]

enigzins offtopic. Zo hadden we laatst een firewall die SQL naar een Linux server verpestte terwijl het naar een Windows SQL server wel goed ging.

[Predator]

serkoon schreef op woensdag 10 februari 2010 @ 13:10:
Ik heb eens zitten turen. RFC 1323 zegt over de window scale option:

[...]


In een Wireshark dump zie ik echter dat 80.79.42.79 (www.ov-chipkaart.nl) in de SYN/ACK dus wel een window scale option meestuurt, terwijl in de SYN vanaf mijn systeem die optie niet meegestuurd werd. Hun stack is dus gewoon niet RFC-compliant bezig. Misschien een idee om ze daar even op te wijzen zodat ze dat eventueel kunnen fixen.

Er is helaas nog heel wat apparatuur en software actief wat helemaal niet RFC compliant is.
Vooral in SMTP relays kom je zo'n dingen vaak tegen.

In het geval dat het over een 'grijs' gebied gaat (bv probleem tussen 2 mailservers van een verschillende partij), dan sta je een stuk sterker als blijkt dat het probleem veroorzaakt wordt door het niet navolgen van de RFC richtlijnen. Ik heb helaas ook al vele discussies gehad met externe partijen (veelal ivm smtp) en gewonnen op die manier. Echter de tegenpartij wil niet altijd zich aanpassen, ook al geven de netwerktraces icm de RFC jou gelijk.

Als je weinig of niets te maken hebt met de andere partij, dan heb je nog minder kans op resultaat...

[TNW]

serkoon schreef op woensdag 10 februari 2010 @ 13:10:
Ik heb eens zitten turen. RFC 1323 zegt over de window scale option:

[...]


In een Wireshark dump zie ik echter dat 80.79.42.79 (www.ov-chipkaart.nl) in de SYN/ACK dus wel een window scale option meestuurt, terwijl in de SYN vanaf mijn systeem die optie niet meegestuurd werd. Hun stack is dus gewoon niet RFC-compliant bezig. Misschien een idee om ze daar even op te wijzen zodat ze dat eventueel kunnen fixen.

Kijk, dat is nou een profi analyse.

Ik ga ze maar een mailtje sturen, ze zijn de enige, zoniet een van de weinige sites die hier niet opvraagbaar zijn door dit geintje en het zou kunnen zijn dat meer mensen achter Cisco apparatuur hierdoor geblokkeerd worden. Lijkt me niet echt handig voor een site die waarschijnlijk door veel mensen wordt opgevraagd.

[Johnny E]

Wij hebben hier het zelfde, zitten ook achter een Cisco IOS FW http://www.ov-chipkaart.nl werkt niet...
tot je https://www.ov-chipkaart.nl probeert, die werkt dus wel.

[salvador4]

Ik zit ook achter een IOS fw, maar hier werkt de site echter prima. Ik heb de volgend inspect rules actief;

ip inspect name fw udp
ip inspect name fw esmtp
ip inspect name fw ftp
ip inspect name fw icmp
ip inspect name fw tcp

[Zoetjuh]

Wij ondervonden laatst ook een dergelijk probleem.

Bij ons bleek de oplossing te zitten in het aanpassen van de MTU van 1500 naar 1452.

In dat geval bleek het te maken te hebben met KPN ADSL verbindingen die gemigreerd waren en bij de ISP via Ethernet afgeleverd werden ipv op ATM niveau (als ik het destijds goed gevolgd heb). Een uitzonderlijke site was na de migratie met een MTU van 1500 op de router niet meer te benaderen. Na de aanpassing van de MTU terug naar 1452 werkte weer als vanouds.

Correspondere commando was in ons geval 'ip tcp adjust-mss 1452' op de eth0.

[ Voor 7% gewijzigd door Zoetjuh op 11-02-2010 21:24 ]

[Kabouterplop01]

Zoetjuh schreef op donderdag 11 februari 2010 @ 21:23:
Wij ondervonden laatst ook een dergelijk probleem..

Correspondere commando was in ons geval 'ip tcp adjust-mss 1452' op de eth0.

Daar hoort een mtu van 1492 bij

[Johnny E]

En wat gebeurt er als je inspect voor Http inschakeld?

salvador4 schreef op donderdag 11 februari 2010 @ 21:00:
Ik zit ook achter een IOS fw, maar hier werkt de site echter prima. Ik heb de volgend inspect rules actief;

ip inspect name fw udp
ip inspect name fw esmtp
ip inspect name fw ftp
ip inspect name fw icmp
ip inspect name fw tcp

[salvador4]

Dan werkt de site nog steeds. Mijn wan interface heeft een MTU van 1500.

[Dennism]

Kabouterplop01 schreef op vrijdag 12 februari 2010 @ 08:31:
[...]


Daar hoort een mtu van 1492 bij

1452 is ook een voorkomende variant, pas geleden nog ondervonden. Ook een probleempje waarbij enkele sites niet benaderbaar waren.

[TNW]

Ik heb de MTU ook aangepast, zonder enig effect. Viel te verwachten, het probleem ligt namelijk niet aan de packetgrootte maar aan hoe de server reageert.

Johnny E schreef op donderdag 11 februari 2010 @ 17:44:
Wij hebben hier het zelfde, zitten ook achter een Cisco IOS FW http://www.ov-chipkaart.nl werkt niet...
tot je https://www.ov-chipkaart.nl probeert, die werkt dus wel.

Dank je voor de tip, dit werkt. In ieder geval een redelijk makkelijke workaround.

Ik heb trouwens een reactie van de OV chipkaart website:

Geachte heer,

Dank u wel voor uw reactie van 11-02-2010.

Excuses voor de late reactie van onze kant. Door grote drukte hebben wij een langere beantwoordingstijd nodig gehad dan u van ons gewend bent.

Wij vinden het vervelend te horen dat u problemen ondervindt in het gebruik van onze website. Wij zijn continu bezig de website alsmede haar applicaties te verbeteren een aan te passen; de door u toegezonden informatie komt daarbij zeker van pas. Mocht u op dit moment problemen blijven ondervinden willen wij u verzoeken dit eventueel via een andere internetverbinding/computer te proberen. Onze excuses voor het ongemak.

Wij hopen u hiermee voldoende geinformeerd te hebben.

Met vriendelijke groet,

<naam>
Klantenservice OV-chipkaart

Niet echt een bevredigend antwoord in mijn ogen. Geen harde bevestiging dat men het intern gaat uitzoeken en de suggestie dat het allemaal continu verbeterd wordt. Hun workaround is "gewoon" een andere internetverbinding gebruiken. Niet echt praktisch voor de gem. pipo (maar die hebben dan ook geen Cisco staan ).

Ik mail ze nog wel. Dit is geen echte Cisco issue maar een ov-chipkaart.nl issue en zij moeten het maar fixen zodat het werkt als alle 99,99 procent van de websites die gewoon bereikbaar zijn.