testing: Adapt tests to retransmission settings and reduce DPD delay/timeout

This commit is contained in:
Tobias Brunner
2015-11-09 15:18:34 +01:00
parent 50a43fbb97
commit f36b6d49af
26 changed files with 43 additions and 43 deletions
@@ -1,5 +1,5 @@
The roadwarrior <b>carol</b> sets up an IPsec tunnel connection to the gateway <b>moon</b>
which in turn activates <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,
<b>moon</b> clears the connection after 4 unsuccessful retransmits.
<b>moon</b> clears the connection after a number of unsuccessful retransmits.
+2 -2
View File
@@ -1,8 +1,8 @@
carol::ipsec status 2> /dev/null::home.*INSTALLED, TUNNEL::YES
moon:: ipsec status 2> /dev/null::rw.*INSTALLED, TUNNEL::YES
carol::iptables -A INPUT -i eth0 -s PH_IP_MOON -j DROP::no output expected::NO
moon:: sleep 180::no output expected::NO
moon:: sleep 13::no output expected::NO
moon:: cat /var/log/daemon.log::sending DPD request::YES
moon:: cat /var/log/daemon.log::retransmit.*of request::YES
moon:: cat /var/log/daemon.log::giving up after 5 retransmits::YES
moon:: cat /var/log/daemon.log::giving up after.*retransmits::YES
moon:: ipsec status 2> /dev/null::rw.*INSTALLED::NO
+3 -3
View File
@@ -2,13 +2,13 @@ carol::ipsec status 2> /dev/null::home.*INSTALLED, TUNNEL::YES
moon:: ipsec status 2> /dev/null::rw.*INSTALLED, TUNNEL::YES
moon:: iptables -A INPUT -i eth0 -s PH_IP_CAROL -j DROP::no output expected::NO
carol::iptables -A INPUT -i eth0 -s PH_IP_MOON -j DROP::no output expected::NO
carol::sleep 180::no output expected::NO
carol::sleep 13::no output expected::NO
carol::cat /var/log/daemon.log::sending DPD request::YES
carol::cat /var/log/daemon.log::retransmit.*of request::YES
carol::cat /var/log/daemon.log::giving up after 5 retransmits::YES
carol::cat /var/log/daemon.log::giving up after.*retransmits::YES
carol::iptables -D INPUT -i eth0 -s PH_IP_MOON -j DROP::no output expected::NO
moon:: iptables -D INPUT -i eth0 -s PH_IP_CAROL -j DROP::no output expected::NO
carol::ping -c 1 PH_IP_ALICE::trigger route::NO
carol::sleep 2::no output expected::NO
carol::sleep 1::no output expected::NO
carol::ipsec status 2> /dev/null::home.*INSTALLED, TUNNEL::YES
moon:: ipsec status 2> /dev/null::rw.*INSTALLED, TUNNEL::YES
+3 -3
View File
@@ -2,12 +2,12 @@ carol::ipsec status 2> /dev/null::home.*INSTALLED, TUNNEL::YES
moon:: ipsec status 2> /dev/null::rw.*INSTALLED, TUNNEL::YES
moon:: iptables -A INPUT -i eth0 -s PH_IP_CAROL -j DROP::no output expected::NO
carol::iptables -A INPUT -i eth0 -s PH_IP_MOON -j DROP::no output expected::NO
carol::sleep 180::no output expected::NO
carol::sleep 13::no output expected::NO
carol::cat /var/log/daemon.log::sending DPD request::YES
carol::cat /var/log/daemon.log::retransmit.*of request::YES
carol::cat /var/log/daemon.log::giving up after 5 retransmits::YES
carol::cat /var/log/daemon.log::giving up after.*retransmits::YES
carol::iptables -D INPUT -i eth0 -s PH_IP_MOON -j DROP::no output expected::NO
moon:: iptables -D INPUT -i eth0 -s PH_IP_CAROL -j DROP::no output expected::NO
carol::sleep 10::no output expected::NO
carol::sleep 1::no output expected::NO
carol::ipsec status 2> /dev/null::home.*INSTALLED, TUNNEL::YES
moon:: ipsec status 2> /dev/null::rw.*INSTALLED, TUNNEL::YES
@@ -1,12 +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
is defined symbolically by <b>right=&lt;hostname&gt;</b>. The IKE daemon 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_SA rekeying to arrive from an arbitrary
<b>%</b> prefix in the <b>right</b> option 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
the old tunnel is replaced by an IPsec connection to the new origin.
<p>
In this scenario <b>carol</b> first initiates a tunnel to <b>moon</b>. After some time <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> and starting the connection from host <b>dave</b> using <b>carol</b>'s identity).
@@ -1,7 +1,7 @@
moon:: ipsec status 2> /dev/null::rw.*INSTALLED, TUNNEL::YES
carol::ipsec status 2> /dev/null::home.*INSTALLED, TUNNEL::YES
carol::ping -c 1 -s 120 -p deadbeef PH_IP_ALICE::128 bytes from PH_IP_ALICE: icmp_req=1::YES
carol::sleep 15::NO
carol::sleep 11::NO
carol::cat /var/log/daemon.log::deleting CHILD_SA after 10 seconds of inactivity::YES
moon:: ipsec status 2> /dev/null::rw.*INSTALLED::NO
carol::ipsec status 2> /dev/null::home.*INSTALLED::NO
@@ -6,5 +6,5 @@ OCSP server is listening. Thanks to timeouts the connection can nevertheless
be established successfully by contacting a valid OCSP URI contained in
<b>carol</b>'s certificate.
<p>
As an additional test the OCSP response is delayed by 5 seconds in order to check
As an additional test the OCSP response is delayed by a few seconds in order to check
the correct handling of retransmitted IKE_AUTH messages.
@@ -6,7 +6,7 @@ echo "Content-type: application/ocsp-response"
echo ""
# simulate a delayed response
sleep 5
sleep 2
cat | /usr/bin/openssl ocsp -index index.txt -CA strongswanCert.pem \
-rkey ocspKey.pem -rsigner ocspCert.pem \
@@ -2,8 +2,4 @@
charon {
load = test-vectors aes des sha1 sha2 md5 pem pkcs1 pkcs8 gmp random nonce x509 curl revocation hmac xcbc cmac ctr ccm gcm stroke kernel-netlink socket-default updown
retransmit_timeout = 2
retransmit_base = 1.5
retransmit_tries = 3
}