[Openswan Users] Dead Peer Detection restart causes tunnel to be established, but afterwards cannot ping from either side

Wed Oct 5 21:42:01 EDT 2011

Hi All,

So, I upgraded to 2.6.36 -- and ipsec verify is showing the new
version -- this morning, but unfortunately for me my testing shows the
issues are still there. I kept my original configs, of course.

There's another scenario I should mention, just in case its useful,
whereby the timeouts occur, but replace does not help at all. And I
have to login to a server on the remote side and initiate a ping (or
some connection) across the tunnel (which works instantly), at which
point pings from both ends work instantly.

I used to get this consistently, then coming into work the next week
it just stopped happening after no changes. I did manage to get it
once this morning *before* doing the upgrade, but I've not been able
to get reliable steps to reproduce before, or since.

Here's the log of my tests on 2.6.36 (incase anything has changed, but
it looks about the same to me):

- This is the log output after issuing the restart:

Oct  6 11:54:24 neo pluto[18145]: "CustomerTunnel": deleting connection
Oct  6 11:54:24 neo pluto[18145]: "CustomerTunnel" #6: deleting state
(STATE_QUICK_R2)
Oct  6 11:54:24 neo pluto[18145]: "CustomerTunnel" #5: deleting state
(STATE_MAIN_R3)
Oct  6 11:54:26 neo pluto[19096]: added connection description "CustomerTunnel"
Oct  6 11:54:26 neo pluto[19096]: "CustomerTunnel" #1: initiating Main Mode
Oct  6 11:54:26 neo pluto[19096]: "CustomerTunnel" #1: received Vendor
ID payload [Dead Peer Detection]
Oct  6 11:54:26 neo pluto[19096]: "CustomerTunnel" #1: transition from
state STATE_MAIN_I1 to state STATE_MAIN_I2
Oct  6 11:54:26 neo pluto[19096]: "CustomerTunnel" #1: STATE_MAIN_I2:
sent MI2, expecting MR2
Oct  6 11:54:27 neo pluto[19096]: "CustomerTunnel" #1: transition from
state STATE_MAIN_I2 to state STATE_MAIN_I3
Oct  6 11:54:27 neo pluto[19096]: "CustomerTunnel" #1: STATE_MAIN_I3:
sent MI3, expecting MR3
Oct  6 11:54:27 neo pluto[19096]: "CustomerTunnel" #1: Main mode peer
ID is ID_IPV4_ADDR: 'REMOTE_IP'
Oct  6 11:54:27 neo pluto[19096]: "CustomerTunnel" #1: transition from
state STATE_MAIN_I3 to state STATE_MAIN_I4
Oct  6 11:54:27 neo pluto[19096]: "CustomerTunnel" #1: STATE_MAIN_I4:
ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128
prf=oakley_sha group=modp1536}
Oct  6 11:54:27 neo pluto[19096]: "CustomerTunnel" #1: Dead Peer
Detection (RFC 3706): enabled
Oct  6 11:54:27 neo pluto[19096]: "CustomerTunnel" #4: initiating
Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK {using
isakmp#1 msgid:48157c7b proposal=defaults
pfsgroup=OAKLEY_GROUP_MODP1536}
Oct  6 11:54:27 neo pluto[19096]: "CustomerTunnel" #4: Dead Peer
Detection (RFC 3706): enabled
Oct  6 11:54:27 neo pluto[19096]: "CustomerTunnel" #4: transition from
state STATE_QUICK_I1 to state STATE_QUICK_I2
Oct  6 11:54:27 neo pluto[19096]: "CustomerTunnel" #4: STATE_QUICK_I2:
sent QI2, IPsec SA established tunnel mode {ESP=>0x3bdb8c72
<0x0995aaa9 xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=enabled}
Oct  6 11:54:27 neo pluto[19096]: "CustomerTunnel" #1: ignoring Delete
SA payload: PROTO_IPSEC_ESP SA(0x3bdb8c71) not found (maybe expired)
Oct  6 11:54:27 neo pluto[19096]: "CustomerTunnel" #1: received and
ignored informational message

- And here's the log messages after issuing --replace on the tunnel
(works after this):

Oct  6 11:56:56 neo pluto[19096]: "CustomerTunnel": deleting connection
Oct  6 11:56:56 neo pluto[19096]: "CustomerTunnel" #4: deleting state
(STATE_QUICK_I2)
Oct  6 11:56:56 neo pluto[19096]: "CustomerTunnel" #1: deleting state
(STATE_MAIN_I4)
Oct  6 11:56:56 neo pluto[19096]: added connection description "CustomerTunnel"
Oct  6 11:57:15 neo pluto[19096]: "CustomerTunnel" #5: responding to Main Mode
Oct  6 11:57:15 neo pluto[19096]: "CustomerTunnel" #5: transition from
state STATE_MAIN_R0 to state STATE_MAIN_R1
Oct  6 11:57:15 neo pluto[19096]: "CustomerTunnel" #5: STATE_MAIN_R1:
sent MR1, expecting MI2
Oct  6 11:57:15 neo pluto[19096]: "CustomerTunnel" #5: transition from
state STATE_MAIN_R1 to state STATE_MAIN_R2
Oct  6 11:57:15 neo pluto[19096]: "CustomerTunnel" #5: STATE_MAIN_R2:
sent MR2, expecting MI3
Oct  6 11:57:15 neo pluto[19096]: "CustomerTunnel" #5: Main mode peer
ID is ID_IPV4_ADDR: 'REMOTE_IP'
Oct  6 11:57:15 neo pluto[19096]: "CustomerTunnel" #5: transition from
state STATE_MAIN_R2 to state STATE_MAIN_R3
Oct  6 11:57:15 neo pluto[19096]: "CustomerTunnel" #5: STATE_MAIN_R3:
sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
cipher=aes_128 prf=oakley_sha group=modp1536}
Oct  6 11:57:15 neo pluto[19096]: "CustomerTunnel" #5: Dead Peer
Detection (RFC 3706): enabled
Oct  6 11:57:16 neo pluto[19096]: "CustomerTunnel" #5: the peer
proposed: 172.16.0.0/24:0/0 -> 192.168.1.0/24:0/0
Oct  6 11:57:16 neo pluto[19096]: "CustomerTunnel" #6: responding to
Quick Mode proposal {msgid:6e8c9cab}
Oct  6 11:57:16 neo pluto[19096]: "CustomerTunnel" #6:     us:
172.16.0.0/24===NEO_IP<NEO_IP>[+S=C]---NEO_NEXTHOP
Oct  6 11:57:16 neo pluto[19096]: "CustomerTunnel" #6:   them:
REMOTE_NEXTHOP---REMOTE_IP<REMOTE_IP>[+S=C]===192.168.1.0/24
Oct  6 11:57:16 neo pluto[19096]: "CustomerTunnel" #6: transition from
state STATE_QUICK_R0 to state STATE_QUICK_R1
Oct  6 11:57:16 neo pluto[19096]: "CustomerTunnel" #6: STATE_QUICK_R1:
sent QR1, inbound IPsec SA installed, expecting QI2
Oct  6 11:57:16 neo pluto[19096]: "CustomerTunnel" #6: Dead Peer
Detection (RFC 3706): enabled
Oct  6 11:57:16 neo pluto[19096]: "CustomerTunnel" #6: transition from
state STATE_QUICK_R1 to state STATE_QUICK_R2
Oct  6 11:57:16 neo pluto[19096]: "CustomerTunnel" #6: STATE_QUICK_R2:
IPsec SA established tunnel mode {ESP=>0x3bdb8c73 <0xdaec24fb
xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=none DPD=enabled}

Doesn't seem like a deal breaker, since we can just be sure to
--replace on all tunnels after a restart is issued for any reason. But
it does bug me, because it seems like it _should_ work, and I'm not
sure if there'll be other situations where the same core problem pops
up when we're in full swing production mode.

Please let me know if there's anything more I can do to help fix this.
I would feel much better with having this sorted. Hopefully I'm not
missing anything basic.

Thanks again.

On Thu, Oct 6, 2011 at 2:22 AM, Paul Wouters <paul at xelerance.com> wrote:
> On Thu, 6 Oct 2011, Geekman wrote:
>
>> Thanks so much for the quick response. Seems like getting the Ubuntu
>> maintainers to make a new package available will take some time, but I
>> may pursue that.
>
>> For now, I've stumbled upon the Ubuntu .deb packages on the OpenSwan
>> FTP site. Going to give what looks to be the 64-bit release of 2.6.33
>> a try.
>>
>>
>> ftp://ftp.openswan.org/openswan/binaries/ubuntu/openswan_2.6.33+ocf-1xelerance_amd64.deb
>
> Pick
> ftp://ftp.openswan.org/openswan/binaries/ubuntu/openswan_2.6.36+ocf-1xelerance1_amd64.deb
>
> Paul
>