[Openswan Users] 2.4.4 mangles SPI?

Thu Nov 30 09:46:48 EST 2006

On 11/29/06, Paul Wouters <paul at xelerance.com> wrote:
>
> On Tue, 28 Nov 2006, Christian Brechbühler wrote:
> > Openswan 2.4.4 sets up a VPN tunnel to a Cisco router OK:
> > 004 "NYC" #58: STATE_QUICK_I2: sent QI2, IPsec SA established
> > {ESP=>0x91af5acc <0xdd787655 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}
>
> > when sending a packet from Openswan through the tunnel, a slightly
> > different SPI is used (tcpdump):
> >
> > 16:34:12.535324 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto:
> ESP
> > (50), length: 136) 66.99.99.99 > 38.111.111.111:
> > ESP(spi=0x91af4878,seq=0x1254001a), length 116
>
> Note that an "IPsec connection" actually consists of two SPI's, one for
> each direction.

Hi Paul,

Thanks again for all the help.

Yes.  Above I see >0x91af5acc and <0xdd787655.  The former (>) *should* be
used for us sending to them, the latter (<) for what we receive from them.

> Nov 28 16:34:04 [pluto] "NYC" #57: ignoring Delete SA payload:
> > PROTO_IPSEC_ESP SA(0x91af4978) not found (maybe expired)
>
> This can happen when Openswan deletes the connection, and the remote sends
> one
> as well, but openswan already deleted it.

I don't think that's happening here -- I just established the connection.
And that modified SPI never existed.

> What could be causing this?
>
> I would have to see the complete (plutodebug=none) log with the spi
> numbers to see what happened.

OK, it's included below, due to its length.  I put the /var/log messages,
output from two tcpdump sessions, and the 3 pings (1 packet each) into
chronological order.  To avoid exposing my partner in Boston and their
partner in NYC, I changed the public IP addresses -- the "99" and "111" are
fake.
The pings 192.168.232.12>10.14.8.X come from separate machine (10.0.0.52,
but that doesn't matter).  Everything else happens on the VPN gateway
machine (eth0 = 10.0.0.1; eth1 = 66.99.99.163).  From ipsec --version, I
get:
Linux Openswan U2.4.4/K2.6.11-gentoo-r5 (netkey)

If you can tell me there was a bug in that version of Openswan or the
kernel, that would be great, and we can upgrade.

Another reason for a changed SPI could be an "IPsec passthrough" router in
> between, messing with the packets.

Both gateways have public IP addresses; there should be no "IPsec
passthrough" router in between.  Negotiation determines NATD=none.  Even if
there was a router messing with the packets, it shouldn't affect the log
below, as tcpdump looks at the ESP packets on the same machine where
Openswan (or Netkey?) generates them.

Two random observations:
The sequence number doesn't start at 1 (which seems to be the norm).
And, for some reason,
    mangled_SPI + (sequence_nr>>16) == true_SPI
In this specific run,
    0xe6bb7df9 + 0x625d == 0xe6bbe056
The general relationship held in earlier attempts, too.  No idea what this
could mean.

/Christian

================================================================================
22:39:33 [sudo] brech : TTY=pts/0 ; PWD=/home/brech ; USER=root ;
COMMAND=/usr/sbin/ipsec auto --verbose --replace NYC
22:39:33 [pluto] "NYC": deleting connection
22:39:33 [pluto] "NYC" #4: deleting state (STATE_QUICK_I2)
22:39:33 [pluto] "NYC" #7: deleting state (STATE_MAIN_I4)
22:39:33 [pluto] added connection description "NYC"

22:39:40 [sudo] brech : TTY=pts/0 ; PWD=/home/brech ; USER=root ;
COMMAND=/usr/sbin/ipsec auto --verbose --up NYC
22:39:40 [pluto] "NYC" #11: initiating Main Mode
22:39:40 [pluto] "NYC" #11: transition from state STATE_MAIN_I1 to state
STATE_MAIN_I2
22:39:40 [pluto] "NYC" #11: STATE_MAIN_I2: sent MI2, expecting MR2
22:39:40 [pluto] "NYC" #11: ignoring unknown Vendor ID payload
[8b58eabd25c502c08a151fb8ee7d8b40]
22:39:40 [pluto] "NYC" #11: I did not send a certificate because I do not
have one.
22:39:40 [pluto] "NYC" #11: transition from state STATE_MAIN_I2 to state
STATE_MAIN_I3
22:39:40 [pluto] "NYC" #11: STATE_MAIN_I3: sent MI3, expecting MR3
22:39:40 [pluto] "NYC" #11: Main mode peer ID is ID_IPV4_ADDR: '
38.111.111.111'
22:39:40 [pluto] "NYC" #11: transition from state STATE_MAIN_I3 to state
STATE_MAIN_I4
22:39:40 [pluto] "NYC" #11: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024}
22:39:40 [pluto] "NYC" #12: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP
{using isakmp#11}
22:39:41 [pluto] "NYC" #12: ignoring informational payload, type
IPSEC_RESPONDER_LIFETIME
22:39:41 [pluto] "NYC" #12: transition from state STATE_QUICK_I1 to state
STATE_QUICK_I2
22:39:41 [pluto] "NYC" #12: STATE_QUICK_I2: sent QI2, IPsec SA established
{ESP=>0xe6bbe056 <0x813ef305 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}
22:40:01 [cron] (root) CMD (test -x /usr/sbin/run-crons &&
/usr/sbin/run-crons )

22:42:48 [sudo] brech : TTY=pts/0 ; PWD=/home/brech ; USER=root ;
COMMAND=/usr/sbin/tcpdump -i eth0 -n -v net 10.14.8/29
22:42:48 [kernel] eth0: Promiscuous mode enabled.
22:43:24 [sudo] brech : TTY=pts/0 ; PWD=/home/brech ; USER=root ;
COMMAND=/usr/sbin/tcpdump -i eth1 -n -v host 38.111.111.111

$        ping -c 1 10.14.8.2
22:43:49.519540 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto:
ICMP (1), length: 84) 192.168.232.12 > 10.14.8.2: ICMP echo request, id
25181, seq 1, length 64
22:43:49.519601 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: ESP
(50), length: 136) 66.99.99.163 > 38.111.111.111:
ESP(spi=0xe6bb7df9,seq=0x625d0001), length 116
22:43:49.547372 IP (tos 0x20, ttl 240, id 50353, offset 0, flags [none],
proto: UDP (17), length: 104) 38.111.111.111.500 > 66.99.99.163.500: isakmp
1.0 msgid : phase 2/others ? inf[E]: [encrypted hash]
22:43:49 [pluto] "NYC" #11: ignoring Delete SA payload: PROTO_IPSEC_ESP
SA(0xe6bb7df9) not found (maybe expired)
22:43:49 [pluto] "NYC" #11: received and ignored informational message

$        ping -s 200 -c 1 10.14.8.2
22:44:21.586879 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto:
ICMP (1), length: 228) 192.168.232.12 > 10.14.8.2: ICMP echo request, id
25437, seq 1, length 208
22:44:21.586946 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: ESP
(50), length: 280) 66.99.99.163 > 38.111.111.111:
ESP(spi=0xe6bb7cf9,seq=0x635d0002), length 260
22:44:21.614666 IP (tos 0x20, ttl 240, id 50520, offset 0, flags [none],
proto: UDP (17), length: 104) 38.111.111.111.500 > 66.99.99.163.500: isakmp
1.0 msgid : phase 2/others ? inf[E]: [encrypted hash]
22:44:21 [pluto] "NYC" #11: ignoring Delete SA payload: PROTO_IPSEC_ESP
SA(0xe6bb7cf9) not found (maybe expired)
22:44:21 [pluto] "NYC" #11: received and ignored informational message

$        ping -s 200 -c 1 10.14.8.6
22:44:46.357347 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto:
ICMP (1), length: 228) 192.168.232.12 > 10.14.8.6: ICMP echo request, id
25693, seq 1, length 208
22:44:46.357432 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: ESP
(50), length: 280) 66.99.99.163 > 38.111.111.111:
ESP(spi=0xe6bb7bf9,seq=0x645d0003), length 260
22:44:46.385324 IP (tos 0x20, ttl 240, id 50656, offset 0, flags [none],
proto: UDP (17), length: 104) 38.111.111.111.500 > 66.99.99.163.500: isakmp
1.0 msgid : phase 2/others ? inf[E]: [encrypted hash]
22:44:46 [pluto] "NYC" #11: ignoring Delete SA payload: PROTO_IPSEC_ESP
SA(0xe6bb7bf9) not found (maybe expired)
22:44:46 [pluto] "NYC" #11: received and ignored informational message
22:46:09 [kernel] device eth0 left promiscuous mode
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20061130/fc8417a3/attachment-0001.html 