On 11/29/06, <b class="gmail_sendername">Paul Wouters</b> <<a href="mailto:paul@xelerance.com">paul@xelerance.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, 28 Nov 2006, Christian Brechbühler wrote:<br>> Openswan 2.4.4 sets up a VPN tunnel to a Cisco router OK:<br>> 004 "NYC" #58: STATE_QUICK_I2: sent QI2, IPsec SA established<br>> {ESP=>0x91af5acc <0xdd787655 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}
<br><br>> when sending a packet from Openswan through the tunnel, a slightly<br>> different SPI is used (tcpdump):<br>><br>> 16:34:12.535324 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: ESP<br>> (50), length: 136)
<a href="http://66.99.99.99"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 66.99.99.99</a> > <a href="http://38.111.111.111"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 38.111.111.111</a>:<br>> ESP(spi=0x91af4878,seq=0x1254001a), length 116<br><br>Note that an "IPsec connection" actually consists of two SPI's, one for
<br>each direction.</blockquote><div><br>
Hi Paul,<br>
<br>
Thanks again for all the help.<br>
<br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Nov 28 16:34:04 [pluto] "NYC" #57: ignoring Delete SA payload:<br>
> PROTO_IPSEC_ESP SA(0x91af4978) not found (maybe expired)<br><br>This can happen when Openswan deletes the connection, and the remote sends one<br>as well, but openswan already deleted it.</blockquote><div><br>
I don't think that's happening here -- I just established the connection. And that modified SPI never existed.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> What could be causing this?<br><br>I would have to see the complete (plutodebug=none) log with the spi
<br>numbers to see what happened.</blockquote><div><br>
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.<br>
The pings <a href="http://192.168.232.12"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.232.12</a>>10.14.8.X come from separate machine
(<a href="http://10.0.0.52"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 10.0.0.52</a>, but that doesn't matter). Everything else happens on
the VPN gateway machine (eth0 = <a href="http://10.0.0.1"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 10.0.0.1</a>; eth1 = <a href="http://66.99.99.163"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 66.99.99.163</a>).
From ipsec --version, I get:<br>
Linux Openswan U2.4.4/K2.6.11-gentoo-r5 (netkey)<br>
<br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Another reason for a changed SPI could be an "IPsec passthrough" router in
<br>between, messing with the packets.</blockquote></div><br>
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.<br>
<br>
Two random observations:<br>
The sequence number doesn't start at 1 (which seems to be the norm).<br>
And, for some reason,<br>
mangled_SPI + (sequence_nr>>16) == true_SPI<br>
In this specific run,<br>
0xe6bb7df9 + 0x625d == 0xe6bbe056<br>
The general relationship held in earlier attempts, too. No idea what this could mean.<br>
<br>
/Christian<br>
<br>
================================================================================<br>
22:39:33 [sudo] brech : TTY=pts/0 ; PWD=/home/brech ; USER=root ; COMMAND=/usr/sbin/ipsec auto --verbose --replace NYC<br>
22:39:33 [pluto] "NYC": deleting connection<br>
22:39:33 [pluto] "NYC" #4: deleting state (STATE_QUICK_I2)<br>
22:39:33 [pluto] "NYC" #7: deleting state (STATE_MAIN_I4)<br>
22:39:33 [pluto] added connection description "NYC"<br>
<br>
22:39:40 [sudo] brech : TTY=pts/0 ; PWD=/home/brech ; USER=root ; COMMAND=/usr/sbin/ipsec auto --verbose --up NYC<br>
22:39:40 [pluto] "NYC" #11: initiating Main Mode<br>
22:39:40 [pluto] "NYC" #11: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2<br>
22:39:40 [pluto] "NYC" #11: STATE_MAIN_I2: sent MI2, expecting MR2<br>
22:39:40 [pluto] "NYC" #11: ignoring unknown Vendor ID payload [8b58eabd25c502c08a151fb8ee7d8b40]<br>
22:39:40 [pluto] "NYC" #11: I did not send a certificate because I do not have one.<br>
22:39:40 [pluto] "NYC" #11: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3<br>
22:39:40 [pluto] "NYC" #11: STATE_MAIN_I3: sent MI3, expecting MR3<br>
22:39:40 [pluto] "NYC" #11: Main mode peer ID is ID_IPV4_ADDR: '<a href="http://38.111.111.111"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 38.111.111.111</a>'<br>
22:39:40 [pluto] "NYC" #11: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4<br>
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}<br>
22:39:40 [pluto] "NYC" #12: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#11}<br>
22:39:41 [pluto] "NYC" #12: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME<br>
22:39:41 [pluto] "NYC" #12: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2<br>
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}<br>
22:40:01 [cron] (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )<br>
<br>
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<br>
22:42:48 [kernel] eth0: Promiscuous mode enabled.<br>
22:43:24 [sudo] brech : TTY=pts/0 ; PWD=/home/brech ; USER=root ; COMMAND=/usr/sbin/tcpdump -i eth1 -n -v host <a href="http://38.111.111.111"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 38.111.111.111</a><br>
<br>
$ ping -c 1 <a href="http://10.14.8.2"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 10.14.8.2</a><br>
22:43:49.519540 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: ICMP (1), length: 84) <a href="http://192.168.232.12"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.232.12</a> > <a href="http://10.14.8.2"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 10.14.8.2</a>: ICMP echo
request, id 25181, seq 1, length 64<br>
22:43:49.519601 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: ESP (50), length: 136) <a href="http://66.99.99.163"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 66.99.99.163</a> > <a href="http://38.111.111.111"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 38.111.111.111</a>:
ESP(spi=0xe6bb7df9,seq=0x625d0001), length 116<br>
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]<br>
22:43:49 [pluto] "NYC" #11: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0xe6bb7df9) not found (maybe expired)<br>
22:43:49 [pluto] "NYC" #11: received and ignored informational message<br>
<br>
$ ping -s 200 -c 1 <a href="http://10.14.8.2"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 10.14.8.2</a><br>
22:44:21.586879 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: ICMP (1), length: 228) <a href="http://192.168.232.12"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.232.12</a> > <a href="http://10.14.8.2"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 10.14.8.2</a>: ICMP echo
request, id 25437, seq 1, length 208<br>
22:44:21.586946 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: ESP (50), length: 280) <a href="http://66.99.99.163"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 66.99.99.163</a> > <a href="http://38.111.111.111"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 38.111.111.111</a>:
ESP(spi=0xe6bb7cf9,seq=0x635d0002), length 260<br>
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]<br>
22:44:21 [pluto] "NYC" #11: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0xe6bb7cf9) not found (maybe expired)<br>
22:44:21 [pluto] "NYC" #11: received and ignored informational message<br>
<br>
$ ping -s 200 -c 1 <a href="http://10.14.8.6"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 10.14.8.6</a><br>
22:44:46.357347 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: ICMP (1), length: 228) <a href="http://192.168.232.12"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 192.168.232.12</a> > <a href="http://10.14.8.6"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 10.14.8.6</a>: ICMP echo
request, id 25693, seq 1, length 208<br>
22:44:46.357432 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: ESP (50), length: 280) <a href="http://66.99.99.163"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 66.99.99.163</a> > <a href="http://38.111.111.111"><font color="red"><b>MailScanner warning: numerical links are often malicious:</b></font> 38.111.111.111</a>:
ESP(spi=0xe6bb7bf9,seq=0x645d0003), length 260<br>
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]<br>
22:44:46 [pluto] "NYC" #11: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0xe6bb7bf9) not found (maybe expired)<br>
22:44:46 [pluto] "NYC" #11: received and ignored informational message<br>
22:46:09 [kernel] device eth0 left promiscuous mode<br>
<br>