IPSec - Status

The status page shows all current IPSec connections (=tunnels) that are terminated by this unit.

To understand what is really shown on this page it is necessary to learn a bit about IPSec, IKE and its two negotiation phases:
(Read more: VPN Overview IPSec IKE)

Normally, the first thing that happens in an IPSec session is that IKE tries to establish a connection with the remote gateway, basically to sort out which (temporary) encryption/authentication key to use during the subsequent data transfer. This 1:st phase is popularly called “main mode”. If this fails, no SA (Security association) tunnel will show up. The Status under IKE Security associations shows Negotiating and never reaches Activated state. A problem may be caused by:

• The remote peer (gateway) couldn't simply be reached.
• Mode mismatch: there are two modes of negotiation: main mode and aggressive mode, the two peers must use the same mode.
• Algorithm mismatch: the two peers cannot agree on a mutual set of authentication/encryption algorithms. Each peer has a number of (Internet Gate has three) acceptable combinations of algorithms, and at least one of these combinations must be the same as the other peer suggests. Traditionally, the combination of 3DES and MD5 has been supported by most IPSec implementations.
• ID mismatch: the two peers don't fully recognize each other's type/contents of ID (identification payload). The ID type expected must be equal at both ends.
• Key mismatch: the two peers have different opinions about what pre-shared key to be used.
• Certificate mismatch: one of the peers could not get the other's certificate (containing the public key) or the acquired certificate could not be verified properly.

To fix the problems the settings on the IPSec - VPN peer settings (IKE) page should be addressed, but there might as well be a fault in the settings of the remote peer, which certainly has similar settings in its configuration menues.

If the IKE has been successful it now carries on negotiating (and tries creating) two IPSec tunnels, called SA:s (Security associations), one in each direction. This negotiation is often called Phase 2 or Quick mode. If this fails, no SA (Security association) tunnel will show up in spite of the IKE SA (phase 1) being ready and Activated. In this case there may be problems with:

• Protocol mismatch: the two peers cannot agree on a mutual protocol (AH, ESP or both).
• Algorithm mismatch: the two peers cannot agree on a mutual set of authentication/encryption algorithms. As with the 1:st phase, each peer has a number of (Internet Gate has three) acceptable combinations of algorithms, and at least one of these combinations must be the same as the other peer suggests. Traditionally, the combination of 3DES and MD5 has been supported by most IPSec implementations.
• PFS (Perfect Forward Secrecy) settings mismatch. Both peers must agree on using it - or not using it.
• IP address mismatch of the local/remote networks in the connection settings.

Problems with this Phase 2 are typically related to the settings on the IPSec - VPN Connection Settings page, but again the settings of the other end should also be checked for any configuration faults.

The IKE SA is capable of establishing more than one pair of IPSec tunnels (SA:s). Furthermore, some time before a SA is timed out, a new pair of SA:s will be negotiated by IKE, if there is need for the tunnel to be kept open (which depends on whether packets keep coming in or not). Consequently, during the transition phase one might see four SA:s set up, two in each direction, where one pair has a low Elapsed time value, the other pair is aged and will die out as the new tunnel takes over.

In time, a similar thing will happen with the IKE SA itself, a new such IKE SA (“key tunnel”) will be born and showed in the IKE Security associations list, the old one will die some time after.

When the phase 2 SA is up and running it will start transmitting the actual data packets, this can be monitored by studying the Bytes processed counter. The first packet to be sent will be the one that triggered the negotiation and due to that procedure it will be heavily delayed. But subsequent packets will suffer from no such delay, the tunnel is kept open and will be replaced by a new SA (as has been described) if needed, well in advance before the lifetime runs out.

• The IKE packets themselves show up as UDP packets to port 500 (=ISAKMP), to/from the WAN interface of the Internet Gate.
• As for the actual data traffic: on the inside LAN interface the packets are shown before being encrypted into the tunnel (resp. after they have been decrypted from the tunnel), with their TCP/UDP headers visible (port numbers, IP destination etc).
• On the WAN port, however, these packets are forwarded as ESP or AH packets - the TCP or UDP (or whatever) header/payload is disguised (encrypted) on that interface. The original destination IP address is also invisible, since all AH/ESP packets are simply sent to the remote IPSec gateway.

The VPN log page is also useful for monitoring the progress of the IPsec tunnels.

List of all currently active “traffic tunnels” - tunnels used for data traffic. Two traffic tunnels (one for each direction) are created for each active IPSec connection. Security association

Destination Global IP address of the connected peer for the tunnel. (For outgoing tunnels the IP address of the remote peer, for incoming tunnels the own global IP address of this unit.)
Direction “Incoming” or “Outgoing” depending on whether the tunnel is used to receive or transmit data.
SPI (Security Parameter Index) Tunnel ID number to uniquely identify the SA, showed by the firewall log. SPI
Protocol IPSec encapsulation protocol. Can be AH (Authentication Header) and/or ESP (Encapsulating Security Payload) protocol.
Algorithm Encryption/authentication algorithms used.
Elapsed time Tunnel uptime (number of seconds since it was established).
Life time Maximum allowed uptime for the tunnel. If elapsed time approaches this value a new traffic tunnel will be negotiated.
Bytes processed Number of data bytes transferred in the tunnel since its establishment.
Errored packets Number of packets not conforming or dropped due to errors, since tunnel was established.

Delete Close the traffic tunnel. A new tunnel will automatically be created if there is more data to transfer. Should not be used except to close obsolete unclosed connections.

List of all currently active “key tunnels” - tunnels used for key exchange. Key tunnels are used to negotiate traffic tunnels. IKE

Remote Gateway Global IP address of the remote peer.
Status Tunnel status: Activated / Idle /Negotiating(x) (where x is negotiation state 1-8, see table below).
Algorithm Authentication/encryption algorithms used.
Elapsed time Tunnel uptime (number of seconds since it was established).
Life time Maximum allowed uptime for this tunnel. If time has elapsed a new key tunnel will be created.
NAT-T NAT-Traversal: none means NAT-T is not used (native IPSec packets are used). Far end and Near end means NAT-T is active, IPSec packets are embedded inside UDP packets, and the NAT is detected to be at the remote or local end of the connection.
Phase 2 negotiations - Number of times a traffic tunnel has successfully been negotiated (possibly due to traffic tunnel life time timeouts).

Delete - Close the key tunnel. A new tunnel will automatically be created if there is more data to transfer. Should not be used except to close obsolete unclosed connections.

These tables show the interpretation of the state number showed in the Status column. The state merely shows how far in the message exchange the negotiation has reached at a certain point. Along with the entries in the VPN log, it could give a clue where a particular negotiaition fails.

In order to use the table correctly one must also know:

• Is main or aggressive mode used? This is shown in the IKE phase1 mode dropdown box in IPSec - VPN peer settings (IKE).
• Are we the initiator or responder? Check the settings in the Act as dropdown box in IPSec - VPN peer settings (IKE). If “Initiator and responder” is selected, the role can change, and must be judged by establishing who is sending the first packet to go into the tunnel (e.g. a PING packet).

Understanding the message exchange and the contents of the packets is advanced and necessarily involves reading the RFC2409.