Websurfing trouble to .gov and .il.us


I am part of a small ISP based in Chicago. We have several clients complaining of an inability to hit a couple specific government websites, specifically http://tierii.iema.state.il.us/TIER2MANAGER/Account/Login.aspx and https://www.deadiversion.usdoj.gov/. It does seem to be related to the IP's they use, specifically parts of 213.159.132/22. They can surf any other site we can think of, do email, IPSec tunnels, anything apparently but surf these sites. The listed sites show "loading" then "connecting" then back to "loading" and so on. I have checked all the blacklist sites I can get out of google. and they all show all green. I am at a loss as to what else might be contributing to the issue. Is there anyone on list here from either of those sites who might be able to help who can hit me off list, or anyone at all who might have some advice? It would be appreciated. All I need to do is to assign different IP's to the client and it works fine (hopefully eliminating Layer 1 and Layer 2, i.e. routers, circuits, etc..) My apologies if this is not the correct forum for this kind of question.



Hi Sam,

Some basic troubleshooting:

1. traceroute? TCP traceroute?

2. From an affected address, do you get a TCP connect to the site or
not? e.g. "telnet tierii.iema.state.il.us 80"

Bill Herrin

Wireshark? It could be a problem with the sides having an infinite referral loop. It doesn't necessarily have to be a network problem per se.

This block appears to have shifted over from RIPE into ARIN space.

I've seen a few firewalls and filtering systems that block countries or block unallocated/weird/bogon ranges in broken ways (probably more so if it was an enterprise/government/finance situation). They could be locally terminating connections at the entry point or something in a browser, which might produce oddities like the loading/connecting/loading.

Alternatively, I've also seen some crappy fw/transparent proxies have problems dealing with IPs that end in .0 and .255 and sometimes .254.

First thing that comes to mind: Fire up wireshark and
see if anything pops out.

Second thing: PMTU black hole or similar - the 3 packet handshake
completes, and TLS fires up, and then comes to a screeching halt
when something large causes a MTU-sized packet to happen.

Double-check the pages, make sure they aren't doing something
squirrelly like fetching CSS from some *other* site that's down
or PMTU black holed.

Oh, and 519 lashes with a wet noodle for the IL state division of IT
for having a Login.aspx on an http: site. :wink: