[strongSwan] Inacceptable Traffic selectors...
Dan Cook
onedsc at gmail.com
Sun Sep 1 07:06:57 CEST 2013
OK - I can reproduce this very easily. I believe this is either a config
bug or an IKE bug.
Description:
When a new connection is added to the same server and ipsec is "reloaded"
to bring in the new config the newly added connection can not be brought up
(Inacceptable error). If however I just restart ipsec I can bring both
connections up without any issue at all. It is only when a new connection
is added and ipsec is reloaded does the error occur.
Here are the steps to reproduce the bug.
Step 1: Start with a single connection in Transport mode.
conn 1898.moon.0
left=%any
leftid=sun
leftprotoport=6/1898
rightid=moon
right=10.216.63.253
rightprotoport=6/%any
Step 2: Bring up the connection with iperf or some other tool.
ipsec up 0.sun.1898
initiating IKE_SA 0.sun.1898[1] to 10.247.11.151
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
sending packet: from 10.216.63.253[500] to 10.247.11.151[500] (272 bytes)
received packet: from 10.247.11.151[500] to 10.216.63.253[500] (280 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
N(MULT_AUTH) ]
remote host is behind NAT
authentication of 'moon' (myself) with pre-shared key
establishing CHILD_SA 0.sun.1898
generating IKE_AUTH request 1 [ IDi IDr AUTH N(USE_TRANSP) SA TSi TSr
N(MULT_AUTH) N(EAP_ONLY) ]
sending packet: from 10.216.63.253[4500] to 10.247.11.151[4500] (264 bytes)
received packet: from 10.247.11.151[4500] to 10.216.63.253[4500] (248 bytes)
parsed IKE_AUTH response 1 [ IDr AUTH N(USE_TRANSP) SA TSi TSr N(AUTH_LFT) ]
authentication of 'sun' with pre-shared key successful
IKE_SA 0.sun.1898[1] established between
10.216.63.253[moon]...10.247.11.151[sun]
scheduling reauthentication in 9810s
maximum IKE_SA lifetime 10350s
connection '0.sun.1898' established successfully
Step 3: Add another connection to the same server, but on a different port
conn 0.sun.1899
left=%any
leftid=moon
leftprotoport=6/%any
rightid=sun
right=10.247.11.151
rightprotoport=6/1899
Step 4: Reload charon with ipsec reload command to pick up new config
Step 5: Try to bring up new connection and it fails with traffic selector
unacceptable
ipsec up 0.sun.1899
establishing CHILD_SA 0.sun.1899
generating CREATE_CHILD_SA request 3 [ N(USE_TRANSP) SA No TSi TSr ]
sending packet: from 10.216.63.253[4500] to 10.247.11.151[4500] (216 bytes)
received packet: from 10.247.11.151[4500] to 10.216.63.253[4500] (88 bytes)
parsed CREATE_CHILD_SA response 3 [ N(TS_UNACCEPT) ]
received TS_UNACCEPTABLE notify, no CHILD_SA built
failed to establish CHILD_SA, keeping IKE_SA
establishing connection '0.sun.1899' failed
To get both connections to come up simply restart ipsec and both will come
up without an issue.
This is either a configuration bug with reload or an IKE issue not seeing
the new config from reload.
ipsec up 0.sun.1898
initiating IKE_SA 0.sun.1898[1] to 10.247.11.151
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
sending packet: from 10.216.63.253[500] to 10.247.11.151[500] (272 bytes)
received packet: from 10.247.11.151[500] to 10.216.63.253[500] (280 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
N(MULT_AUTH) ]
remote host is behind NAT
authentication of 'moon' (myself) with pre-shared key
establishing CHILD_SA 0.sun.1898
generating IKE_AUTH request 1 [ IDi IDr AUTH N(USE_TRANSP) SA TSi TSr
N(MULT_AUTH) N(EAP_ONLY) ]
sending packet: from 10.216.63.253[4500] to 10.247.11.151[4500] (264 bytes)
received packet: from 10.247.11.151[4500] to 10.216.63.253[4500] (248 bytes)
parsed IKE_AUTH response 1 [ IDr AUTH N(USE_TRANSP) SA TSi TSr N(AUTH_LFT) ]
authentication of 'sun' with pre-shared key successful
IKE_SA 0.sun.1898[1] established between
10.216.63.253[moon]...10.247.11.151[sun]
scheduling reauthentication in 10042s
maximum IKE_SA lifetime 10582s
connection '0.sun.1898' established successfully
ipsec up 0.sun.1899
establishing CHILD_SA 0.sun.1899
generating CREATE_CHILD_SA request 2 [ N(USE_TRANSP) SA No TSi TSr ]
sending packet: from 10.216.63.253[4500] to 10.247.11.151[4500] (216 bytes)
received packet: from 10.247.11.151[4500] to 10.216.63.253[4500] (216 bytes)
parsed CREATE_CHILD_SA response 2 [ N(USE_TRANSP) SA No TSi TSr ]
connection '0.sun.1899' established successfully
Here are my configs:
# basic configuration
config setup
strictcrlpolicy=no
uniqueids = no
charondebug="ike 1, knl 1, cfg 1, chd 1"
conn %default
authby=secret
mobike=no
closeaction=none
dpdaction=clear
dpddelay=30s
dpdtimeout=150s
inactivity=30m
ikelifetime=3h
keyexchange=ikev2
keyingtries=3
lifetime=1h
reauth=yes
rekey=yes
margintime=9m
esp=aes256!
ike=aes256-sha384-prfsha384-ecp384!
forceencaps=yes
type=transport
auto=route
#
conn 0.sun.1898
left=%any
leftid=moon
leftprotoport=6/%any
rightid=sun
right=10.247.11.151
rightprotoport=6/1898
#
# Add this second connection after bringing up the first and reload ipsec
#
#conn 0.sun.1899
# left=%any
# leftid=moon
# leftprotoport=6/%any
# rightid=sun
# right=10.247.11.151
# rightprotoport=6/1899
On Fri, Aug 30, 2013 at 5:37 PM, Dan Cook <onedsc at gmail.com> wrote:
> I am trying to track down a connection issue and I tracked it down to an
> "inacceptable" traffic selector error on a transport connection with the
> route=auto.
> What is very strange is I can bring the connection manually using the
> "ipsec up" command and the connection is established.
>
> I am really stumped on this one...
>
> I am using 5.1.0 in transport mode with the following config.
>
> # basic configuration
> config setup
> strictcrlpolicy=no
> uniqueids = no
>
> Here are my connection defaults:
> # Default connection attributes for ipsec.conf
> #
> conn %default
> authby=secret
> mobike=no
> closeaction=none
> dpdaction=clear
> dpddelay=30s
> dpdtimeout=150s
> inactivity=30m
> ikelifetime=3h
> keyexchange=ikev2
> keyingtries=3
> lifetime=1h
> reauth=yes
> rekey=yes
> margintime=9m
> esp=aes256!
> ike=aes256-sha384-prfsha384-ecp384!
> forceencaps=yes
> type=transport
> auto=route
>
> Here is the connections in question:
> conn 4.6.3000.10-98-108-194.0
> left=%any
> leftid=a27
> leftprotoport=6/3000
> rightid=a26
> right=10.98.108.194
> rightprotoport=6/%any
>
> I should note there are other connections in transport mode to this server
> on port 80 and 3306 and they are connected without issue.
>
> 013-08-30T17:22:03-0700 01[MGR] checkout IKE_SA
> 2013-08-30T17:22:03-0700 01[MGR] IKE_SA 4.17.0.10-98-108-199.11211[6]
> successfully checked out
> 2013-08-30T17:22:03-0700 01[KNL] querying policy
> 10.98.108.199/32[tcp/11211] <http://10.98.108.199/32%5Btcp/11211%5D> ===
> 10.98.108.195/32[tcp] <http://10.98.108.195/32%5Btcp%5D> in (mark
> 0/0x00000000)
> 2013-08-30T17:22:03-0700 01[MGR] checkin IKE_SA
> 4.17.0.10-98-108-199.11211[6]
> 2013-08-30T17:22:03-0700 01[MGR] check-in of IKE_SA successful.
> 2013-08-30T17:22:03-0700 09[NET] received packet: from 10.98.108.194[4500]
> to 10.98.108.195[4500]
> 2013-08-30T17:22:03-0700 09[NET] waiting for data on sockets
> 2013-08-30T17:22:03-0700 16[MGR] checkout IKE_SA by message
> 2013-08-30T17:22:03-0700 16[MGR] IKE_SA 4.6.80.10-98-108-194.0[5]
> successfully checked out
> 2013-08-30T17:22:03-0700 16[NET] received packet: from 10.98.108.194[4500]
> to 10.98.108.195[4500] (248 bytes)
> 2013-08-30T17:22:03-0700 16[ENC] parsed CREATE_CHILD_SA request 99 [
> N(USE_TRANSP) SA No TSi TSr ]
> 2013-08-30T17:22:03-0700 16[CFG] looking for a child config for
> 10.98.108.195/32[tcp/3000] <http://10.98.108.195/32%5Btcp/3000%5D>
> 10.98.108.195/32[tcp/3000] <http://10.98.108.195/32%5Btcp/3000%5D> ===
> 10.98.108.194/32[tcp] <http://10.98.108.194/32%5Btcp%5D>
> 10.98.108.194/32[tcp] <http://10.98.108.194/32%5Btcp%5D>
> 2013-08-30T17:22:03-0700 16[CFG] looking for a child config for
> 10.98.108.195/32[tcp/3000] <http://10.98.108.195/32%5Btcp/3000%5D>
> 10.98.108.195/32[tcp/3000] <http://10.98.108.195/32%5Btcp/3000%5D> ===
> 10.98.108.194/32[tcp] <http://10.98.108.194/32%5Btcp%5D>
> 10.98.108.194/32[tcp] <http://10.98.108.194/32%5Btcp%5D>
> 2013-08-30T17:22:03-0700 16[IKE] traffic selectors
> 10.98.108.195/32[tcp/3000] <http://10.98.108.195/32%5Btcp/3000%5D>
> 10.98.108.195/32[tcp/3000] <http://10.98.108.195/32%5Btcp/3000%5D> ===
> 10.98.108.194/32[tcp] <http://10.98.108.194/32%5Btcp%5D>
> 10.98.108.194/32[tcp] <http://10.98.108.194/32%5Btcp%5D> inacceptable
> 2013-08-30T17:22:03-0700 16[IKE] failed to establish CHILD_SA, keeping
> IKE_SA
> 2013-08-30T17:22:03-0700 16[ENC] generating CREATE_CHILD_SA response 99 [
> N(TS_UNACCEPT) ]
> 2013-08-30T17:22:03-0700 16[NET] sending packet: from 10.98.108.195[4500]
> to 10.98.108.194[4500] (88 bytes)
> 2013-08-30T17:22:03-0700 06[NET] sending packet: from 10.98.108.195[4500]
> to 10.98.108.194[4500]
> 2013-08-30T17:22:03-0700 16[MGR] checkin IKE_SA 4.6.80.10-98-108-194.0[5]
> 2013-08-30T17:22:03-0700 16[MGR] check-in of IKE_SA successful.
>
> Any suggestions as to why the connection will not come up by itself?
>
> Regards,
> Dan Cook
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130831/5005d57e/attachment.html>
More information about the Users
mailing list