Basically some dolt Admins think that blocking ALL ICMP packets is a good thing... when they really just want to block ICMP echo request/response. ICMP MTU discovery *should* and *does* work.. unless admins do the above (ie block all ICMP packets). I ran into this with a lot of smaller banks and thier online account stuff... they are so afraid (or stupid) that they block everything hoping that it will work/keep out the bad guys. Basically you need to keep your MTU at 1500+ or face the wrath of poorly designed firewalls. -- Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Thu, 26 Dec 2002, Travis M. Best wrote:
Joel,
I Have All Mine Set To 1500 Take A Look A The Bellow Info From An Older Post
Thanks, Travis
Ok, here's my candidate for weird problem of the year. I'll try to be brief, but please don't confuse that with a lack of having tried a billion things to figure out what's going on. :)
Our users are unable to connect to a VERY SMALL number of IP hosts when they connect to our HiperDSP/HiperARC Chassis. For instance, it seems that we cannot open www.harvard.edu in a web browser. Don't confuse this with an inability to open any web site, far over 99% seem to work just fine, including www.law.harvard.edu, www.hup.harvard.edu, www.med.harvard.edu... the list goes on and on (by the way, we have no special affiliation with harvard (like a peering arrangement), from our point of view they are just a random web server). In fact, I'm only sure of three Web servers on the whole internet that we have problems with (I'm sure there are more, but those are the only ones I know). Those three display the same symptoms every time: a web browser hangs on "host contacted, waiting for reply..." And never gets through.
Ok, to make sure you believe this is weird, we can access these sites no problem from workstations on the same ethernet as the TC Chassis. We can access the sites no problem from dialup connections to an old PortMaster with analog lines in the back (also on the same ethernet). And in fact I created a special user in the hiperarc, dialed up, logged in as that user, and had no problems. I thought it might be related to the IP address (like the web server being unable to reverse lookup the address), but no, I can connect using a specified IP address using an account set up in the hiperarc, and it works fine, but if I get the same IP address after RADIUS authentication, no dice.
SO, the obvious candidate for the problem is the RADIUS server, which is cistron, just upgraded because of a security problem (making it look even more suspicious). My problem is, I have no idea what kind of information the RADIUS server could be sending to the HiperArc to cause this problem. I mean, I couldn't cause this problem if I wanted to! I couldn't even cause anything similar to this problem! Furthmore, log information in the "detail" file looks essentially identical regardless of how the connection is authenticated... I've got those, as well as output from "monitor radius" and the like, if anyone really wants to dig deep. But naturally, what I'm really hoping for is just that someone will say "OH, it sounds like a such-and-such kind of problem, try that".
Thanks for even reading about my woes, and especially for any thoughts you may be able to share...