Also sprach Dave Lajoie
I have had a problem 'like' this, may or may not be the same issue but solution for me was to change MTU setting from 512 to 1514 and it cleared up the issue. This was some time ago and am not quite sure how to address setting changes for MTU setting in cistron but you could check to see what it is assigning for MTU size. Its a long shot and just off the top of my head, hope it helps.
Indeed...reading through the description, I was thinking the same thing...that it was an MTU issue. Indeed, I seem to remember that in a previous discussion that turned out to be an MTU issue, www.harvard.edu was even mentioned as a troublesome site! Anyway...for some more information on the subject...this is rather detailed and I suspect that many of you understand all of this...but for any that don't...this should explain how MTU settings on a dial-up link can become a hard problem to track down like this. MTU setting with RADIUS authentication is a bit on the odd side. That's because MTU (actually, in PPP MRU is negotiated, not MTU) is negotiated during LCP, which runs *before* any authentication protocols happen. So the deal is that the customer connects, MTU is negotiated to 1500 most likely (or possibly 1514, 1524, something like that, but at least 1500) during LCP, then you get the authentication information (from PAP or CHAP or whatever), send off a RADIUS authentication request, get the reply which tells the Arc to set the MTU (note...not MRU) to a smaller value (576 is a common one). OK...here's where it gets tricky. The MRU negotiated in PPP from the customer is likely 1500 or higher...meaning that the customer's computer is saying, "don't send me any packets larger than 1500 bytes" (or whatever value is negotiated). When the RADIUS authentication response comes back, it's telling the Arc "don't send any packets over this link larger than 576 bytes" (or, again, whatever the value is set to). So...the Arc can comply with the RADIUS response value without violating the value negotiated in LCP, so there is no reason to go back and re-open LCP to renegotiate a new value. So now we have the Arc set to not send any packets larger than 576 bytes, and the customer's computer set to not receive anything larger than 1500 bytes, which won't be a problem 'cause the Arc won't ever send it anything larger than 576 bytes. The trick is, the customer doesn't know about the 576 byte limit that the Arc has in place (and in theory, it shouldn't *need* to know). So, what does all of this mean? Well, when the customer tries to connect to www.harvard.edu, the TCP SYN packet that the customer's computer sends out likely has the Maximum Segment Size option set (or it may not, the result will be the same) to 1500 bytes ('cause the customer's computer thinks it can receive packets up to 1500 bytes 'cause that's the MRU value negotiated in PPP). So the Harvard web server either immediately sends packets up to 1500 bytes in size, or very quickly ramps the packet size up to 1500 bytes, but certainly larger than 576 bytes. The Harvard web server also almost assuredly sets the "Don't Fragment" bit in the IP header of the packets its sending out. So these packets that are larger than 576 bytes, but not larger than 1500 bytes traverse the Internet, get to your Arc, and the Arc says, "I can't send this packet across this link because I have the MTU set to 576". So the Arc drops the packet on the floor, and generates an ICMP Destination Unreachable - Fragmentation needed but DF (Don't Fragment) bit set message and sends it back to the IP address for Harvard's web server. This ICMP message would tell Harvard's web server that there is a link somewhere along the path of the packet that it sent out that can't handle packets larger than 576 bytes...ideally, Harvard's web server would get this packet back and resend the data, but break it up into smaller chunks that will fit into 576 byte packets. The problem is that Harvard is either blocking these ICMP packets at some sort of packet filter or firewall in front of their web server, or, more likely (since you're not having problems with other web servers within Harvard's network) www.harvard.edu is some sort of load-balanced cluster of web servers that cannot handle ICMP messages like this correctly. Regardless of the cause, the ICMP message that your Arc is sending out is never getting back to the Harvard web server, so it never learns that it needs to send smaller packets, so it keeps on sending the larger ones, which your Arc keeps dropping on the floor, so no data gets through at all. Solution...remove the MTU settings from the RADIUS server's user config, or set it to a value of 1500 or higher (1500 is the MTU value of ethernet, so setting it higher doesn't really get you anything). Another possibility is to let Harvard know that they either have a firewall or a load-balancer on their web servers that are breaking Path MTU Discovery and that they should fix it. The problem with the second solution is that Harvard may not be willing to fix it, and you almost assuredly will run into this problem with other sites on the 'net and its probably just easier to set your MTU's higher than trying to fight a crusade like this on the 'net. :)
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've pulled this part of your message out to point out why all of these things worked when the RADIUS authenticated user on the Arc didn't. Workstations on the ethernet obviously have not link with an MTU of 576 between them and the Harvard web server. Old PortMaster ComOS code (as well as the 3Com NETServer code that was derived from it) didn't pay any attention to the MTU values returned in a RADIUS authentication response as they had already negotiated MRU during LCP and didn't have any support for changing it in the middle of a session. A user created in the Arc's local user table most likely didn't have the MTU setting that the user record in your RADIUS server had, so the MTU remained set to 1500 and traffic flowed normally. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456