D-Link 800 - DFL 800 - Security Appliance, User Manual

Page: 341 / 469

To achieve NAT detection both IPsec peers send hashes of their own IP addresses along with the
source UDP port used in the IKE negotiations. This information is used to see whether the IP
address and source port each peer uses is the same as what the other peer sees. If the source address
and port have not changed, then the traffic has not been NATed along the way, and NAT traversal is
not necessary. If the source address and/or port has changed, then the traffic has been NATed, and
NAT traversal is used.
Changing Ports
Once the IPsec peers have decided that NAT traversal is necessary, the IKE negotiation is moved
away from UDP port 500 to port 4500. This is necessary since certain NAT devices treat UDP
packet on port 500 differently from other UDP packets in an effort to work around the NAT
problems with IKE. The problem is that this special handling of IKE packets may in fact break the
IKE negotiations,which is why the UDP port used by IKE has changed.
UDP Encapsulation
Another problem that NAT traversal resolves is that the ESP protocol is an IP protocol. There is no
port information as we have in TCP and UDP, which makes it impossible to have more than one
NATed client connected to the same remote gateway and at the same time. Because of this, ESP
packets are encapsulated in UDP. ESP-UDP traffic is sent on port 4500, the same port as IKE when
NAT traversal is used. Once the port has been changed, all following IKE communication is done
over port 4500. Keep-alive packets are also sent periodically to keep the NAT mapping alive.
NAT Traversal Configuration
Most NAT traversal functionality is completely automatic and in the initiating firewall no special
configuration is needed. However, for responding firewalls two points should be noted:
• On responding firewalls, the Remote Gateway field is used as a filter on the source IP of
received IKE packets. This should be set to allow the NATed IP address of the initiator.
• When individual pre-shared keys are used with multiple tunnels connecting to one remote
firewall which are then NATed out through the same address, it is important to make sure the
Local ID is unique for every tunnel. The Local ID can be one of
• Auto - The local ID is taken as the IP address of the outgoing interface. This is the
recommended setting unless, in an unlikely event, the two firewalls have the same external
IP address.
• IP - An IP address can be manually entered
• DNS - A DNS address can be manually entered
• Email - An email address can be manually entered
9.3.6. Algorithm Proposal Lists
To agree on the VPN connection parameters, a negotiation process is performed. As a result of the
negotiations, the IKE and IPsec security associations (SAs) are established. A proposal list of
supported algorithms is the starting point for the negotiation. Each entry in the list defines
parameters for a supported algorithm that the VPN tunnel end point device is capable of supporting
(the shorter term tunnel endpoint will also be used in this manual). The initial negotiation attempts
to agree on a set of algorithms that the devices at either end of the tunnel can support.
There are two types of proposal lists, IKE proposal lists and IPsec proposal lists. IKE lists are used
during IKE Phase-1 (IKE Security Negotiation), while IPsec lists are using during IKE Phase-2
(IPsec Security Negotiation).
9.3.6. Algorithm Proposal Lists Chapter 9. VPN
341