Hi,
While working with a PIX remote, I am running into one small
annoying problem where if the remote dies (e.g power failure), the
ipsectools version of racoon is not detecting that its gone. My only
way to currently work around it is by restarting racoon, or logging
on to a remote device and initiating traffic from there. However,
the later is not always possible. Restarting racoon always works,
but its obtrusive as it kills all my other associations.
Here is host A's inside address trying to ping Host B (the PIX) after
Host B has rebooted as seen by the router in the middle (i.e. the
public traffic). The PIX does not have any associations.
10:14:58.426228 IP 10.10.10.10 > 20.20.20.20: ESP(spi=0x43f1db44,seq=0x50)
10:15:03.250024 IP 10.10.10.10 > 20.20.20.20: ESP(spi=0x43f1db44,seq=0x51)
10:15:36.473624 IP 10.10.10.10 > 20.20.20.20: ESP(spi=0x43f1db44,seq=0x52)
10:15:50.514338 IP 10.10.10.10 > 20.20.20.20: ESP(spi=0x43f1db44,seq=0x53)
10:16:07.556660 IP 10.10.10.10 > 20.20.20.20: ESP(spi=0x43f1db44,seq=0x54)
On host A, I delete the SADB entries, and now I see
10:17:56.429578 IP 10.10.10.10.500 > 20.20.20.20.500: isakmp: phase
2/others ? oakley-quick[E]
going out. But how do I force a phase 1 to reneg ?
setkey -D does not show any associations
remote 20.20.20.20
{
exchange_mode main;
doi ipsec_doi;
situation identity_only;
my_identifier address;
peers_identifier address;
verify_identifier on;
dpd_delay 20;
nonce_size 16;
lifetime time 86400 sec; # sec,min,hour
initial_contact on;
support_mip6 on;
proposal_check obey; # obey, strict or claim
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key ;
dh_group 2 ;
}
}
#pix test box
sainfo address 192.168.44.0/28 any address 172.25.1.0/24 any
{
lifetime time 86400 sec;
encryption_algorithm 3des ;
authentication_algorithm hmac_sha1;
compression_algorithm deflate ;
}
# pix test box
sainfo address 172.25.1.0/24 any address 192.168.44.0/28 any
{
lifetime time 86400 sec;
encryption_algorithm 3des ;
authentication_algorithm hmac_sha1;
compression_algorithm deflate ;
}
The only way I am able to work around it, is by killing racoon and
restarting it or initiating the connection from the other side.
e.g. I kill racoon, and then do the same ping from the inside address of host A
10:22:58.521353 IP 10.10.10.10.500 > 20.20.20.20.500: isakmp: phase 1 I ident
10:22:59.063439 IP 20.20.20.20.500 > 10.10.10.10.500: isakmp: phase 1 R ident
10:22:59.083771 IP 10.10.10.10.500 > 20.20.20.20.500: isakmp: phase 1 I ident
10:22:59.636884 IP 20.20.20.20.500 > 10.10.10.10.500: isakmp: phase 1 R ident
10:22:59.664524 IP 10.10.10.10.500 > 20.20.20.20.500: isakmp: phase 1
I ident[E]
10:22:59.686713 IP 20.20.20.20.500 > 10.10.10.10.500: isakmp: phase 1
R ident[E]
10:22:59.688701 IP 20.20.20.20.500 > 10.10.10.10.500: isakmp: phase
2/others R inf[E]
10:22:59.704500 IP 10.10.10.10.500 > 20.20.20.20.500: isakmp: phase
2/others I inf[E]
10:23:00.574227 IP 10.10.10.10.500 > 20.20.20.20.500: isakmp: phase
2/others I oakley-quick[E]
10:23:01.199468 IP 20.20.20.20.500 > 10.10.10.10.500: isakmp: phase
2/others R oakley-quick[E]
10:23:01.254232 IP 10.10.10.10.500 > 20.20.20.20.500: isakmp: phase
2/others I oakley-quick[E]
10:23:07.133308 IP 10.10.10.10 > 20.20.20.20: ESP(spi=0x85b123c3,seq=0x1)
10:23:07.159598 IP 20.20.20.20 > 10.10.10.10: ESP(spi=0x06f84f76,seq=0x1)
Other than restarting racoon, is there a way to force it to restart
its phase 1 negotiations ?
It also doesnt seem to neg DPD ?
access-list secret permit ip 192.168.44.0 255.255.255.248 172.25.1.0
255.255.255.0
sysopt connection permit-ipsec
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto map outside_map 20 ipsec-isakmp
crypto map outside_map 20 match address secret
crypto map outside_map 20 set peer 10.10.10.10
crypto map outside_map 20 set transform-set ESP-3DES-SHA
crypto map outside_map interface outside
isakmp enable outside
isakmp key ******** address 10.10.10.10 netmask 255.255.255.255
isakmp identity address
isakmp keepalive 10 3
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 86400
---Mike
--------------------------------------------------------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike@...
Providing Internet since 1994 http://www.sentex.net
Cambridge, Ontario Canada http://www.sentex.net/mike
|