VPN stands for Virtual Private Networking and is a way to establish a secure “private network” to a computer at another location through the public Internet. This is frequently used by businesses to allow employees to telecommute and establish a connection to their private company network. If you don’t need this ability, don’t worry about a lack of VPN capability in the router you’ll be buying.
If you do need this capability, check the router specs carefully to make sure your choice supports the protocol you need. Microsoft PPTP is frequently supported, some units support IPsec, and only a few support L2TP.
If you’re using Microsoft’s Internet Connection Sharing (ICS) to share your connection, forget about using IPsec based VPN, since it’s not supported.
PPTP specific help can be found on this page.
What flavor VPN do you need?
If you are connecting to a remote VPN server from a computer on the LAN side of your router, you need VPN “client pass-thru” capability. When you run in “pass-thru” mode, you usually need to run some sort of client software on your machine. Let’s look at the two most popular VPN protocols:
- PPTP (Point to Point Tunnelling Protocol)
Microsoft’s VPN solution. Widely used (because the client comes bundled with Win95/98), but considered to not be as robust as IPsec.
- IPsec (Internet Protocol security)
Backed by Cisco, IPsec is considered by many to be more secure than PPTP, due to its higher level of encryption.
To use either of these protocols from computers on your LAN to connect to a VPN server via the Internet, your router needs to support “client pass-thru” for the protocol you need. Some routers support only one “pass-thru” client, others support many. In either case, you’ll need to run some sort of VPN software on your client machine(s).
NOTE: Many inexpensive routers have a VPN “feature” that allows multiple client pass-thru sessions, but only one VPN session per VPN tunnel “terminator”. This means that you can’t connect multiple VPN clients simultaneously to the same VPN server, but can connect only one client per VPN server.
If you need to support multiple VPN clients to the same server, be sure that your router supports the ability to do this. Due to the range of VPN configurations and the difficulty in getting correct information from many router vendors, your safest bet is to spend some extra money and get a router that has a built-in VPN end point (see below).
Some routers come with the VPN Client built into the router or available for additional $ (usually $$$!). Sometimes called “VPN End point, or “VPN Edge”, this capability is more common with IPSec VPN and terminates the VPN “tunnel” in the router. This allows computers on the router’s LAN side to not have to run VPN client software, and effectively makes the entire LAN side of the router an extension of the VPN server’s LAN.
If, however, you’ll be hosting a VPN server behind the router, i.e. users will be connecting to you, make sure the router supports VPN “server pass-thru” in the protocol that you need. “Server pass-thru” usually supports only one VPN server.
Unless otherwise specified, assume that the router itself is not a VPN server or “endpoint”.
[Help for setting up a PPTP connection through a router is available here.]
More ISPs are setting access control lists on their routers to filter (i.e. discard) IPSec traffic. Some ISPs are charging more for business services than consumer services (@Home Comcast, for example) and they do not want people buying consumer services and using them for business.
If you can’t get your VPN connection to work, ask your service provider if they are filtering IPSec traffic. If they are, complain to them, change ISP’s if possible, or complain to your state Attorney General or Consumer Affairs office!
We recently heard from a user who was having trouble getting their IPsec client to work with a router that supported IPsec passthrough. The problem turned out to be that the VPN in question was using Header Authentication. I’ll let Mike Shields of Netgear explain:
The problem is Header Authentication, and no NAT will work with it. When a company sets up a VPN system with IPSec, they can choose to have the packet header information included in the authentication scheme, or to just have the body of the message contain the authentication. If they choose to include the header, then absolutely nothing in the header can be changed, or the far side will consider the packet to be tampered and will reject it.
When a router performs NAT, it replaces the source address in the packet header with its own address, so it would fail Header Authentication. Luckily, most companies do not use Header Authentication, relying on authentication within the packet. This may leave the packets vulnerable to hijacking, but I think it causes fewer problems in getting the VPN running reliably.
A user in this situation may be able to use a router (more $$$) that does IPsec end-point, not just passthrough. In this case, the router runs the IPSec client, not the PC, so all encoding and encryption is done after NAT. The hitch is that the router’s IPSec client must be compatible with the IPSec server at the far end, and not all IPSec implementations are alike. Who is it that said “The great thing about standards is that there are so many to choose from”?
Some encryption schemes used by IPsec are not “NATable”. For example unencapsulated FMZ and NAT routers don’t play nicely. Try using ISAKMP or encapsulated FMZ encryption if your IPsec client allows those choices. (For more information on this, go to this page.)
Here are some tips that we’ve picked up from users. If you’d like to contribute information on how you got your VPN setup working, send it in!
AT&T Client VPN
AT&T Global Networks (formerly IBM Global Networks),has used IPSec Header Authentication, and thus would not work through a NAT device. The new version of the AT&T Client VPN software (which they call the “dialer” with Bluemoon Tunneling) now supports IPSec Data Authentication without IPSec Header Authentication, and it now works through routers.
In order to make this work, though, you need to put the following two undocumented statements in the “custom.ini” file which is located in the same directory as the rest of the VPN client software (typically c:\program files\AT&T Global Network\). The version of the AT&T client software must be 4.25.2 or higher (which was released on Sept 6, 2000). Also make sure IPSec passthru is enabled on your router if that is required.
In custom.ini put:
(If you’re not comfortable with editing the custom.ini file, ATT Global Network Services has a handy tool that you can download and run that will do it for you. Go here and download “natswitch.exe” and run it.)
No port forwarding needed in router. Set “allow NAT passthru” in Altiga client
Compatible Systems (now a part of Cisco) IntraPort VPN client
[Thanks to Chad Varner]
Set “Use NAT Transparency Mode” option, then completely close the VPN client and start it again. It doesn’t always recognize the change in status on that checkbox, until you close and restart the client.
If your ISP uses “WCCP” (Web Cache Control Protocol… a feature of some Cisco routers), NAT Transparency Mode will not work. When NAT Transparency Mode is enabled, the VPN client communicates with the server via TCP ports “http” (80) and 500. “WCCP” performs caching on port 80, to speed up web access. This caching on port 80 prevents you from establishing the authenticated VPN tunnel between your client and the VPN server on the other end.
On a related note, some ISP’s use “CacheFlow” servers: this is WCCP by another name, and causes exactly the same problem. Compatible’s tech support says if the ISP does any caching on port 80, whether WCCP, CacheFlow, or otherwise, NAT Transparency Mode will not work, period, finis, end of story. So far, the only way around WCCP is to obtain a static IP address and have the ISP route your address around the WCCP server. Or, change ISP’s to one that does not use WCCP.
Check Point VPN-1 SecuRemote 4.1
You may need to set your client to use UDP Encapsulation mode:
====From the SecureRemote 4.1 SP2 readme======
UDP Encapsulation Mode enables IKE/IPSec SecuRemote users to traverse Network Address Translation devices, firewalls and other devices that fail to handle IPSec packets. It also enables more than one SecuRemote user to work with IPSec behind a port-mapping NAT device, also known as dynamic NAT, (e.g., FireWall-1 Hide NAT mode) with the same VPN-1/SecuRemote/SecureClient gateway. This is achieved by encapsulating IPSec packets inside UDP datagrams. This option is negotiated in IKE. VPN-1/SecuRemote/ SecureClient supports this feature only in IPSec ESP mode (AH is not supported).
Two modes of UDP Encapsulation are available:
– Automatic mode in which UDP encapsulation is performed only when the SecuRemote client is behind a dynamic Network Address Translation device configured for Hide mode. In other cases, IPSec packets are transmitted in the standard manner. The server determines how to transmit IPSec packets according to value of the source port in IKE packets.
– Forced mode in which the client can work only in UDP Encapsulation Mode. Communication is enabled only if the gateway supports UDP encapsulation and always uses UDP Encapsulation Mode. Forced mode should be used if the client is behind devices which drop or damage IPSec packets but do not modify IKE packets.
Nortel Extranet client:
Try forwarding Ports 500 and 1723 to your IPsec LAN client
Also see this example of a Nortel Extranet and IP phone setup with an SMC Barricade router.
Using SecureID token cards for authentication?
try forwarding TCP/UDP port 500 to your LAN client
Shiva Lanrover VPN: Forward Port 2233 to your VPN LAN client.
Watchguard Mobile User VPN Client 2.0:
Set up a AnyVPN service
From: ipsecusers To: Trusted
Outgoing From: Trusted To: ipsecusers
15 Tips for Troubleshooting VPN connections (mostly about PPTP)
Network Computing’s “Why Can’t IPsec and NAT just get along?” explains why your IPsec connection may not be working through your NAT router.
Another Network Computing goodie, “Making IPsec work for you” has a good explanation of IKE’s Main, Aggressive, and Quick modes on page 3.
Although SonicWall’s VPN FAQs are mainly for their products, there’s info there that you may find useful in figuring out why you can’t get your IPsec tunnel working. Scroll to the bottom of this page.
If you really want to get into it, go to the IETF’s IPsec working group page for all the RFQs and real brain-bending stuff!