I am moving our servers to a diffrent locatins and have a few questions about our vpn setup.

Hello all,

This weekend I will be moving our terminal server to a new location.  Our current network is arranged as such:  Home office is site 1 which houses our TS and Exchange server.  Our remote sites are 2,3,4, and 5 and I have a L2L vpn established between the remote sites and site 1.  Right now, traffic never needs to flow between the remote sites themselves, so the vpn is only established between 1 and the remote sites.  When I move the TS I was going to make a vpn to this new site which is 6.  What I want to avoid is remote site's traffic going to vpn site 1 and then to vpn site 6.  The reason for the server move is because the new site has Fiber Optic and site 1 is stuck on cable and is suffering.

Question:  Should I just add a l2l vpn to site 6 and then change everybody's RD to point to site 6?  I was afraid the traffic would still flow through site 1 then go to site 6 which wouldn't help with our bandwidth issue.  This was my original plan but then I started thinking about the way the traffic would flow.

Right now, the remote sites don't even know the other remote sites exist.  I can't remember what this is called but I know I can make them talk to each other without going through site 1.  This seems like th eway to go, but just want confirmation.

Any help anyone could provide would be much appreciated.  BTW, all sites are using Cisco ASA's.  I made that jump last year.

Who is Participating?
lavinpj1Connect With a Mentor Commented:
Sorry, I misunderstood your needs. If each site needs to be able to access sites 1 and 6, just create a tunnel at each site to sites 1 and 6. Assuming they use different subnets, the traffic will be routed over the right VPN.

As far as I am aware, you will need to create 5 tunnels at each site connecting to each of the other sites. Assuming each site has a different subnet and the Cisco ASAs are the default gateway for devices in each subnet, packets will be routed over the relevant site->site VPN.

VNEAuthor Commented:
Hmm.  I see what you are saying.  How about this......I create a tunnel for each remote site on site 6's asa and on the remote site's asa.  Then, when a remote site wants to access the terminal server then the traffic will simply be routed to site 6.  If they want to access the exchange server on site 1 then the traffic flows as it always has.  There is no reason for the current remote sites to be able to talk to each other.  They just need to talk to site 1 and 6 where the Exchange server TS are repectivily.  Sound right?
I think that is what you are saying except for the 5 tunnels on each asa since they don't need to access each other.
Get Certified for a Job in Cybersecurity

Want an exciting career in an emerging field? Earn your MS in Cybersecurity and get certified in ethical hacking or computer forensic investigation. WGU’s MSCSIA degree program was designed to meet the most recent U.S. Department of Homeland Security (DHS) and NSA guidelines.  

VNEAuthor Commented:
Sorry about the confusion as I 'm tyring to run through this in my head.  Yes, you are right and that's the way I will do it.  I've already got everything subnetted out, so it should be a snap. Thanks for leading me in the right direction.


Can you clarify your situation?  Since your remote sites can't see each other, we know that each one is on its own subnet.  It sounds like site1 is currently providing all the services that were being used by the remote sites.  If so your VPN tunnels need to follow the services as Phil(lavinpj1) suggests.  
I think you can do most of it with some simple editing on the ASA's if you swap ASA's at sites 1&6 and flip the LAN IP addressing schemes.  This method should work for ASA/PIX and generic VPN routers and is a general guide on how to do this without trashing your internal Windows networking setup.
In general you have a substantial investment in addressing infrastructure and you want to do this in a way that will create the least amount of work and least amount of potential for mistakes as possible by making it as close to throwing a switch as you can:
1) All your services are setup for all the sites relative to site1's existing LAN IP addressing scheme.  Sooo, you want to take the servers AND the addressing from site1 and move all of it to site6.  Easiest thing is take the ASA from site1 and swap it with site6's AND MAKE SOME EDITS.  That way you will not run afoul of any software or version differences which tend to creep up in multiple ASA's/VPN Routers.
2) This will let you limit what you have to do at sites 2-5 to simply editing the IP address in the VPN tunnel definition in the ASA and hit save.  That's it for those sites they will never know that anything changed except  it's faster.
3) At site6 you need to tell the site1 ASA how to navigate to the WAN IP address/subnet and whatever of the local ISP services you use like DNS.  You need to need to point your public DNS to the new public IP(s) of the new location.  I am assuming you have the ASA between the gateway router and the LAN so it essentially is already configred with correct LAN IP setup.  At this point your major services are ready to fire up and sync to sites 2-5.  As far as 2-5 are concerned nothing changed.
4a) Site6 lost their LAN addressing scheme so you need to fix IP addressing for workstations, printers, copiers and network devices to sync up.
4b) Site1 also lost their IP addressing and is now a branch site relative to the servers.  you need to define a new VPN tunnel for it at site6 and install the old site6 ASA at site1 (sorry if this is starting to sound like Abbot and Costello Who's On First...).  then you need to update the workstations and network devices accordingly.
The VPNs are now all pointing to site6 as painlessly as possible and because you didn't change the addressing local to your servers, there is no reconfiguration of the windows networking and services internally to worry about.  Public services have been pointed to the different public IP(s).  Best of all when you are dog tired come Monday, you don't have to spend the whole day having to help with broken Outlook and RDP client pointers because they didn't change.  If you are running backup your setups should also be intact.
Hope this helps you plan,
VNEAuthor Commented:
Thanks Mark for your time,

The only fly in the ointment is that we will be leaving our exchange server at site 1 for the time being.  I thought of swapping site 1's asa with site 6 but site 1 has a bunch of users and alot of printers with static ip's and I hate to change their subnet just to save having to change the other site's RD addresses.  Know what I mean Abbot?  The remote locations only have maybe 2 or 3 pc's per locations so changing the remote desktop address is quick and adding a tunnel is no big deal.  Here's what I decided to do, let me know if this sounds nuts:

1.  Add vpn tunnels for all locations to asa at site 6.
2. Leave site 1 alone except for add vpn tunnel to site 6 and change RD addresses, takes about an hour.
3.  Add tunnel to remote sites 2-5 to point to site 6 and change maybe 3 RD addresses apiece.  Can be done remotely without having to travel.

Changing the IP addresses for each device at site 1 makes me naucious.  Thats where all the bosses work and if they can't click a button and print then the whole world goes to hell.  Mass hysteria, confusion, screaming, yelling, sweating, and general hatred directed at that IT guy just because they can't print their emails that their cousin sent them that has a warning about that worm that was supposed to start on April 1st or whatever.  You know, that worm/virus that nobody actually got.

Do you really think I may have software version issues among the asa's?  They are all less than 12 months old.  That could be a nightmare.

Thank you so much for your input.

On small routers, security devices or pretty much any little stand alone network device, you never really know what you have unless you check it.  For distributors to get good pricing and early delivery they have to commit to large volumes of items.  In some cases they may sit on inventory if they misjudge the consumer response.  As a reseller I have ordered stuff like Linksys or Netgear and receive versions that are sometimes 8 mos or more out of date.
Good practice on install is to update the firmware on anything like that to the most current version before you even start to configure.  I would expect the ASA's and PIX to update at least twice a year.  If you bought all your ASA's in one batch they are probably OK.  The only thing that might cause you to worry would be if you were planning a Saturday move and expected to transfer configs by export/import.
Two comments on the outline I gave you.  I like to do fixed IP addressing for critical stuff and DHCP for workstations and such.  If you use AD/DNS/WINS internally and do all your addressing via names, you can jump your subnet addressing all over the place with reckless abandon and everything will still be able to find itself.  This strategy flys in the face of the old WIN95/NT4 days where poor software integration forced admins to map drives to letters.
I still walk into a lot of small businesses and schools with workstations with G:, H:, S: & Z: drives.  I hate it because in a lot of instances a server going down or getting slow can more or less hamstring all the workstations as mapped drives are very 'chatty' over the old LANMAN.  I find all kinds of screwy stuff like pagefiles on a mapped share.
I digress.  If you are going to have dual tunnels from all the remotes to sites 1&6 watch out for the ARP tables and route statements. and beware of RIP protocol settings lest your NETBIOS starts looping around.
Also, it isn't an issue now but if/when you go to VOIP and have IP phones you may need to bounce 2-5 through site6 with a route statement to tell them how to get to the exchange server on site1 or switch to http/SSL access on the Exchange Server and drop the 2-5 tunnels to 6 altogether.
Good luck with your move!
VNEAuthor Commented:
Thanks for the help.  All of that is good info.  I'm sure you will see me posting questions in the future.  Thanks for your time.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.