Bizarre bizarre…
Well, I have an issue since a week or more… As some readers already know, since several years my home servers are running on embedded devices (Linksys Nslu2), and I am a frequent visitor of the www.nslu2-linux.org for firmware updates or to access its wiki.
It’s always frustrating when you just upgraded a device with the latest firmware and noticed that the eeprom has got a bad configuration that needs a factory reset, that you have to telnet into redboot and that you forgot the exact procedure.
It is even more frustrating when you notice that the wiki isn’t reachable from time to time… but only if the connection originates from Switzerland…

When after several tries, since the result looks the same, wou may want to ping the server to see if it’s still alive…

It seems to. Okay ! Now, let’s go further : a traceroute (mtr) gives this…

Have you noticed the rise of response time between the two ip-plus.net routers ? It’s possibly the time the packets take to cross the atlantic and go to New York. I have other screenshots of those measurements, and each time the delay increases from around 20 to 90 ms. Okay, let’s just say it is caused by the transatlantic delay (but I fear there is another reason for this delay, see below).
The same test is also done on Windows, we get this :

Now, what I hope not to understand well is the following :

Note :
1. when setting the proxy to a public proxy located let’s say for instance in UK or even in South Korea, the http://nslu2-linux.org site, I am able to browse on the pages.
When I set no proxy (direct connection through the swiss provider Swisscom / Bluewin networks), the page is unreachable and the port 80 is filtered… but not the other ports such as port 22 !
ip-plus.net seems to be the Swisscom subsidiary that is in charge of their backbones.
As I am writing this post, the wiki is available again, but this behavior happened me at least 20 times during nearly the last 2 weeks.
Does that mean there is a more-or-less (I would say less !) transparent filtering on our DSL lines ???? That raises a bunch of issues if it is the case…
Any comments ?
Bruno Kerouanton on septembre 4th 2007 in IT Security