[Swan-dev] IKEv1: Remove all IPsec SA's of a connection when newest SA is removedrefs/heads/master
Lennart Sorensen
lsorense at csclub.uwaterloo.ca
Wed Aug 26 16:48:11 EEST 2015
On Wed, Aug 26, 2015 at 02:33:32AM -0400, D. Hugh Redelmeier wrote:
> | From: Lennart Sorensen <lsorense at csclub.uwaterloo.ca>
>
> | On Tue, Aug 25, 2015 at 01:17:06PM -0400, D. Hugh Redelmeier wrote:
>
> | > | We are not talking about a second
> | > | tunnel here (from what I understand)
> | >
> | > I think that we are. But the tunnels have essentially identical
> | > policies.
> |
> | No we are not.
>
> In what sense are we not talking about two tunnels?
>
> At least from our end it must look like two tunnels.
>
> | Cisco occationally sends two SAs for the same connection
> | for some reason, but only uses the most recent one as far as I understood
> | the problem.
>
> What does "uses" mean? Will it work inbound? Will it work outbound,
> once there is no longer the other one?
>
> If it won't work for inbound, then surely a delete notification would
> have been generated. That notification hasn't happened since we still
> have the SA bundle pair.
>
> If it will work for inbound but not outbound, that seems kind of odd.
>
> How does this come up? Is this a race condition in negotiation?
>
> Maybe I'm leaping to conclusions based on a very partial problem
> description.
Here is the setup from our internal bug report (RC is ruggedcom, which
is our device running linux with openswan/libreswan (depending on the
release of course))
-> Under certain test scenario, the IPSEC connection on the RC device is being
placed to the state of "perspective erouted" up on receiving Delete IPSEC SA
and ISAKMP SA for an old/unknown SA from a Cisco peer while the peer have
already negotiated and established a new SA (IPSEC and ISAKMP) between them. []
Test Topology:
===============
192.168.10.x/24
192.168.30.1--[RX1500].1-------[Switch]-------.2[Cisco]fe0/1--192.168.20.1
Test Description:
=================
1. Setup a network as shown in the above figure.
Config from the Cisco device:
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 5
lifetime 28800
crypto isakmp key 6 ruggedcom address 192.168.10.1 255.255.255.0 no-xauth
crypto isakmp keepalive 30
!
crypto ipsec transform-set myset esp-3des esp-md5-hmac
!
crypto map mymap 10 ipsec-isakmp
set peer 192.168.10.1
set transform-set myset
set pfs group5
match address 100
!
interface FastEthernet0/0
ip address 192.168.10.2 255.255.255.0
duplex auto
speed auto
crypto map mymap
!
interface FastEthernet0/1
ip address 192.168.20.1 255.255.255.0
duplex auto
speed auto
!
ip forward-protocol nd
ip route 192.168.30.0 255.255.255.0 192.168.10.1
no ip http server
no ip http secure-server
!
access-list 100 permit ip 192.168.20.0 0.0.0.255 192.168.30.0 0.0.0.255
IPSEC Config from the RC device:
tunnel
ipsec
enabled
no nat-traversal
no keep-alive
preshared-key 192.168.10.2 192.168.10.1
key $4$05sxb9ZekzsdhYYI0d4IDw==
!
connection Test
startup add
authenticate secret
connection-type tunnel
dead-peer-detect timeout 60
dead-peer-detect action clear
pfs yes
no l2tp
monitor-interface switch.0010
ike algorithm 3des md5 any
!
esp algorithm 3des md5
!
left
public-ip type address
public-ip value 192.168.10.1
subnet 192.168.30.0/24
!
!
right
public-ip type address
public-ip value 192.168.10.2
subnet 192.168.20.0/24
!
2. Send traffic from the cisco box to initiate the connection
ping 192.168.30.1 source fastethernet 0/1
3. Verify the ISAKMP and IPSEC SA are established and Active on both devices
RC#show tunnel ipsec status
000 "Test":
192.168.30.0/24===192.168.10.1<192.168.10.1>[+S=C]...192.168.10.2<192.168.10.2>[+S=C]===192.168.20.0/24;
erouted; eroute owner: #2
000 "Test": myip=unset; hisip=unset; myup=ipsec _updown --route
yes; hisup=ipsec _updown --route yes;
000 #2: "Test":500 STATE_QUICK_R2 (IPsec SA established);
EVENT_SA_REPLACE in 3325s; newest IPSEC; eroute owner; isakmp#1; idle;
import:not set
000 #2: "Test" esp.d86c2b40 at 192.168.10.2 esp.ba8ab00d at 192.168.10.1
tun.0 at 192.168.10.2 tun.0 at 192.168.10.1 ref=0 refhim=4294901761
000 #1: "Test":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established);
EVENT_SA_REPLACE in 3325s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle;
Cisco Router#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
192.168.10.1 192.168.10.2 QM_IDLE 1076 ACTIVE
4. Disconnect the link between RX1500 and switch
5. Start ICMP traffci from the Cisco device
ping 192.168.30.1 source fastethernet 0/1 repeat 10
6. Verify that the ISAKMP SA is set to "delete" in the Cisco device
7. Before the ISAKMP SA is completely being purged from the Cisco device,
initiate ICMP traffic flow from the Cisco device.
ping 192.168.30.1 source fastethernet 0/1
8. Verify that a new ISAKMP SA is being created while the old ISAKMP sa is
still waiting for the purge timer to expire before it is being deleted from the
ISAKMP
association table.
Cisco Router#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
192.168.10.1 192.168.10.2 MM_NO_STATE 0 ACTIVE
192.168.10.1 192.168.10.2 MM_NO_STATE 1076 ACTIVE (deleted)
9. Reconnect the cable and verify that the ISAKMP SA and IPSEC SA are being
re-initiated by the Cisco device.
Router#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
192.168.10.1 192.168.10.2 QM_IDLE 1077 ACTIVE
10. Now the RC device has two set of IPSEC SA and ISAKMP SA establishment. One
for the old session and one for the new session.
11. Among these two sessions, one session is marked as "Newest"
12. Once the purge timer expire and the old ISAKMP session is removed from the
Cisco device, it sends ISAKMP SA and IPSEC SA delete message to the RC device
in order to delete the old session.
13.Sometime after receiving these messages from the Cisco device, ROX II seems
to be rejecting them and put the tunnel in "perspective erouted" while the
newest IPSEC SA and ISAKMP SA are still in active and established states.
[Fail]
NOTE: The above noted behavior does not happen every time. Sometime the
tunnel will remain in erouted state even after rejecting the IPSEC SA and
ISAKMP SA delete messages from the Cisco device.
RC# tail -f /var/log/auth.log
Aug 5 14:50:13 ruggedcom pluto[8239]: "Test" #3: ignoring Delete SA payload:
PROTO_IPSEC_ESP SA(0xbd111c17) not found (our SPI - bogus implementation)
Aug 5 14:50:13 ruggedcom pluto[8239]: "Test" #3: received and ignored
informational message
Aug 5 14:50:18 ruggedcom pluto[8239]: "Test" #3: received Delete
SA(0x29ddaa5d) payload: deleting IPSEC State #5
Aug 5 14:50:18 ruggedcom pluto[8239]: "Test" #3: received and ignored
informational message
RC# Show tunnel ipsec status
000 "Test":
192.168.30.0/24===192.168.10.1<192.168.10.1>[+S=C]...192.168.10.2<192.168.10.2>[+S=C]===192.168.20.0/24;
prospective erouted; eroute owner: #0
000 #4: "Test":500 STATE_QUICK_R2 (IPsec SA established);
EVENT_SA_REPLACE in 3143s; isakmp#3; idle; import:not set
000 #4: "Test" esp.a405e7fb at 192.168.10.2 esp.d35ec5e5 at 192.168.10.1
tun.0 at 192.168.10.2 tun.0 at 192.168.10.1 ref=0 refhim=4294901761
000 #3: "Test":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established);
EVENT_SA_REPLACE in 3142s; newest ISAKMP; lastdpd=52s(seq in:0 out:0); idle;
import:not set
000 #2: "Test":500 STATE_QUICK_R2 (IPsec SA established);
EVENT_SA_REPLACE in 3072s; isakmp#1; idle; import:not set
000 #2: "Test" esp.169405af at 192.168.10.2 esp.2bb99e85 at 192.168.10.1
tun.0 at 192.168.10.2 tun.0 at 192.168.10.1 ref=0 refhim=4294901761
000 #1: "Test":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established);
EVENT_SA_REPLACE in 3071s; lastdpd=-1s(seq in:0 out:0); idle; import:not set
14. The RC device seem to be responding to DPD:R-U-THERE messages" with
"DPD:R-U-THERE-ACK" even when the tunnel is in the sate of "perspective
erouted". [Fail]
The DPD ACK message from the RC device is making the Cisco device to think
that the remote peer is still alive.
15. Because of the above mentioned problem, bidirectional traffic flow between
the Cisco and RC devices would stop until the newest IPSEC and ISAKMP SAs
expire, which could take few hours. [Fail]
Debug on cisco suggesting that RC device is responding to DPD message with
correct sequence number even when the tunnel is in the state of "Prespective
erouted"
Note: T
*Aug 6 21:51:40.980: ISAKMP:(1206):purging node -656699726
*Aug 6 21:51:46.892: ISAKMP: DPD received KMI message.
*Aug 6 21:51:46.892: ISAKMP: set new node -2017992265 to QM_IDLE
*Aug 6 21:51:46.892: ISAKMP:(1206):Sending NOTIFY DPD/R_U_THERE protocol 1
spi 1718395776, message ID = -2017992265
*Aug 6 21:51:46.892: ISAKMP:(1206): seq. no 0x676D86EA
*Aug 6 21:51:46.892: ISAKMP:(1206): sending packet to 192.168.10.1 my_port 500
peer_port 500 (I) QM_IDLE
*Aug 6 21:51:46.892: ISAKMP:(1206):Sending an IKE IPv4 Packet.
*Aug 6 21:51:46.892: ISAKMP:(1206):purging node -2017992265
*Aug 6 21:51:46.896: ISAKMP (1206): received packet from 192.168.10.1 dport
500 sport 500 Global (I) QM_IDLE
*Aug 6 21:51:46.896: ISAKMP: set new node 829526078 to QM_IDLE
*Aug 6 21:51:46.896: ISAKMP:(1206): processing HASH payload. message ID =
829526078
*Aug 6 21:51:46.896: ISAKMP:(1206): processing NOTIFY DPD/R_U_THERE_ACK
protocol 1
spi 0, message ID = 829526078, sa = 66BB2BFC
*Aug 6 21:51:46.896: ISAKMP:(1206): DPD/R_U_THERE_ACK received from peer
192.168.10.1, sequence 0x676D86EA
*Aug 6 21:51:46.896: ISAKMP:(1206):deleting node 829526078 error FALSE reason
"Informational (in) state 1"
*Aug 6 21:51:46.896: ISAKMP:(1206):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
*Aug 6 21:51:46.896: ISAKMP:(1206):Old State = IKE_P1_COMPLETE New State =
IKE_P1_COMPLETE
Does that clarify (or muddy) the situation any more?
--
Len Sorensen
More information about the Swan-dev
mailing list