Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

At work (UK university) we use a set of Windows servers running WS2008R2 and RRAS which offer VPN service to students in our accommodation. We do this to associate the network connections with individuals. Before they've connected to the VPN all they can talk to is the stuff thats needed to setup the VPN and a local web site with documentation on how to connect. Medium term we'll probably replace this but it's what we're using at the moment. VPN on the 2008 servers allocates client a private (10.x) address. Access to external sites is through NAT on the campus routers (same as any other directly connected client on a private address). Non-VPN connections aren't seeing this problem.

Older servers run WS 2003 and ISA2004. That setup works but has become unreliable under load. Big difference there was that we were allocating non-RFC1918 addresses to the clients (so no NAT required). Behaviour we're seeing is that once connected to the VPN, clients can reach local web sites (that is sites on the campus network) but only some external sites. It seems (but this may be chance) that the sites we can reach are Google ones (including YouTube). We certainly have trouble reaching Microsoft's Office 365 service (which is a pain because that's where mail for most of our students is).

One odd bit of behaviour is that clients can fetch (using wget on a Windows 7 client) (which gets a 301 redirect) but hangs when asked to fetch (which is what the first URL redirects to). Access works reliably if we configure clients to use our local web proxies (Squid).

My gut tells me that this is likely to be something in the chain dropping replies either based on HTTP inspection or the IP address in the reply. However I'm puzzled about why we're seeing this with the VPN clients.

Plan for tomorrow (when I'm back in the office) is to setup a web server on external connection so that we can monitor behaviour at both ends of the conversation (hoping that the problem manifests itself with our test server). Any suggestions for things we should be looking at?

share|improve this question
We're now (almost) sure that this is provoked by WS2008 setting the "don't fragment" bit on packets and a misconfiguration of the campus firewall blocking ICMP packets. WS2003 doesn't set the "don't fragment" bit and doesn't show this problem. Theory is that small packets got under the fragmentation threshold and so worked, larger ones needed to be split and so didn't get through. – Paul Haldane Oct 31 '12 at 16:01
up vote 0 down vote accepted

We've decided that there's almost certainly a misconfiguration in our border firewall rules about handling of ICMP which is stopping fragmentation working properly. Given that we're reviewing how we provide the network service which relies on these VPN servers, we've decided to stick with WS2003 and ignore the issues with WS2008. If it looks like we're stuck with running this VPN for much longer we'll look at the firewall config again.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.