A site to site ipsec vpn (also known as a lan to lan or lan2lan vpn) connects to different networks with what appears to be a wan or wide area network link in between the sites. Richweb uses linux based sgw firewalls or Cisco Pixes to implement the lan to lan vpn tunnel.
Requirements for considering an ipsec vpn between 2 sites
1. You need to have at least 512Kbits/sec of internet bandwidth at each site
2. You need a cisco pix or linux sgw firewall appliance at each site
3. You need at least one publically routable, static ip address at the HQ or main site. This IP address should NOT be behind a NAT appliance. It should be exposed directly to the internet and unfiltered by any upstream firewalls.
Note: VPNs work best if you have a static IP at each end. It is not possible to effectively manage remotely a vpn where both ends of the tunnel have a dynamic (changing) ip address. A user will have to be onsite to generate outbound traffic and report the ip address currently in use to the firewall admin at each site.
Problems:
1. NAT - if one or both ends of the vpn are behind a NAT box (such as a router or dsl modem) it might be possible to make an ipsec vpn work using NAT traversal. Richweb needs port 22/tcp (ssh) and ipsec (protocol 50) and isakmp (udp 500) open inbound to the private ip address of the sgw firewall box. If more than one ipsec session is in use behind the nat box (common in shared tenant office buildings using NAT) it is likely that the site to site vpn will not work consistently. Again we suggest pushing a public, non-natted ip through the router or upstream firewall to the sgw box or pix that is implementing the vpn tunnel.
2. Lack of bandwidth - 512Kbits/sec is the MINIMUM amount of AVAILABLE bandwidth needed for a basic site to site vpn. If you have a 512K connection that is often totally consumed by internet traffic (web browsing) then of course implementing a vpn on top of this connection will be troublesome at best, and likely not work at all.
3. Types of communications needed across the vpn may not be supported due to bandwidth or latency - a more complex issue to consider. Microsoft file sharing traffic can be very difficult to implement over a VPN connection just as it can be difficult over a standard private WAN such as a point to point t1. Microsoft desktop operating systems and standard servers are tuned for LAN (high available bandwidth, low latency) environments. VPNs tend to have the opposite operating environment (low bandwidth, high latency). Richweb suggests that if you need to mount drives (file sharing) across a vpn that you have at least:
3a. 1.5 Mbits/sec bandwidth available at all times (i.e. dedicated for the vpn and NOT shared by internet traffic such as email or web browsing)
3b. 60 ms or less ping times between the vpn connected lans
3c. less than 1% packet loss on 1000 1400 byte pings between two servers across the vpn connection
If your vpn internet connections and networks do NOT meet these criteria then you will likely not be able to use Microsoft file sharing across your vpn.
You will be able to run other applications such as email (Outlook/Exchange/OWA), Citrix, MS Terminal Services, AS400, UNIX/Linux/Microsoft/AS400/IBM TCP/IP based client server apps and possibly other custom applications.
4. DNS resolution; DHCP configuraton
When connecting two networks LAN to LAN, each network needs to use a unique local ipv4 address space. If both of your lans use 192.168.1.x and you wish to connect them, you will need to re-address one of your lans to 192.168.2.x for example.
You will need a DHCP server to hand out ip addresses at each location. Do NOT attempt to forward DHCP requests across a vpn. The Cisco PIX or Linux SGW box will be the DHCP if you do not have a MS Windows server at one or both locations.
DNS is a very important consideration for VPN networks. You CANNOT point your PCs behind each lan to public ISP provided DNS servers if you expect Active Directory connections to work. In fact you will waste your own bandwidth with excessive bogus DNS queries that may cause you to get into trouble with your provider.
Assuming you have a domain controller (server) at each site (the best design) the domain controllers at each site will be the primary dns server, with the opposite domain controller across the vpn connection being the secondary dns server.
If you have 1 HQ site with a domain controller (site A) and 1 site without a domain controller (site B) you should have the DHCP server at site B pass out the domain controller at site A as the DNS server to its DHCP clients.
5. Voice over IP across a VPN (VOIP)
VOIP presents many challenges to a vpn; quality of the voice calls may range from toll quality to less than that of a cell phone depending on bandwidth, latency, carriers and configuration.
Richweb has experience implementing voip across vpns with pretty good success. Here are some considerations to work around the challenges:
5a. VOIP packets are small and cannot be delayed by large data packets. This means that you MUST have at least a 768 Kbits/sec bi-directional internet connection to run data AND voice. At speeds less that 768K the router cannot clock out the data packet that has been dequeued in front of a waiting voip packet fast enough. In other words if you have a 512K dsl line and you run VOIP AND data across it at the same time, there is no configuration that can prevent clipping of voice when data is sent at the same time.
5b. VOIP sessions CANNOT work with latcency higher than 150 ms. If you run a constant ping (1000 packets) between 2 machines on either side of your vpn and you get response times above 150ms it is likely that your voice calls will experience lag (like an overseas call) and clipping. If your internet connections are from the same provider et each location you have a better chance of your voip working across your vpn as the packets will be going across the carrier backbone rather than across the internet at large. If your packets traverse more than 12 to 15 hops in a traceroute (use the public not private firewall ips to trace) then you may have some problems with your quality.
5c. If you have an internet router (Cisco 1841 dual ethernet is an excellent model) that can do traffic shaping and basic packet prioritzation Richweb can configure your internet connections such that the routers will prefer voip packets first, and limit www and other bursty data traffic such that voip will not be choked out. This generally results in pretty good voip quality.
Remember, routers can only shape traffic they send. traffic that is received can be shapped when forwarded downstream but the input traffic itself cannot be shaped. This means that if you have a heavy in flow of non-voip traffic to a router it can choke the voip traffic even if shaping is in place. TCP driven traffic will adjust itself to shaping better than IPSEC, and UDP based traffic for example. For example, if you have data AND voice flowing across multiple ipsec sessions into a router it can be difficult to protect the voice traffic inside 1 ipsec tunnel from data traffic inside another tunnel.
If you have the ability to add multiple circuits to the HQ location this can often make it easier to properly manage VPN traffic and handle VOIP over VPNs. For example if you have a dsl or broadband line for incoming mail and outbound web browsing traffic and another dsl or broadband line for VPN traffic this makes the protection of traffic easier to engineer.
In order for Active Directory to work and your sites to see each other you need to have your DNS servers at each location aware of the other locations. You CANNOT use your ISP or provider DNS servers.
That usually means the same HH site DNS server records should be configured in the DHCP scopes on each of the subnets.
This becomes tricky when you are not able to access the vpn during an internet outage as you will lose all internet access unless you have secondary and tertiary DNS that is pointed at a local DNS server.
This the best option is to have an A/D server at each location and use active directory sites and services to manage this for you. Setup your local A/D server as DNS server #1 and setup the server at the HQ location as DNS server #2.
With this DNS setup you have redundancy AND you offload your
authentication traffic to the local servers.
If this dual dns server approach is not feasible then
assigning your HQ site DNS as primary and secondary will have to suffice.
Be advised that while WINS (Windows Internet Name Service resolution) can be made to work across a VPN using H or P node NBT resolver types in DHCP options config this is not a suggested approach. Use AD and MS DNS.
Also your remote sites will need to use FQDN to access remote network
resource.