====== IPSec - Status ====== The status page shows all current IPSec connections (=tunnels) that are terminated by this unit. {{:web_gui:vpn_status_page.png?303|VPN Status page in rel 5.30}} ==== Understanding the phases ==== 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:start|VPN Overview]] [[wp>IPsec|IPSec]] [[wp>Internet_Key_Exchange|IKE]]) === Phase 1 (main or aggressive mode) === 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 [[#Security associations|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. * [[vpn:certificates|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 [[web_gui:vpn_peer|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. === Phase 2 === If the IKE has been successful it now carries on negotiating (and tries creating) two IPSec tunnels, called [[#Security associations|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 [[web_gui:vpn_connection|connection]] settings. Problems with this Phase 2 are typically related to the settings on the [[web_gui:vpn_connection|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. \\ \\ \\ ==== ==== ---- :!: There are a few things to remember when reading the [[web_gui:firewall_log_page|firewall log]] for IPSec traffic:\\ * 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|VPN log]] page is also useful for monitoring the progress of the IPsec tunnels. \\ ===== Security associations ===== 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. [[wp>Security_association|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. [[wp>Security_Parameter_Index|SPI]]\\ **Protocol** IPSec encapsulation protocol. Can be AH ([[wp>IPsec#Authentication_Header|Authentication Header]]) and/or ESP ([[wp>IPsec#Encapsulating_Security_Payload|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. ===== IKE Security associations ===== List of all currently active "key tunnels" - tunnels used for key exchange. Key tunnels are used to negotiate traffic tunnels. [[wp>Internet_Key_Exchange|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 [[#Negotiation states|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 [[wp>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. === Negotiation states === 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 [[web_gui:vpn_peer|IPSec - VPN peer settings (IKE)]]. * Are we the initiator or responder? Check the settings in the **Act as** dropdown box in [[web_gui:vpn_peer|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). ^ main mode ^^^ ^ ^ initiator ^ responder ^ |Idle(0)| --- | --- | |1|start|start (1st msg received)| |2| --- |1st valid msg received| |3|1st msg sent|1st msg sent| |4|1st valid msg received|2st valid msg received| |5|2nd msg sent|2nd msg sent| |6|2nd valid msg received|3rd valid msg received| |7|3rd msg sent|3rd msg sent| |8|3rd valid msg received| --- | |Activated(9)|IKE SA established|IKE SA established| ^ aggressive mode ^^^ ^ ^ initiator ^ responder ^ |Idle(0)| --- | --- | |1|start|start (1st msg received)| |2| --- |1st valid msg received| |3|1st msg sent|1st msg sent| |4|1st valid msg received|2st valid msg received| |5| --- | --- | |6| --- | --- | |7| --- | --- | |8| --- | --- | |Activated(9)|IKE SA established|IKE SA established| Understanding the message exchange and the contents of the packets is advanced and necessarily involves reading the [[http://tools.ietf.org/html/rfc2409|RFC2409]].