PLEASE NOTE: As of firmware version 4.10, the IPSec ALG will allow multiple hosts behind a single PAT address to simultaneously establish and maintain tunnels to the multiple exterior hosts. The only limitation will be that the IKE negotiations and the first ESP exchange may not be overlapped to a single remote host.
PLEASE NOTE: If your router is currently running Netopia Residential Firmware with a web "GUI" configuration menu, this technote is not applicable to you. Most 3300 Series Netopia Gateways can be upgraded to Enterprise level firmware. Click Here! to purchase the upgrade key.
Related documents:
Firmware References:
- v8.2 R1 (and up) - 3300 Enterprise Series
- v5.3.7 (and up) - 4000 Series
- v4.8.2 (and up) - R-Series
Login with the user name and password. The Superuser login is required to save changes. If you are unsure of this, contact your network administrator.
Don't forget to press the Enter key to save any entries. Hitting the back space, delete or tab without first hitting enter will undo any changes.
The Esc key will take you back towards the main menu screen.
Once you have completed your configuration, you should reboot the Netopia to save and apply your changes.
The Netopia Main Menu Interface
As of firmware version 4.8, Netopia routers support passthrough of IPSec tunnels through NAT. IPSec is passed through NAT by adding a Server List entry on port 500.
As of firmware version 4.10, the IPSec ALG will allow multiple hosts behind a single PAT address to simultaneously establish and maintain tunnels to the multiple exterior hosts. The only limitation will be that the IKE negotiations and the first ESP exchange may not be overlapped to a single remote host.
Please Note: Some vendor implementations will use other ports besides UDP 500, and these ports would also need to be mapped, but in a separate server list entry.
Prior to firmware version 4.8, there was no easy way to map IPSec through NAT because most IPSec tunnels use several IP protocols that are not port-based. Specifically, most IPSec implementations will use Encapsulation Header (ESP), which is IP protocol 50, and/or Authentication Header (AH), which is IP protocol 51, in addition to Internet Key Exchange (IKE), which runs on UDP port 500. Version 4.8 of the firmware incorporates an application level gateway (ALG) that automatically forwards protocols 50 & 51 to any destination host that has a port 500 mapping.
If your IPSec client is still failing to connect when using a Server List entry on port 500, it may be possible to get it working by setting up a Transparent Map.
Transparent mapping requires that you have a valid *routed* IP subnet. A bridged block of address is not sufficient; the subnet must conform to a valid routable IP range. This means that the router's Ethernet IP Address and Default IP Gateway will be on different subnets.
Regardless of the procedure used, simply forwarding the protocols through NAT may not always be enough to establish an IPSec tunnel. Because IPSec is a security protocol, it performs a number of checks to determine if a packet has been tampered with. This can often cause problems when the protocol is passed through NAT, as NAT changes the source address of the packet from the original (unroutable) source address used on the workstation to that of the (routable) WAN address of the router. NAT must change the private source address, or the NAT process itself would break and no outbound traffic from the LAN hosts would be possible.
There are numerous options available when creating an IPSec tunnel. Some of them are more tolerant of NAT than others. Not all vendors will allow for all options, and in many cases implementation of a given option may vary from vendor to vendor. This makes it difficult to provide cut-and-dried guidelines for what will work through NAT. Nonetheless, some generalizations can be made about the key features of an IPSec tunnel and how they will react to NAT.
Transport mode is most common on software IPSec clients and is primarily intended for host-to-host connections. Tunnel mode is most common on hardware implementations and is primarily intended for network-to-network (or host-to-network) connections. There are of course exceptions to these generalizations. The key difference between the two modes is in *how* the packet is encapsulated and authenticated (regardless of the protocol used).
Transport mode will usually have issues with NAT. It places a security protocols header immediately after the initial IP header. Since NAT modifies the IP header, but not the security protocol header, then information contained in the security protocol header is different than that in the IP header after NAT has modified it, and this will generally cause the packet to fail a checksum authentication.
Tunnel mode is more NAT-friendly than transport mode. In tunnel mode, there is an additional IP header added to the packet. NAT modifies this 'outer' IP header, which is not used in authenticating the packet (unless AH is used as the Authentication protocol). This leaves the 'inner' IP header intact, and so there is no discrepancy between the information it contains and the information contained in the security protocols header.
Authentication Header will basically never work through NAT (unless using a Transparent Map) because AH performs a checksum authentication on the packet, including parts of the IP header. When NAT changes the source address of the packet (in the IP header), the checksum value changes. AH will detect this change and fail the packet. A transparent map works around this issue because the original source IP Address of the packet (as supplied by the originating workstation) and the final source IP address of the packet (as modified by NAT) are identical because of the way the mapping is configured.
ESP on the other hand doesn't perform this same checksum on the header of the packet, and so should map nicely through NAT with no real problems.
IKE (Internet Key Exchange) is the most popular automatic key exchange protocol in current use. IKE and other protocols for automatic key exchange will have problems with NAT because most implementations of such key-exchange mechanisms enforce a strict policy whereby the remote party must know the source address from which the traffic originates. The issue here is similar to the issues with AH - the source addresses are different after NAT modifies them. IKE in 'Main Mode' may work with shared secrets, IF there is a provision in the vendor implementation for telling the remote party what source IP address NAT will re-map the IPSec packets to. IKE may also work in other modes where the cryptographic mechanism is not source-address dependent.
Manual keys bypass all of these issues by design; in a sense manual keys are less secure than IKE because the keys never change, but this also makes the key exchange process easier to get through NAT.
From the above discussion, it should be apparent that IPSec works best through NAT when in Tunnel mode, using ESP encapsulation and manual keys. Transport mode and/or automatic key exchange protocols (such as IKE or ISAKMP) *may* work through NAT, but are likely to have issues, depending on vendor implementation. Authentication Header (AH) will almost always fail through NAT, unless a transparent map is used. A transparent map should work in almost all cases if the port 500 based mapping fails.