The type of work the offshore group is contracted to do will influence how you extend your network. If the offshore group only needs to check code in and out, a full VPN would be overkill. Most major code repositories have built-in Web interfaces and username/password protection. Your network only needs to be extended to allow the front-end Web piece to access the back-end code repository. Using the popular Concurrent Versions System (CVS) as an example, there are several free, commercial-grade Web front-ends available. By setting up a publicly available Web site, using Secure Sockets Layer and relying on the built-in username/password protection in CVS, all that is required is a public IP address and fully qualified domain name. This is a simple solution that will let you sleep at night and play an uninterrupted round of golf on the weekend.
It also applies to offshore work that doesn’t require live access to your internal systems. Building on the above concepts will work for any access requirements that don’t involve live, real-time access to systems. If the business requirements are more involved than simple code check-in and check-out, then put the clubs aside.
What are the services the offshore workforce will need to consume that are hosted on your local network, such as Web services, database services or Network File System services? It might seem like more work than necessary to grant access to these systems at such a granular level. But by only exposing the application ports and hosts that are required for the specific job, you prevent any other traffic coming from the offshore network into yours, regardless if the traffic is hostile or not. Depending on the size of the offshore workforce, there are two common methods normally used to accomplish this — implementing a LAN-to-LAN VPN tunnel or client-based VPN access. A LAN-to-LAN VPN tunnel is a secure connection between two otherwise separate networks. A VPN endpoint can be a router, firewall, Windows server, Linux system or a dedicated VPN concentrator — anything that can encrypt and decrypt packets at an acceptable speed.
At this point, you have selected an offshore business partner, gathered a list of resources and purchased a VPN endpoint device. Name resolution, routing, latency and IP address conflicts all have the potential to keep you off the golf course. For an offshore workforce that has its own internal DNS servers, name resolution for the resources/hosts that I identified earlier can be an issue. A DNS zone transfer can be done between your DNS servers and the local DNS servers inside of the offshore group’s network, or you can create alias records on your public-facing DNS for these hosts. This filters traffic after it comes out of the VPN tunnel and before it reaches any part of your local network. You need to inject this network into your routing process or use static routes on the systems that the offshore group will access.
All the traffic that will come through the VPN will traverse the firewall. There are devices that will perform the VPN piece, NAT translation and stateful inspection all in one, but I have found these devices very hard to troubleshoot when using all of the above functions and not very good at controlling access to perform different functions.
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9000983&source=rss_topic17