Algorithm proposal lists – Amer Networks E5Web GUI User Manual
Page 591
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 gateway no special
configuration is needed. However, for responding gateways two points should be noted:
•
On responding gateways, the Remote Endpoint 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
gateway 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 the two gateways 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).
Several algorithm proposal lists are already defined by default in cOS Core for different VPN
scenarios and user defined lists can be added.
Two IKE algorithm lists and two IPsec lists are already defined by default:
•
High
This consists of a more restricted set of algorithms to give higher security. The complete list is
3DES, AES, Blowfish, MD5, SHA1.
•
Medium
This consists of a longer set of algorithms. The complete list is 3DES, AES, Blowfish, Twofish,
Chapter 9: VPN
591