Project

General

Profile

Bug #397

Receive TS_UNACCEPTABLE errors

Added by Dan Cook about 7 years ago. Updated over 3 years ago.

Status:
New
Priority:
High
Assignee:
-
Category:
-
Target version:
-
Start date:
01.09.2013
Due date:
Estimated time:
Affected version:
5.1.0
Resolution:

Description

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

Related issues

Blocked by Feature #129: Relations between ike/child/peer_cfgAssigned13.05.2011

History

#1 Updated by Dan Cook about 7 years ago

How do we get this "unblocked"?

#2 Updated by Tobias Brunner about 7 years ago

If you only need to add new connections you can use ipsec update instead of ipsec reload. Because the former does not remove existing CHILD_SA configs it avoids the problem described in #129, which is the reason for this issue here.

#3 Updated by Dan Cook about 7 years ago

Thank you Tobias that works for adding.
However we do need to cleanup old connections as well - leading us to the issue in #129.

Any update on #129? With the addition of transport mode over NAT in 5.x I think this issue will start to come up more often.

My issues my be the same as stated in issue #129, but I think there needs to be a cleaner way to configure the IKE connections (IKE_SA). This could be a different type of connection "conn ike <name>" or an attribute of the connection that says it is ike only with just left/right ids. This could be used by people who need it and the old connections would work also for backward compatibility. They should only be used for IKE and not for IPSEC and the update/reload commands need to be able to work cleanly with IPSEC connections coming and going.

I am willing to help if I can as this is a very high priority for me now.

#4 Updated by piet 36 over 5 years ago

Hi all,

Is anything changed for this problem? I see the same issues with 5.2.2 is that possible.

What would be the preferred method to restart a profile/connection without interfering other "active" connections? We are trying to use ipsec stroke up-nb <profile> and ipsec down <profile> but this seems to be blocking sometimes and gives us the TS_UNACCEPTABLE errors sometimes.

Thanks.

#5 Updated by Nick Huanca over 5 years ago

This is also happening intermittently on restarts on 5.2.1. Any news?

#6 Updated by Noel Kuntze over 3 years ago

It probably happens on restarts, because the loading of the configuration races with the processing of inbound IKE_SA requests. You could try to DROP all packets that the kernel would handle when the configuration is not loaded.

Also available in: Atom PDF