Sure would be nice if we could just cluebat all the people that run websites that have that problem. Point them all to a site like Hint to firewall administrators: DO NOT BLINDLY BLOCK ALL ICMP TRAFFIC. It's a dumb idea. Some ICMP is essential. This exact problem is why. See http://www.worldgate.com/~marcs/mtu/ for a good read on the subject. Mike Andrews * mandrews@dcr.net * mandrews@bit0.com * http://www.bit0.com VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet access for Frankfort, Lexington, Louisville and surrounding counties It's not news, it's Fark.com. "With sufficient thrust, pigs fly just fine" On Thu, 7 Mar 2002, Paul Farber wrote:
I ran into a similiar problem... I had just changed the RADIUS attribute Framed-MTU from 1500 to 576.
TC equipment would not get to several web sites (www.iwon.com, www.psecu.com, www.weather.com etc) but our patton gear worked fine (both use the same auth/acct server).
Since 2 /24's were assigned to the TC's and 1 /24 to the Pattons I figured that we may have been filtered for some reson. Called some admins at PSECU (I bank there) and they verified thier ACLs, not the problem.
RESET THE FRAMED-MTU TO 1500 AND THE TC'S WORKED TO ALL SITES AGAIN.
Not sure if it is a fragmentation bit bug, a RADIUS bug in the ARC code or a setting on the ARC that I needed to change... I just reset the MTU size in the USERS file and it all worked again.
-- Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545
On Thu, 7 Mar 2002 drernst@kirkwood.hoosier.net wrote:
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...
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc