[Openswan Users] Duplicate ESP SAs being created
Mike Horn
lists at caddisconsulting.com
Thu Feb 1 17:47:13 EST 2007
Hi,
I have a situation where I am seeing duplicate ESP SAs getting created
between to Openswan devices. Both devices are using Openswan 2.4.6 with
NETKEY on a 2.6.19 kernel. In my configuration there is only one connection
statement between peers 172.3.3.5 and 172.4.4.10.
The issue occurs if the tunnel connection is set auto=start on both sides.
Once the ipsec process is started on both sides the peers come up and
negotiate an ISAKMP SA, then they negotiate an ESP SA, then a few seconds
later they negotiate another ESP SA. Based on the byte counters for the SA
it appears that the second set of negotiated SAs are used. Is this expected
behavior?
If I set one end of the tunnel connection to "auto=add" and leave the other
to "auto=start" then I only get one pair of SA as expected.
< LOG MESSAGES >
Feb 1 17:30:30 uml-5 pluto[6632]: packet from 172.4.4.10:500: ignoring
unknown Vendor ID payload [4f454e7c454d716b5f4d6c67]
Feb 1 17:30:30 uml-5 pluto[6632]: packet from 172.4.4.10:500: received
Vendor ID payload [Dead Peer Detection]
Feb 1 17:30:30 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #2: responding
to Main Mode
Feb 1 17:30:30 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #2: transition
from state STATE_MAIN_R0 to state STATE_MAIN_R1
Feb 1 17:30:30 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #2:
STATE_MAIN_R1: sent MR1, expecting MI2
Feb 1 17:30:30 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #2: transition
from state STATE_MAIN_R1 to state STATE_MAIN_R2
Feb 1 17:30:30 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #2:
STATE_MAIN_R2: sent MR2, expecting MI3
Feb 1 17:30:30 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #2: Main mode
peer ID is ID_IPV4_ADDR: '172.4.4.10'
Feb 1 17:30:30 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #2: I did not
send a certificate because I do not have one.
Feb 1 17:30:30 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #2: transition
from state STATE_MAIN_R2 to state STATE_MAIN_R3
Feb 1 17:30:30 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #2:
STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1536}
Feb 1 17:30:30 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #3: responding
to Quick Mode {msgid:63ba348f}
Feb 1 17:30:30 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #3: transition
from state STATE_QUICK_R0 to state STATE_QUICK_R1
Feb 1 17:30:30 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #3:
STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Feb 1 17:30:30 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #3: transition
from state STATE_QUICK_R1 to state STATE_QUICK_R2
Feb 1 17:30:30 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #3:
STATE_QUICK_R2: IPsec SA established {ESP=>0x53463f47 <0x5cc8fba5
xfrm=AES_256-HMAC_SHA1 NATD=none DPD=none}
*** First SA negotiation complete ***
Feb 1 17:30:41 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #1: ignoring
unknown Vendor ID payload [4f454e7c454d716b5f4d6c67]
Feb 1 17:30:41 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #1: received
Vendor ID payload [Dead Peer Detection]
Feb 1 17:30:41 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #1: transition
from state STATE_MAIN_I1 to state STATE_MAIN_I2
Feb 1 17:30:41 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #1:
STATE_MAIN_I2: sent MI2, expecting MR2
Feb 1 17:30:41 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #1: I did not
send a certificate because I do not have one.
Feb 1 17:30:41 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #1: transition
from state STATE_MAIN_I2 to state STATE_MAIN_I3
Feb 1 17:30:41 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #1:
STATE_MAIN_I3: sent MI3, expecting MR3
Feb 1 17:30:41 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #1: Main mode
peer ID is ID_IPV4_ADDR: '172.4.4.10'
Feb 1 17:30:41 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #1: transition
from state STATE_MAIN_I3 to state STATE_MAIN_I4
Feb 1 17:30:41 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #1:
STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1536}
Feb 1 17:30:41 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #4: initiating
Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#1}
Feb 1 17:30:41 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #4: transition
from state STATE_QUICK_I1 to state STATE_QUICK_I2
Feb 1 17:30:41 uml-5 pluto[6632]: "peer-172.4.4.10-tunnel-1" #4:
STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x98c80ea0 <0xa23ead62
xfrm=AES_256-HMAC_SHA1 NATD=none DPD=none}
Now if I look at the output from "setkey -D" I see a total of 4 SA (2
inbound, 2 outbound), but there should only be 2 SAs.
[root at uml-10 tunnels]# setkey -D
172.4.4.10 172.3.3.5
esp mode=tunnel spi=2722016610(0xa23ead62) reqid=16385(0x00004001)
E: aes-cbc ebc71563 40e71778 c5d925f8 04b09ea5 f10057f2 a3ea809e
c365d1fa f09a4d66
A: hmac-sha1 c9640009 ce2d6ede d2c24c6e 56152f43 08f65ffc
seq=0x00000000 replay=32 flags=0x00000000 state=mature
created: Feb 1 17:30:41 2007 current: Feb 1 17:36:50 2007
diff: 369(s) hard: 0(s) soft: 0(s)
last: Feb 1 17:32:10 2007 hard: 0(s) soft: 0(s)
current: 912(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 6 hard: 0 soft: 0
sadb_seq=3 pid=10719 refcnt=0
172.3.3.5 172.4.4.10
esp mode=tunnel spi=2563247776(0x98c80ea0) reqid=16385(0x00004001)
E: aes-cbc eced091e a4656ff4 cc605fc2 7d3f2abd 7f99c3cd 797b5f55
cd7b72e7 6187ef70
A: hmac-sha1 8322b286 1dc0fc52 51602679 aadf2fe8 9231cd36
seq=0x00000000 replay=32 flags=0x00000000 state=mature
created: Feb 1 17:30:41 2007 current: Feb 1 17:36:50 2007
diff: 369(s) hard: 0(s) soft: 0(s)
last: Feb 1 17:32:10 2007 hard: 0(s) soft: 0(s)
current: 504(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 6 hard: 0 soft: 0
sadb_seq=2 pid=10719 refcnt=0
172.4.4.10 172.3.3.5
esp mode=tunnel spi=1556675493(0x5cc8fba5) reqid=16385(0x00004001)
E: aes-cbc c6a4d1c9 869f7389 09314d91 00bb8161 d065616e 55bf92ea
5063eabd 9d5babde
A: hmac-sha1 459a972c dd36d5f8 21c7c229 67a20c71 3b64d037
seq=0x00000000 replay=32 flags=0x00000000 state=mature
created: Feb 1 17:30:30 2007 current: Feb 1 17:36:50 2007
diff: 380(s) hard: 0(s) soft: 0(s)
last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=1 pid=10719 refcnt=0
172.3.3.5 172.4.4.10
esp mode=tunnel spi=1397112647(0x53463f47) reqid=16385(0x00004001)
E: aes-cbc c52ece00 785e8770 2c2b05b4 9baa9417 89c5b067 f4967596
7f425674 590c2c50
A: hmac-sha1 f71fe5a6 f1c3791d a1f2b4d6 8d906d03 b104c83b
seq=0x00000000 replay=32 flags=0x00000000 state=mature
created: Feb 1 17:30:30 2007 current: Feb 1 17:36:50 2007
diff: 380(s) hard: 0(s) soft: 0(s)
last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=0 pid=10719 refcnt=0
[root at uml-10 tunnels]#
< connection definition on peer 172.3.3.5 >
conn peer-172.4.4.10-tunnel-1
left=172.3.3.5
leftsubnet=192.168.40.0/24
right=172.4.4.10
rightsubnet=192.168.100.0/24
authby=secret
ike="3des-sha1"
ikelifetime=3600s
esp="aes256-sha1"
type=tunnel
keylife=1800s
rekeyfuzz=0%
rekeymargin=10s
auto=start
< connection definition on peer 172.4.4.10 >
conn peer-172.3.3.5-tunnel-1
left=172.4.4.10
leftsubnet=192.168.100.0/24
right=172.3.3.5
rightsubnet=192.168.40.0/24
authby=secret
ike="3des-sha1"
ikelifetime=3600s
esp="aes256-sha1"
type=tunnel
keylife=1800s
auto=start
Let me know if there is additional information that I should provide.
-mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20070201/285ef29e/attachment-0001.html
More information about the Users
mailing list