[strongSwan] Issue with net-net scenario with load-tester plugin (using strongSwan 5.0.4)

[Chinmaya Dwibedy]

Hi Martin,
Thanks for yours response.  
In our topology , the traffic selectors for the would be 10.0.0.0/8
and 40.0.0.0/8, defining the two subnets that are to be connected by the IPSec
tunnel are not aware that their respective VPN gateways (Say A and B) with
external IP addresses 30.30.30.11 and 30.30.30.21 tunnel all traffic between
the subnets by encrypting them according to the IPsec Encapsulated Security
Payload (ESP). The clients  which are
part of the 10.0.0.0/8 subnet hidden behind gateway A (acts as an IKE
Initiator)  whereas some clients belong
to the 40.0.0.0/8 subnet located behind gateway B (acts as an IKE responder).
I configured initiator_tsr in strongswan.conf (at IKE
initiator) end and leftsubnet to 40.0.0.0/8 in ipsec.conf (at IKE responder)
and tested with five IPSec tunnels (using load-tester plugin). What I find from
the output of #ipsec statusall, it does allow restricting the IP address ranges
to only specific IP address (i.e., 40.0.0.0). Please see the below logs. Does IKEv2 Charon keying daemon
(IKE Responder) chooses subset of the traffic selector proposed by the initiator?
As a result, the traffics (UDP) sent by hosts/nodes on  40.0.0.0/8 subnet behind gateway B are not
getting passed through the IPsec tunnel. 
 
Connections:
       host1:  30.30.30.21...%any  IKEv2
       host1:   local:  [srv.strongswan.org] uses pre-shared key authentication
       host1:   remote: uses pre-shared key authentication
       host1:   child:  40.0.0.0/8 === dynamic TUNNEL
Security Associations (5 up, 0 connecting):
       host1[4]:
ESTABLISHED 8 seconds ago,
30.30.30.21[srv.strongswan.org]...30.30.30.11[c3-r1.strongswan.org]
       host1[4]: IKEv2
SPIs: 11d068db7fd9a986_i 5bded75e6a201c60_r*, pre-shared key reauthentication
in 7 hours
       host1[4]: IKE proposal:
AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
       host1{1}:  INSTALLED, TUNNEL, ESP SPIs: ce7dac8b_i
cf8aba7d_o
       host1{1}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0
bytes_o, rekeying in 5 hours
       host1{1}:   40.0.0.0/8 === 10.0.0.1/32 
       host1[5]:
ESTABLISHED 8 seconds ago,
30.30.30.21[srv.strongswan.org]...30.30.30.11[c4-r1.strongswan.org]
       host1[5]: IKEv2
SPIs: 0dcc0f4f567d0ac5_i 9c7eeb321be75a81_r*, pre-shared key reauthentication
in 7 hours
       host1[5]: IKE
proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
       host1{4}:  INSTALLED, TUNNEL, ESP SPIs: c1c26829_i
c7626569_o
       host1{4}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0
bytes_o, rekeying in 5 hours
       host1{4}:   40.0.0.0/8 === 10.0.0.4/32 
       host1[2]:
ESTABLISHED 8 seconds ago,
30.30.30.21[srv.strongswan.org]...30.30.30.11[c1-r1.strongswan.org]
       host1[2]: IKEv2
SPIs: 8ac3036e0c76cf4e_i c56b5c5815d619a6_r*, pre-shared key reauthentication
in 7 hours
       host1[2]: IKE
proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
       host1{3}:  INSTALLED, TUNNEL, ESP SPIs: c225d017_i
c126a6b4_o
       host1{3}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0
bytes_o, rekeying in 5 hours
       host1{3}:   40.0.0.0/8 === 10.0.0.3/32 
       host1[6]:
ESTABLISHED 8 seconds ago,
30.30.30.21[srv.strongswan.org]...30.30.30.11[c5-r1.strongswan.org]
       host1[6]: IKEv2
SPIs: 0205f7ce519a4119_i 3bd37c17bd073ec9_r*, pre-shared key reauthentication
in 7 hours
       host1[6]: IKE proposal:
AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
       host1{2}:  INSTALLED, TUNNEL, ESP SPIs: c7aa2737_i
c890e192_o
       host1{2}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0
bytes_o, rekeying in 5 hours
       host1{2}:   40.0.0.0/8 === 10.0.0.2/32 
       host1[3]:
ESTABLISHED 8 seconds ago,
30.30.30.21[srv.strongswan.org]...30.30.30.11[c2-r1.strongswan.org]
       host1[3]: IKEv2
SPIs: e0a523bdfa742f04_i 49dc42f7aba6388f_r*, pre-shared key reauthentication
in 7 hours
       host1[3]: IKE
proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
       host1{5}:  INSTALLED, TUNNEL, ESP SPIs: c0656cd8_i
c7166b80_o
       host1{5}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0
bytes_o, rekeying in 5 hours
       host1{5}:   40.0.0.0/8 === 10.0.0.5/32
 
Can I  tunnel all
traffic from subnet 40.* host address range (40.0.0.1 - 40.255.255.254) on the
responder's side to subnet 10.* & host address range (10.0.0.1 -
10.255.255.254) on the initiator's side using load-tester plugin (strongswan
5.0.4)?.
 
Regards,
Chinmaya
 

________________________________
 From: Martin Willi <martin at strongswan.org>
To: Chinmaya Dwibedy <ckdwibedy at yahoo.com> 
Cc: "users at lists.strongswan.org" <users at lists.strongswan.org> 
Sent: Monday, August 26, 2013 1:50 PM
Subject: Re: [strongSwan] Issue with net-net scenario with load-tester plugin (using strongSwan 5.0.4)
  

Hi,

> what I see with load-tester is that TSr is by default the remote IP 
> address (as it is configured in strongswan.conf).

Yes.

> I need to send the traffic from host behind Y to host behind X and
> vice-versa via IPsec tunnels established between A and B.

Custom traffic selectors in load-tester are supported since 5.0.2, see
[1]. Use the initiator_tsr option to propose a custom TSr as initiator.

Regards
Martin

[1]http://wiki.strongswan.org/projects/strongswan/wiki/LoadTests#Traffic-selectors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130827/42c2c84c/attachment.html>