Differences

This shows you the differences between two versions of the page.

--- web_gui:vpn_status_page [2010/11/18 14:49] – mats
+++ web_gui:vpn_status_page [2010/11/26 14:11] (current) – mats
@@ Line 2: / Line 2: @@
 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 ====
@@ Line 14: / Line 16: @@
   * 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.
+  * 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.
+  * [[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.
@@ Line 23: / Line 25: @@
 === Phase 2 ===
-If the IKE is successful it starts to negotiate two IPSec tunnels, called SA:s (Security associations), one in each direction.
+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 [[#Security associations|SA (Security association)]] tunnel will show up in spite of the IKE SA being ready and //Activated//.
+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.
+  * 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:connection]] settings.
+  * 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).
+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.
@@ Line 43: / Line 45: @@
 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.
+\\
+\\
+\\
 ==== ====
 ----
@@ Line 51: / Line 55: @@
   * 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.
@@ Line 57: / Line 64: @@
 **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 used by the firewall log. [[wp>Security_Parameter_Index|SPI]]\\
+**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 reaches this value a new traffic tunnel will be negotiated.\\
+**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.\\
@@ Line 71: / Line 78: @@
 **Remote Gateway** Global IP address of the remote peer.\\
-**Status** Tunnel status: Activated / Idle /Negotiating(x) (where x is negotiation state 1-8).\\
+**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).\\
@@ Line 81: / Line 88: @@
+=== 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]].