Having spent a happy 3 weeks trying to get a fairly simple inter-site network up and running I thought that I should share the various problems - and solutions - to minimise hair loss if anyone else wants to do the same.

This is the network diagram:-
Branch Office Network 192.168.254.0
VPN provides link between Branch Office (192.168.254.254) and Main Office (192.168.255.0)
Branch Office machines use 192.168.254.254 as default gateway AND preferred DNS Server with the Main Office Server being secondary DNS Server
Note - many experts suggested Main Office Server (SBS 2003) should be preferred DNS server for Branch Office with 192.168.252.254 being secondary but the only thing this seems to do is to slow down access to the Internet because DNS requests go to Head Office for resolution rather than to the local router - OK the delay is only around 500mSec but it annoys me! I have tried both ways and, seeing that the 'recommended setting' did not solve any of the problems I was having I can't see any point in doing it - I would suggest DNS1 is set to the one you are most likely to use more frequently and, in our case, that is the one closest to the Internet. It is possible that something will expire over the next few weeks and the DNS1 timeout of 2 seconds before trying DNS2 will prevent a refresh and prove that the experts were right.

We also have Remote Desktop Connection available from the Branch Office to the Main Office - we can use either TCP port 3389 to main.office.com via Port Mapping on the main office AR240e to a single machine (in our case an Application Server where we can run MS Access applications (impossible to achieve remotely otherwise) bypassing the VPN or to any of our office machines over the VPN.

There is quite a hot-potch of equipment installed on our networks - mainly because the technology is now too complex for any hardware supplier to provide a complete working solution in one box and the various user interfaces either omit some important settings or the documentation is so ambiguous or misleading that configuration can be a nightmare.

Allied Telesyn AR240e

I wanted complete visibility of Internet security settings and the Allied Telesyn AR240e has been a favourite of mine for around 3 years now. None of this 'Plug and Play' nonsense with no idea of what settings and security leaks this may involve - you tell it what ports and/or protocols you want to allow in either direction and, for incoming packets, where each one should be forwarded to (Port Forwarding). It also has a built in ADSL modem.

Allied Telesyn have not been without fault on this model though. A couple of years back we discovered that the AR240e (and AR250e) were susceptible to failure to re-establish the ISP connection if it was lost in certain circumstances. The AR240e would 'hang' in the Authorise phase of the negotiations. The problems appeared to be associated with a telco reset of the exchange switch and, on newly enabled exchanges, the problem would happen a couple of times a day gradually tailing off to once a week - presumably as the switch was populated for additional subscribers.

You MUST have the v1.2.2 firmware - note that this is one the Allied Telesyn website but it is not listed under firmware - it is refered to as "Application Loader v1.2.2".

Dynamic DNS

As out ISP's charge quite a lot extra for a fixed IP address we have been using NO-IP to keep our addresses accessible. Nice and simple and the Groups feature makes life even easier. Keep up the good work guys.
For the purposes of this document I have called them main.office.com and branch.office.com

Linksys BEFSX41

Now I wanted a VPN between the 2 networks to make life a bit less complex. I chose the BEFSX41 on the basis of perceived quality and, I suppose my only complaint now it is working is that documentation and help files are pathetic! You know what you want to do and assume that this is also what everyone else wants to do (because its the way to do it!!) but can you find out how - no way!! In fact the documentation even gives the impression that it won't work because it skips over the more important issues. First step is to check the firmware - mine is 1.50.18

To configure the VPN you need to set various bits and pieces and our settings are:-

Still - having run into various performance issues and user authentication in our Domain - I set the MTU on the BEFSX41 to be 1400 (OK maybe I could have added a few more bytes but by this time I was fed up trying different things). See next section on Windows XP issues.

Having established out connections all went well for a week and then, following an obvious ISP problem where we couldn't access their DNS server, the link failed to come up again. As ISP's are pretty uncommunicative when they have problems this issue resolved itself quietly following several restarts of the AR240e's - and the subsequent allocation of different dynamic IP addresses. Noting that the allocated IP addresses which allowed the Tunnel to re-establish were obviously on a different router I fired off e-mails to the ISP tech support pointing out my feelings about the router configs and the ranges which appeared to be affected - lo and behold the problems went away (when these addresses were subsequently re-allocated to us) - but nothing was heard from the ISP to admit a problem or otherwise - nothing like working blind.

This was actually quite a time consuming diagnostic excercise because we were using 2 different ISP's and problems were seen at both ends of the link at first - but now all appears well. In hindsite it would have been an easy diagnostic task had I had a program which would attempt to open the various VPN ports in both directions and provided diagnostics - the BEFSX41 log files were not of much help although they did show RX and TX traffic patterns which indicated that sometimes Key exchange traffic was not being received although it was being sent and vice versa although a description somewhere of the VPN exchanges would have been even more helpful.

Windows XP

When using a VPN, because of the GRE packet overheads, the UDP packets can get fragmented and prevent the VPN working - a quick registry hack sorted this:-
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxPacketSize=1
(Thanks to http://www.eventid.net/display.asp?eventid=40960&eventno=787&source=LsaSrv&phase=1 and the author Vazy Gee)
Microsoft description is in Q244474 but I didn't find this until I knew what to look for.

Before finding this registry setting I had also set up LMHOSTS and swapped my DNS server settings around on the workstations - neither of these appeared to have any effect although many experts suggested these as sorting out the problem.

LMHOSTS (Note the abcdefghijklmno represents Domain name padded with blanks to 15 characters within the quotes)
192.168.255.1 sun #PRE #DOM:abcdefghijklmno
192.168.255.1 "abcdefghijklmno\0x1b" #PRE

My DNS Server settings on the branch office workstations are: DNS1= 192.168.255.1 and DNS2=192.168.252.254
and the routing on these is 192.168.255.0 going via persistent route through 192.168.254.252 with default gateway of 192.168.254.254
This does have the overhead of branch office DNS requests being sent over the VPN for resolution which, when the head office server is automatically turned off between 00:30 and 09:00 as part of our energy management program, gives a 2 second timeout at the branch office for DNS resolution although in practise this isn't much of a problem.

One thing to also be aware of is that you don't want Internet traffic going over the VPN and then on to the Internet (I suppose you could argue that if you had a proxy server at the Head office this may be OK) because it will slow things down dramatically due to a bottleneck at the Head office router. In our case the only VPN based traffic when we are browsing the Internet from the Branch office is that used for the DNS resolutions which is necessary because we need the resolution for our own machine names provided by our DNS Server on the SBS Server.