Saturday, August 23, 2008

Under the hood VPN looksy in SBS 2003

Happy HOT summer Saturday to you - at least if you are reading in North America!

I am the author fo Windows Small Business Server 2003 best Practices (SBS 2003) and I am posting up a few pages per day unitl SBS 2008 ships!

Today the topic is a under-the-hood lookat SBS 2003's VPN/ architecture. Enjoy!

cheers....harrybbbb

Harry Brelsford

CEO at smb nation, www.smbnation.com Microsoft Small Business Specialist (SBSC), MBA and other goodness like CNE, MCSE, MCT, CLSE, CNP

PS did u know I host a major rager SBS conference in early october in Seattle?

###

Under the Hood: VPN


So what’s the technical view of the VPN connection just made? Figure 8-32 shows the port-activity related to the VPN connection.


Figure 8-32


Observe that Port 1723 is being used for the VPN connection between a remote computer and SBS 2003.





Visit www.microsoft.com/technet for the latest updates for any Microsoft product.


BEST PRACTICE: Regarding the day-to-day use of VPN connectivity in SBS 2003, I suggest you view this as a dial-on-demand approach. Whenever I’ve seen SBS sites that view the VPN area as full-time, 7/ 24 connectivity between branch offices, I’ve actively discouraged such thinking, because SBS isn’t positioned as a branch office solution. But it’s fine if a traveling Norm Hasborn needs to VPN into the SPRINGERS network to do some voodoo.


VPN and NAT-T


Finally, it’s beyond the scope of this text and it’s something I’ll pursue in the advanced SBS book later (with step-by-step procedures), but be advised there is an issue with respect to having VPN connections when you place a hardware-based firewall router out in front of SBS 2003 and want to tunnel into the SBS network (especially if you’re adhering to the best practice of a dual firewall). This area is NAT-T over IPSec across the firewall. Technically speaking, IPSec NAT Traversal (NAT-T) allows IPSec clients and server to work when behind a NAT. To use NAT-T, both the remote access VPN client and the remote access server must be IPSec NAT-T-capable. IPSec NAT-T provides UDP encapsulation of IPSec packets to enable Internet Key Exchange (IKE) and Encapsulating Security Payload (ESP)-protected traffic to pass through a NAT. IKE automatically detects that a NAT is present and uses User Datagram Protocol-Encapsulating Security Payload (UDP-ESP) encapsulation to enable ESP-protected IPSec traffic to pass through the NAT.


IPSec NAT-T is supported by the Windows Server 2003 family. As such, it’s supported in SBS 2003. Your next step might be to delve deeper into the issue with the Microsoft Press Windows Server 2003 Resource Kit or look up some articles on TechNet.

2 comments:

alex smith said...

I recently had a situation where roadwarriors needed to communicate with routers and systems beyond our administrative scope. I used the information listed here... but under your vpn policy goto advanced and you can use source NAT (SNAT) to make the connections appear to come from the local interface of the NetScreen. I would not advise this for more than a few users doing light tcp/udp work. My situation was this: 5 remote users need telnet access to an internal rehat server (large car dealership). The other locations have networks that were large enough for us to have coporate add routes back.

Anonymous said...

This link provides information on how to reach state insurance regulators that can help to provide state-specific information relating to car, homeowner, ... http://insuranceinstates.com/tennessee/Memphis/Heaton%20&%20Moore/38103/