[strongSwan] Problem observed during traffic selector narrowing

[Patil, Shashidhar 1. (NSN - IN/Bangalore)]

Hi,
Could you please address the following query ?

BR,
Shashidhar

From: users-bounces+shashidhar.1.patil=nsn.com at lists.strongswan.org [mailto:users-bounces+shashidhar.1.patil=nsn.com at lists.strongswan.org] On Behalf Of ext Patil, Shashidhar 1. (NSN - IN/Bangalore)
Sent: Friday, June 07, 2013 5:57 PM
To: users at lists.strongswan.org
Subject: [strongSwan] Problem observed during traffic selector narrowing

Hi,

We are seeing a problem with traffic selector narrowing scenario.

"rightsubnet" on Sec-GW-1 has larger subnet compared to the "leftsubnet" on Sec-GW-2, But
"*protoport" fields on Sec-GW-2  has wider range(any) compared to Sec-GW-1.

With this configuration ESP tunnel establishment fails with "traffic selector unacceptable" .
It works if the "*protoport" on both sides is same.
Also we observed that if both the "ip addres and protocol/port" ranges are wider on sec-GW-1 then it works.

Could you please explain the rationale behind this behavior ?

Configuration on Sec-GW-1

Configuration on Sec-GW-2

conn conn6
  type=tunnel
  leftsubnet=30.30.30.30/32
  rightsubnet=11.0.0.0/16
  left=30.30.30.30
  right=30.30.30.31
  keyexchange=ikev2
  authby=psk
  reauth=no
  ike=aes128-sha1-modp1024,3des-sha1-modp1024!
  ikelifetime=864000
  pfs=no
  esp=3des-sha1!
  keylife=86400
  dpdaction=clear
  dpddelay=10
  leftprotoport=1
  rightprotoport=1
  rekeyfuzz=100%
  rekeymargin=540s


conn conn6
  type=tunnel
  rightsubnet=30.30.30.30/32
  leftsubnet=11.0.1.0/24
  right=30.30.30.30
  left=30.30.30.31
  keyexchange=ikev2
  authby=psk
  reauth=no
  ike=aes128-sha1-modp1024,3des-sha1-modp1024!
  ikelifetime=86400
  pfs=no
  esp=3des-sha1!
  keylife=28800
  dpdaction=clear
  dpddelay=10
  rightprotoport=any
  leftprotoport=any
  rekeyfuzz=100%
  rekeymargin=540s




BR,
Shashidhar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130611/c7a3dced/attachment.html>