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

upgraded ikev1 scenarios to 5.0.0

Browse Source
This commit is contained in:
Andreas Steffen
2012-05-23 14:45:15 +02:00
parent 3c475660c5
commit 148b643880
973 changed files with 1476 additions and 13035 deletions
Download Patch File Download Diff File Expand all files Collapse all files
testing/tests/ikev1/dpd-restart/description.txt
+7 -13
View File
@@ -1,13 +1,7 @@
The peer <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 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> disconnects (simulated by iptables blocking IKE and ESP traffic).
<b>moon</b> detects via Dead Peer Detection (DPD) that the connection is down and tries to
reconnect. After a few seconds the firewall is opened again and the connection is
reestablished.
The roadwarrior <b>carol</b> sets up an IPsec tunnel connection to the gateway
<b>moon</b>. Both end points activate <b>Dead Peer Detection</b> (DPD) with a
polling interval of 10 s. When the network connectivity between <b>carol</b>
and <b>moon</b> is forcefully disrupted for a duration of 100 s, <b>moon</b>
clears the connection after 4 unsuccessful retransmits whereas <b>carol</b>
also takes down the connection but immediately tries to reconnect which succeeds
as soon as the connection becomes available again.