adapted description to IKEv2

This commit is contained in:
Andreas Steffen
2012-06-22 09:53:37 +02:00
parent aa8898bc45
commit fc16296391
3 changed files with 5 additions and 6 deletions
@@ -2,7 +2,7 @@ The peers <b>carol</b> and <b>moon</b> both have dynamic IP addresses, so that t
is defined symbolically by <b>right=&lt;hostname&gt;</b>. The ipsec starter resolves the is defined symbolically by <b>right=&lt;hostname&gt;</b>. The ipsec starter resolves the
fully-qualified hostname into the current IP address via a DNS lookup (simulated by an fully-qualified hostname into the current IP address via a DNS lookup (simulated by an
/etc/hosts entry). Since the peer IP addresses are expected to change over time, the option /etc/hosts entry). Since the peer IP addresses are expected to change over time, the option
<b>rightallowany=yes</b> will allow an IKE main mode rekeying to arrive from an arbitrary <b>rightallowany=yes</b> will allow an IKE_SA rekeying to arrive from an arbitrary
IP address under the condition that the peer identity remains unchanged. When this happens IP address under the condition that the peer identity remains unchanged. When this happens
the old tunnel is replaced by an IPsec connection to the new origin. the old tunnel is replaced by an IPsec connection to the new origin.
<p> <p>
@@ -2,7 +2,7 @@ The peers <b>carol</b> and <b>moon</b> both have dynamic IP addresses, so that t
is defined symbolically by <b>right=&lt;hostname&gt;</b>. The ipsec starter resolves the is defined symbolically by <b>right=&lt;hostname&gt;</b>. The ipsec starter resolves the
fully-qualified hostname into the current IP address via a DNS lookup (simulated by an fully-qualified hostname into the current IP address via a DNS lookup (simulated by an
/etc/hosts entry). Since the peer IP addresses are expected to change over time, the option /etc/hosts entry). Since the peer IP addresses are expected to change over time, the option
<b>rightallowany=yes</b> will allow an IKE main mode rekeying to arrive from an arbitrary <b>rightallowany=yes</b> will allow an IKE_SA rekeying to arrive from an arbitrary
IP address under the condition that the peer identity remains unchanged. When this happens IP address under the condition that the peer identity remains unchanged. When this happens
the old tunnel is replaced by an IPsec connection to the new origin. the old tunnel is replaced by an IPsec connection to the new origin.
<p> <p>
@@ -3,10 +3,9 @@ so that the remote end is defined symbolically by <b>right=%&lt;hostname&gt;</b>
The ipsec starter resolves the fully-qualified hostname into the current IP address The ipsec starter resolves the fully-qualified hostname into the current IP address
via a DNS lookup (simulated by an /etc/hosts entry). Since the peer IP addresses are via a DNS lookup (simulated by an /etc/hosts entry). Since the peer IP addresses are
expected to change over time, the prefix '%' is used as an implicit alternative to the expected to change over time, the prefix '%' is used as an implicit alternative to the
explicit <b>rightallowany=yes</b> option which will allow an IKE explicit <b>rightallowany=yes</b> option which will allow an IKE_SA rekeying to arrive
main mode rekeying to arrive from an arbitrary IP address under the condition that from an arbitrary IP address under the condition that the peer identity remains unchanged.
the peer identity remains unchanged. When this happens the old tunnel is replaced When this happens the old tunnel is replaced by an IPsec connection to the new origin.
by an IPsec connection to the new origin.
<p> <p>
In this scenario both <b>carol</b> and <b>dave</b> initiate a tunnel to In this scenario both <b>carol</b> and <b>dave</b> initiate a tunnel to
<b>moon</b> which has a named connection definition for each peer. Although <b>moon</b> which has a named connection definition for each peer. Although