Bug #397
Receive TS_UNACCEPTABLE errors
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
History
#1 Updated by Dan Cook about 12 years ago
How do we get this "unblocked"?
#2 Updated by Tobias Brunner about 12 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 12 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 10 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 10 years ago
This is also happening intermittently on restarts on 5.2.1. Any news?
#6 Updated by Noel Kuntze over 8 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.