IPSEC Interop problem with Cisco using multiple SA's
David DeSimone
fox at verio.net
Mon May 8 22:01:03 UTC 2006
I am having a problem establishing peering between my FreeBSD 6.0
gateway and a Cisco device, using IPSEC. The peering works fine if
there is only one subnet behind the remote gateway, but it fails when
there is more than one subnet. I believe the FreeBSD side is failing
to be as strict with the Security Associations being negotiated.
More details below:
========================
Basic info:
Gateway 1: Cisco 7200VXR
IP: 1.2.3.4
Subnets: 10.11.11.0/24
10.22.22.0/24
Gateway 2: FreeBSD 6.0-RELEASE
IP: 4.3.2.1
Subnet: 10.99.99.0/24
========================
Cisco config:
interface GigabitEthernet0/1
ip address 1.2.3.4 255.255.255.0
crypto map IPSEC
crypto map IPSEC local-address GigabitEthernet0/1
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
lifetime 86000
crypto isakmp key <removed> address 4.3.2.1
crypto ipsec transform-set 3DES-MD5 esp-3des esp-md5-hmac
crypto map IPSEC 1 ipsec-isakmp
set peer 4.3.2.1
set transform-set 3DES-MD5
match address remote-lan
ip access-list extended remote-lan
permit ip 10.11.11.0 0.0.0.255 10.99.99.0 0.0.0.255
permit ip 10.22.22.0 0.0.0.255 10.99.99.0 0.0.0.255
========================
ipsec.conf:
spdadd 10.11.11.0/24 10.99.99.0/24 any -P in ipsec \
esp/tunnel/1.2.3.4-4.3.2.1/require;
spdadd 10.22.22.0/24 10.99.99.0/24 any -P in ipsec \
esp/tunnel/1.2.3.4-4.3.2.1/require;
spdadd 10.99.99.0/24 10.11.11.0/24 any -P out ipsec \
esp/tunnel/4.3.2.1-1.2.3.4/require;
spdadd 10.99.99.0/24 10.22.22.0/24 any -P out ipsec \
esp/tunnel/4.3.2.1-1.2.3.4/require;
========================
racoon.conf:
path pre_shared_key "/usr/local/etc/ipsec.keys";
listen
{
isakmp 4.3.2.1;
}
remote 1.2.3.4
{
exchange_mode aggressive,main,base;
my_identifier address 4.3.2.1;
peers_identifier address 1.2.3.4;
verify_identifier off;
proposal_check claim;
proposal
{
encryption_algorithm 3des;
hash_algorithm md5;
authentication_method pre_shared_key;
dh_group 2;
lifetime time 24 hours;
}
}
sainfo address 10.11.11.0/24 any address 10.99.99.0/24 any
{
lifetime time 1 hour;
encryption_algorithm 3des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}
sainfo address 10.22.22.0/24 any address 10.99.99.0/24 any
{
lifetime time 1 hour;
encryption_algorithm 3des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}
sainfo address 10.99.99.0/24 any address 10.11.11.0/24 any
{
lifetime time 1 hour;
encryption_algorithm 3des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}
sainfo address 10.99.99.0/24 any address 10.22.22.0/24 any
{
lifetime time 1 hour;
encryption_algorithm 3des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}
========================
ipsec.keys:
1.2.3.4 <removed>
========================
I believe my configuration is sound, even though it may not match some
of the recipes found on the net.
First test: Inbound traffic
A remote system (10.11.11.88) pings a system (10.99.99.11) behind my
gateway. The result is success. Here is the resulting SA on the Cisco
side:
# show crypto ipsec sa peer 4.3.2.1
interface: GigabitEthernet0/1
Crypto map tag: IPSEC, local addr. 1.2.3.4
protected vrf:
local ident (addr/mask/prot/port): (10.11.11.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.99.99.0/255.255.255.0/0/0)
current_peer: 4.3.2.1:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 173, #pkts encrypt: 173, #pkts digest 173
#pkts decaps: 839, #pkts decrypt: 839, #pkts verify 839
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 101, #recv errors 636
local crypto endpt.: 1.2.3.4, remote crypto endpt.: 4.3.2.1
path mtu 1500, media mtu 1500
current outbound spi: EA6BAC9
inbound esp sas:
spi: 0x307C7433(813462579)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 8531, flow_id: 8169, crypto map: IPSEC
sa timing: remaining key lifetime (k/sec): (4445960/3275)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xEA6BAC9(245807817)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 8532, flow_id: 8170, crypto map: IPSEC
sa timing: remaining key lifetime (k/sec): (4445962/3275)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:
And here is the resulting SA on my side:
# setkey -D
4.3.2.1 1.2.3.4
esp mode=tunnel spi=813462579(0x307c7433) reqid=0(0x00000000)
E: 3des-cbc 7c5e61ce d9c097ab 77724344 51fddf8d 854a8797 d0dffbca
A: hmac-md5 d878b88f d9a90dfd c239ca10 e6705098
seq=0x00000001 replay=4 flags=0x00000000 state=mature
created: May 8 12:23:29 2006 current: May 8 12:24:28 2006
diff: 59(s) hard: 3600(s) soft: 2880(s)
last: May 8 12:23:29 2006 hard: 0(s) soft: 0(s)
current: 136(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 1 hard: 0 soft: 0
sadb_seq=1 pid=10602 refcnt=2
1.2.3.4 4.3.2.1
esp mode=tunnel spi=245807817(0x0ea6bac9) reqid=0(0x00000000)
E: 3des-cbc 963f91b6 a0e56342 ad32f99c 295e3260 a20b211b 1a8b1539
A: hmac-md5 c8ca1452 3413049e e69f93d7 ad7f1490
seq=0x00000001 replay=4 flags=0x00000000 state=mature
created: May 8 12:23:29 2006 current: May 8 12:24:28 2006
diff: 59(s) hard: 3600(s) soft: 2880(s)
last: May 8 12:23:29 2006 hard: 0(s) soft: 0(s)
current: 84(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 1 hard: 0 soft: 0
sadb_seq=0 pid=10602 refcnt=1
Here is a tcpdump showing the packet exchange that occurs:
12:22:44 IP 1.2.3.4.500 > 4.3.2.1.500: isakmp: phase 1 ? ident[E]
12:23:23 IP 1.2.3.4.500 > 4.3.2.1.500: isakmp: phase 1 I ident
12:23:23 IP 4.3.2.1.500 > 1.2.3.4.500: isakmp: phase 1 R ident
12:23:24 IP 1.2.3.4.500 > 4.3.2.1.500: isakmp: phase 1 I ident
12:23:24 IP 4.3.2.1.500 > 1.2.3.4.500: isakmp: phase 1 R ident
12:23:26 IP 1.2.3.4.500 > 4.3.2.1.500: isakmp: phase 1 I ident[E]
12:23:26 IP 4.3.2.1.500 > 1.2.3.4.500: isakmp: phase 1 R ident[E]
12:23:28 IP 1.2.3.4.500 > 4.3.2.1.500: isakmp: phase 2/others I oakley-quick[E]
12:23:28 IP 4.3.2.1.500 > 1.2.3.4.500: isakmp: phase 2/others R oakley-quick[E]
12:23:29 IP 1.2.3.4.500 > 4.3.2.1.500: isakmp: phase 2/others I oakley-quick[E]
12:23:29 IP 1.2.3.4 > 4.3.2.1: ESP(spi=0x0ea6bac9,seq=0x1), length 116
12:23:29 IP 4.3.2.1 > 1.2.3.4: ESP(spi=0x307c7433,seq=0x1), length 116
The IKE negotiation succeeded, and the SPI's match for the inbound and
outbound encrypted traffic.
Second test: Inbound traffic
A remote system (10.22.22.88) located on a different remote subnet
behind the same gateway as before, pings a system (10.99.99.11) behind
my gateway. The result is failure.
Again, here is the resulting SA set on the Cisco side:
# show crypto ipsec sa peer 4.3.2.1
interface: GigabitEthernet0/1
Crypto map tag: IPSEC, local addr. 1.2.3.4
protected vrf:
local ident (addr/mask/prot/port): (10.11.11.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.99.99.0/255.255.255.0/0/0)
current_peer: 4.3.2.1:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 173, #pkts encrypt: 173, #pkts digest 173
#pkts decaps: 839, #pkts decrypt: 839, #pkts verify 839
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 101, #recv errors 636
local crypto endpt.: 1.2.3.4, remote crypto endpt.: 4.3.2.1
path mtu 1500, media mtu 1500
current outbound spi: EA6BAC9
inbound esp sas:
spi: 0x307C7433(813462579)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 8531, flow_id: 8169, crypto map: IPSEC
sa timing: remaining key lifetime (k/sec): (4445960/3275)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xEA6BAC9(245807817)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 8532, flow_id: 8170, crypto map: IPSEC
sa timing: remaining key lifetime (k/sec): (4445962/3275)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:
protected vrf:
local ident (addr/mask/prot/port): (10.22.22.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.99.99.0/255.255.255.0/0/0)
current_peer: 4.3.2.1:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 188, #pkts encrypt: 188, #pkts digest 188
#pkts decaps: 98, #pkts decrypt: 98, #pkts verify 98
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 3, #recv errors 47
local crypto endpt.: 1.2.3.4, remote crypto endpt.: 4.3.2.1
path mtu 1500, media mtu 1500
current outbound spi: 625C4B6
inbound esp sas:
spi: 0xC7C085BD(3351283133)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 8535, flow_id: 8173, crypto map: IPSEC
sa timing: remaining key lifetime (k/sec): (4554069/3414)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x625C4B6(103138486)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 8536, flow_id: 8174, crypto map: IPSEC
sa timing: remaining key lifetime (k/sec): (4554066/3414)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:
And here is the SA list on my side, showing that two pairs of SA's have
been negotiated:
# setkey -D
4.3.2.1 1.2.3.4
esp mode=tunnel spi=3351283133(0xc7c085bd) reqid=0(0x00000000)
E: 3des-cbc 3323af44 bb35454d 452d6e45 781ff741 5ddea450 bdc4e6f8
A: hmac-md5 f5ebb9cd 4bd9c7ef 8ecdb8fa 95dc21d1
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: May 8 12:25:48 2006 current: May 8 12:28:06 2006
diff: 138(s) hard: 3600(s) soft: 2880(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=3 pid=10609 refcnt=1
4.3.2.1 1.2.3.4
esp mode=tunnel spi=813462579(0x307c7433) reqid=0(0x00000000)
E: 3des-cbc 7c5e61ce d9c097ab 77724344 51fddf8d 854a8797 d0dffbca
A: hmac-md5 d878b88f d9a90dfd c239ca10 e6705098
seq=0x00000015 replay=4 flags=0x00000000 state=mature
created: May 8 12:23:29 2006 current: May 8 12:28:06 2006
diff: 277(s) hard: 3600(s) soft: 2880(s)
last: May 8 12:27:05 2006 hard: 0(s) soft: 0(s)
current: 2856(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 21 hard: 0 soft: 0
sadb_seq=2 pid=10609 refcnt=3
1.2.3.4 4.3.2.1
esp mode=tunnel spi=103138486(0x0625c4b6) reqid=0(0x00000000)
E: 3des-cbc 490cd807 2d8efeb2 9bc39e74 176f791b 63d1f8d1 3451442c
A: hmac-md5 808f7344 bfc44b18 09a8a61d 97c0aa98
seq=0x00000014 replay=4 flags=0x00000000 state=mature
created: May 8 12:25:48 2006 current: May 8 12:28:06 2006
diff: 138(s) hard: 3600(s) soft: 2880(s)
last: May 8 12:27:05 2006 hard: 0(s) soft: 0(s)
current: 1680(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 20 hard: 0 soft: 0
sadb_seq=1 pid=10609 refcnt=1
1.2.3.4 4.3.2.1
esp mode=tunnel spi=245807817(0x0ea6bac9) reqid=0(0x00000000)
E: 3des-cbc 963f91b6 a0e56342 ad32f99c 295e3260 a20b211b 1a8b1539
A: hmac-md5 c8ca1452 3413049e e69f93d7 ad7f1490
seq=0x00000001 replay=4 flags=0x00000000 state=mature
created: May 8 12:23:29 2006 current: May 8 12:28:06 2006
diff: 277(s) hard: 3600(s) soft: 2880(s)
last: May 8 12:23:29 2006 hard: 0(s) soft: 0(s)
current: 84(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 1 hard: 0 soft: 0
sadb_seq=0 pid=10609 refcnt=1
The packet trace shows part of the problem:
12:25:47 IP 1.2.3.4.500 > 4.3.2.1.500: isakmp: phase 2/others I oakley-quick[E]
12:25:47 IP 4.3.2.1.500 > 1.2.3.4.500: isakmp: phase 2/others R oakley-quick[E]
12:25:48 IP 1.2.3.4.500 > 4.3.2.1.500: isakmp: phase 2/others I oakley-quick[E]
12:25:49 IP 1.2.3.4 > 4.3.2.1: ESP(spi=0x0625c4b6,seq=0x1), length 116
12:25:49 IP 4.3.2.1 > 1.2.3.4: ESP(spi=0x307c7433,seq=0x2), length 116
12:25:50 IP 1.2.3.4 > 4.3.2.1: ESP(spi=0x0625c4b6,seq=0x2), length 116
12:25:50 IP 4.3.2.1 > 1.2.3.4: ESP(spi=0x307c7433,seq=0x3), length 116
12:25:51 IP 1.2.3.4 > 4.3.2.1: ESP(spi=0x0625c4b6,seq=0x3), length 116
12:25:51 IP 4.3.2.1 > 1.2.3.4: ESP(spi=0x307c7433,seq=0x4), length 116
As you can see, the Cisco gateway is sending traffic using the newly-
negotiated SPI, however the FreeBSD gateway is responding using the
previously negotiated SPI for the other subnet, 10.11.11.0/24. The
Cisco gateway (correctly, in my opinion) rejects this traffic:
IPSEC(epa_des_crypt): decrypted packet failed SA identity check
IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Third test: Outbound traffic
A local system (10.99.99.11) tries to ping two systems (10.11.11.88 and
10.22.22.61) behind the remote gateway. The first ping succeeds. The
second fails.
I will leave out the status output as shown above, as it is getting
redundant.
For the first ping, the SA is established correctly as above. However,
when the second ping is attempted, the FreeBSD box DOES NOT attempt to
negotiate a second SA for the second subnet. Instead, it begins
generating ESP traffic immediately, using the existing SPI that was
negotiated for the first subnet. There is no attempt to contact the
racoon daemon in order to attempt the negotiation.
Summary: It appears to me that FreeBSD is only paying attention to one
SPI per gateway, rather than one SPI per subnet as IPSEC standards would
suggest. It seems that, once the FreeBSD gateway determines which
destination gateway is going to be used for traffic, it does not search
the list of SPI's negotiated, nor does it pay attention to which SPD was
matched for the outbound traffic. It simply picks the first (or last)
SPI that was negotiated, and uses that.
This leads to an interoperability problem when I attempt to peer with
remote systems managed by other vendors.
Is there anyone I can talk to that can help me understand how this
problem comes about, and assist me in developing a fix? I am willing to
bang on kernel code if necessary, but I could use some help in
understanding the source and how the ipsec modules interrelate to the
rest of the networking code.
Thanks for any assistance you can give.
--
David DeSimone == Network Admin == fox at verio.net
"It took me fifteen years to discover that I had no
talent for writing, but I couldn't give it up because
by that time I was too famous. -- Robert Benchley
More information about the freebsd-net
mailing list