denozord/strongswan-ext
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

testing: Reorganizing IKEv1 and IKEv2 examples

Browse Source 
For documentation purposes the new folders ikev1-algs, ikev2-algs,
ikev1-multi-ca and ikev2-multi-ca have been created. Most of the
test cases have now been converted to the vici interface. The
remaining legacy stroke scenarios yet to be converted have been put
into the ikev2-stroke-bye folder.

For documentation purposes some legacy stroke scenarios will be kept
in the ikev1-stroke, ikev2-stroke and ipv6-stroke folders.
This commit is contained in:
Andreas Steffen
2021-05-21 09:42:50 +02:00
parent db93938297
commit 7c5a2974b9
4054 changed files with 16375 additions and 15209 deletions
Download Patch File Download Diff File Expand all files Collapse all files
testing/tests/ikev1/dynamic-responder/description.txt
Regular → Executable
+6 -7
View File
@@ -1,13 +1,12 @@
The peers <b>carol</b> and <b>moon</b> both have dynamic IP addresses, 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 via a DNS lookup (simulated by an
/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
IP address under the condition that the peer identity remains unchanged. When this happens
The peers <b>carol</b> and <b>moon</b> both have dynamic IP addresses, so that the
<b>remote_addrs</b> field contains a <b>Fully Qualified Domain Name</b> (FQDN) which
is evaluated just before use via a DNS lookup (simulated by an /etc/hosts entry).
This will allow an IKE main mode rekeying to arrive from an arbitrary 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.
<p>
In this scenario <b>moon</b> first initiates a tunnel to <b>carol</b>. After some time
the responder <b>carol</b> suddenly changes her IP address and restarts the connection to
<b>moon</b> without deleting the old tunnel first (simulated by iptables blocking IKE packets
to and from <b>carol</b> and starting the connection from host <b>dave</b> using
<b>carol</b>'s identity).
<b>carol</b>'s identity).