1

I'm trying to create a tunnel using StrongSwan. In order to do this, I'm creating two sh files, one for each gateway router. All I'm doing in the sh files is creating the tunnel, configuring it, and calling "ipsec restart." I then execute each file on its respective router.

The odd thing is that if I execute these sequentially, it works every time. If, however, I execute them at the exact same time, everything gets reconfigured and looks correct, but there is no connectivity over the tunnel. Calling "ipsec restart" again fixes it.

My question is, is it inherently bad to set up each side of the tunnel at the exact same time? Is restarting ipsec at the same time for each end somehow messing up connectivity?

Thanks!

ADDITIONAL INFO:

I looked through the syslogs for a healthy run vs. a failed run, and came up with the following present in the failed run's output:

Dec 13 10:06:32 CORE charon: 14[KNL] unable to add policy 172.28.2.2/32 === 172.102.211.2/32 fwd
Dec 13 10:06:32 CORE charon: 14[IKE] unable to install IPsec policies (SPD) in kernel
Dec 13 10:06:32 CORE charon: 14[ENC] generating IKE_AUTH response 1 [ IDr AUTH N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(TS_UNACCEPT) ]
Dec 13 10:06:32 CORE charon: 07[IKE] CHILD_SA bag-afb-rtr_eth1{1} established with SPIs cc8d2941_i cfe8ad47_o and TS 172.102.211.2/32 === 172.28.2.2/32 
Dec 13 10:06:32 CORE charon: 07[IKE] received AUTH_LIFETIME of 10248s, scheduling reauthentication in 9708s
Dec 13 10:06:32 CORE charon: 07[IKE] peer supports MOBIKE
Dec 13 10:06:32 CORE charon: 14[NET] sending packet: from 172.102.211.2[4500] to 172.28.2.2[4500]
Dec 13 10:06:32 CORE charon: 09[NET] received packet: from 172.102.211.2[4500] to 172.28.2.2[4500]
Dec 13 10:06:32 CORE charon: 09[ENC] parsed IKE_AUTH response 1 [ IDr AUTH N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(TS_UNACCEPT) ]
Dec 13 10:06:32 CORE charon: 09[IKE] authentication of '172.102.211.2' with pre-shared key successful
Dec 13 10:06:32 CORE charon: 09[IKE] IKE_SA crh-432nd-sipr-rtr_eth2[1] established between 172.28.2.2[172.28.2.2]...172.102.211.2[172.102.211.2]
Dec 13 10:06:32 CORE charon: 09[IKE] scheduling reauthentication in 10046s
Dec 13 10:06:32 CORE charon: 09[IKE] maximum IKE_SA lifetime 10586s
Dec 13 10:06:32 CORE charon: 09[IKE] received TS_UNACCEPTABLE notify, no CHILD_SA built
Dec 13 10:06:32 CORE charon: 09[IKE] received AUTH_LIFETIME of 9806s, scheduling reauthentication in 9266s
Dec 13 10:06:32 CORE charon: 09[IKE] peer supports MOBIKE
Dec 13 10:06:32 CORE dhclient: DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 10
Dec 13 10:06:32 CORE charon: 00[DMN] signal of type SIGINT received. Shutting down

This looks like it might indicate why it's not working. Any idea what could cause this?

exxodus7
  • 95
  • 1
  • 8
  • Setting them up at the same time should work fine. Try to provide some corresponding syslog entries otherwise it is impossible to help you. – scai Dec 12 '13 at 08:09
  • Since the syslog stuff is long, I added the bit that I thought might be relevant. Please let me know if that's not enough info! – exxodus7 Dec 12 '13 at 21:36
  • You have to look at the syslog on the other endpoint for the reason for sending TS_UNACCEPTABLE. Must be roughly the same time stamp provided that the system clocks are synchronized. Raising the log level may also help. – scai Dec 13 '13 at 06:25
  • As I'm using a network emulator, the logging for both endpoints is going to the same machine, and unfortunately it's basically impossible to see what is logging what. I ran it again and included more logging. I think the "unable to add policy" bit is generating the "TS_UNACCEPTABLE" reply. – exxodus7 Dec 13 '13 at 15:18
  • Also, how do you turn the logging level up? It seems the StrongSwan website is down, so I'm having trouble finding out how to do it. – exxodus7 Dec 13 '13 at 15:18
  • 1
    Can't you make them log to different files? Otherwise this will be pretty confusing for you. [strongswan.org](https://www.strongswan.org/) works fine here. See the [LoggerConfiguration wiki page](https://wiki.strongswan.org/projects/strongswan/wiki/LoggerConfiguration), the easiest solution is probably by using `ipsec stroke loglevel ike 2` (there are various different subsystems and log levels range from *-1* to *4*). – scai Dec 13 '13 at 16:47

0 Answers0