Differences

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

web_gui:vpn_status_page [2010/11/19 09:58]
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. 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 ==== ==== Understanding the phases ====
Line 14: Line 16:
  * The remote peer (gateway) couldn't simply be reached.   * 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.   * 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.   * 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.   * 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. 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 === === 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//. 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: In this case there may be problems with:
  * Protocol mismatch: the two peers cannot agree on a mutual protocol (AH, ESP or both).   * 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.   * 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. 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). 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. 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 52: Line 54:
  * 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).   * 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.   * 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 ===== ===== Security associations =====
Line 59: 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.)\\ **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.\\ **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.\\ **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.\\ **Algorithm** Encryption/authentication algorithms used.\\
**Elapsed time** Tunnel uptime (number of seconds since it was established).\\ **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.\\ **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.\\ **Errored packets** Number of packets not conforming or dropped due to errors, since tunnel was established.\\
Line 89: Line 94:
In order to use the table correctly one must also know: 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)]]. +  * 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?+  * 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  ^^^ ^  main mode  ^^^
Line 117: Line 122:
|8|  ---  |  ---  | |8|  ---  |  ---  |
|Activated(9)|IKE SA established|IKE SA established| |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]].
web_gui/vpn_status_page.1290157101.txt.gz · Last modified: 2010/11/19 09:58 by mats
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0