[ previous ] [ next ] [ threads ]
 
 From:  David Cook <david dot cook at jpcompserv dot co dot uk>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: VPN for 2 offices connecting to same domain on a windows server
 Date:  Wed, 01 Feb 2006 18:40:23 +0000
Dee Lowndes wrote:
> Sorry I should have said that only one Windows 2003 SBS server would be
> in use and that would be located in the main office. Indeed to figure
> out a way for both offices to be able to use that one server.
> 
> Ideas on a postcard please ;)
> 
> Dee
> 
> On Wed, 2006-02-01 at 07:04 -0600, MN wrote:
> 
>>Your Windows 2003 servers will have DNS, you can use this for the domain
>>connectivity. Point your "fringe" office back at a DNS server at the "home"
>>office.  As for DHCP, it may be more trouble than it is worth to get that
>>across. 
>>

This should be possible. The key is using the hidden options in the 
config.xml file so that m0n0wall providing DHCP services on the remote 
network assigns the IP address of your SBS server as the primary DNS 
server for the remote clients. This will allow the remote clients to 
participate properly in Active Directory.

If this is properly setup in combination with the site-site VPN, then 
there should be no need for WINS. If WINS is required (some legacy 
software fusses without it) then the IP address of your SBS server can 
be again assigned to the remote clients by DHCP and standard m0n0wall 
DHCP configuration options. See 
http://doc.m0n0.ch/handbook/faq-hiddenopts.html and the DHCP section on 
http://doc.m0n0.ch/handbook/config-services.html for details.

A few observations.

1. You are going to need a small block of static IPs on each xDSL 
connection between the router and m0n0wall. The m0n0wall-m0n0wall VPN 
just won't work without the m0n0walls all having Internet IPs. A /30 is 
ideal though if you have to use BT (avoid if at all possible) the 
minumum they generally supply is a /29.

2. Assuming that you are using MS Windows on your client PCs, this is 
all going to work much better and be easier to configure and 
troubleshoot without fighting with MS Win9x or WinME clients. If you 
have any of these left and were thinking about replacing them, now is 
the time!

3. Your SBS server does not need to do DHCP for the remote networks. You 
will cause yourself more work if you try, though it is possible using 
DHCP relay in m0n0wall. The key is that all PCs on the network are using 
your SBS server for DNS.

4. Minimise the amount of traffic that is passed between the server and 
remote clients at login and logoff. If you are using Group Policy for 
folder redirection on your main site then create Organisational Units 
for each the remote site which has a policy with either the folder 
redirction disabled or pointing to a UNC path on the remote local 
network. The clients at the remote sites then need adding to the 
appropriate OU. This doesn't apply for MS Win9x clients.

5. MS Outlook as a client to MS Exchange does not play nicely across 
firewalls and VPNs. In our experience the packets generated by the RPC 
traffic between the client and server are just too big for anything 
other than a LAN. The solution is to use a combination of MS Outlook 
2003 (licensed with your SBS CALs), MS Windows XP Pro SP2 and configure 
Outlook RPC over HTTP (or better HTTPS).

This works really well and in addition to giving everybody the full 
functionality of MS Outlook and Exchange; avoids the hell of PSTs, 
POP3/IMAP connections to Exchange mailboxes and other nastiness. If you 
have Exchange SP2 installed then this is a matter of clicking a few 
options in Exchange Administrator, manually configuring two registry 
entries and changing a couple of options in IIS. I believe we have a 
hint-sheet for this somewhere; email me if you want it. Traffic across 
the WAN between Exchange and the Outlook clients can be minimised by 
using the default Cached Exchange Mode in Outlook.

Best regards

David