Site-to-site VPN tunnel with Cisco 831 vs. Firebox 2 renegotiation issue

[hornet303]

Hi,

Im having an issue with the above mentioned setup. I have created a VPN tunnel and all this works fine. I have isakmp expiration set at 86400 seconds no value for volume defined. If I initiate the tunnel from The c831 side, the tunnel will be created and passes traffic from both sides no problem.

I have noticed that if the 24hrs passes, the key expires and I initiate from the watchgard network the negotiation will fail. When I get to the c831 network, and I send traffic across (to cause isakmp negotiation)the tunnel will negotiate just fine.

The log im getting on the watchgard side is as follows:

03/01/05 13:52 kernel: ipsec: Output SA changing state DYING or DEAD

03/01/05 13:52 kernel: ipsec0: packet (e53f) failed with SA expired, SPI=1599637737, src=lll.lll.lll.lll, dest=rrr.rrr.rrr.rrr, sa.saddr=lll.lll.lll.lll, sa.daddr=rrr.rrr.rrr.rrr

03/01/05 13:52 kernel: ipsec: Output SA id now DEAD

03/01/05 13:52 iked[167]: Acquiring key for channel/policy 0/0

03/01/05 13:52 iked[167]: Key acquire proxyraddr = 10.0.3.0

03/01/05 13:52 iked[167]: Key acquire proxyladdr = 10.0.0.0

03/01/05 13:52 iked[167]: ipsec_acquire_keys: laddr = lll.lll.lll.lll, raddr = rrr.rrr.rrr.rrr

03/01/05 13:52 iked[167]: TO rrr.rrr.rrr.rrr MM-HDR ISA_SA ISA_VENDORID ISA_VENDORID ISA_VENDORID ISA_VENDORID

03/01/05 13:52 iked[167]: FROM rrr.rrr.rrr.rrr MM-HDR ISA_SA ISA_VENDORID

03/01/05 13:52 iked[167]: TO rrr.rrr.rrr.rrr MM-HDR ISA_KE ISA_NONCE NAT-D NAT-D

03/01/05 13:52 iked[167]: FROM rrr.rrr.rrr.rrr MM-HDR ISA_KE ISA_NONCE ISA_VENDORID ISA_VENDORID ISA_VENDORID ISA_VENDORID NAT-D NAT-D

03/01/05 13:52 iked[167]: Rejecting peer XAUTH request: not configured

03/01/05 13:52 iked[167]: TO rrr.rrr.rrr.rrr MM-HDR*# ISA_ID ISA_HASH

03/01/05 13:52 iked[167]: FROM rrr.rrr.rrr.rrr MM-HDR*# ISA_ID ISA_HASH

03/01/05 13:52 iked[167]: Phase 1 completed as initiator

03/01/05 13:52 iked[167]: Getting IPSEC preferences as Initiator propnum=1, mode=(UDP Encaps Tunnel), laddr=lll.lll.lll.lll, raddr=rrr.rrr.rrr.rrr

03/01/05 13:52 iked[167]: Getting IPSEC preferences as Initiator propnum=2, mode=(UDP Encaps Tunnel), laddr=lll.lll.lll.lll, raddr=rrr.rrr.rrr.rrr

03/01/05 13:52 iked[167]: TO rrr.rrr.rrr.rrr QM-HDR*#-E7557343 ISA_HASH ISA_SA ISA_NONCE ISA_ID ISA_ID

03/01/05 13:52 iked[167]: FROM rrr.rrr.rrr.rrr IF-HDR*#-6FD6B097 ISA_HASH ISA_NOTIFY

03/01/05 13:52 iked[167]: Received NO_PROPOSAL_CHOSEN message, mess_id=0x97B0D66F

03/01/05 13:52 iked[167]: Notify error 14 received from rrr.rrr.rrr.rrr

03/01/05 13:52 iked[167]: RE-TO rrr.rrr.rrr.rrr QM-HDR*#-E7557343 ISA_HASH

Unfortunatly, I cant get to the syslog on the c831 network, but I will later tonight so I can post the crypto negotiation for that. Anyway, Im just curious as to if anyone has any ideas what could be the issue.

On a side note, I notice in the isakmp policy declaration, I set the lifetime to 86400 seconds.

But when it actually negotiates with the Watchgard FB2, it also specifies a volume of roughly 400megs. This seems to be declared in the crypto security-association area and seems to have priority over what is declared in the individual isakmp policy.

Is there a way to not use volume lifetime expiration? Normally (with other devices) I do not require it, but the c831 seems to mandate it. Is this true?

Anyway, any help would be greatly appreciated. I will add the c831 syslog when I get access to it

[ehirsel]

IOS by default will specify a volume size of 4000 MB (4 GB) if none is speced out and I believe that it will put that value in the volume parameter. I would check the remote c831 config to see if there is a volume lifetime speced out, and if so is it 400 MB; if not then double check what you saw to make sure you saw the size right (easy to miss when there is a lot of log info).

Another item to check is that the IPSEC prosposal on the Watchgard matches exactly what the c831 has configured; not just time and volume lifetimes, but pfs and dh group settings as well as insuring that the interesting traffic lists are mirror images of each other. I think that the c831 has a subset of what the Watchgard has which is why it can intiate a negotiation; but when the inverse happens the negotiation fails; if one acl uses port/protocol info the acl on the other unit should use them as well.

Let me know what you find.

[hornet303]

Ehirsel,

Thanks for the response. I cleared all the crypto info in my 831 and re-entered it all back in. I set the volume limit to 20megs and the seconds limit to 86400. Everything seems to be matching to the best of my ability. I am relatively new to Cisco so there may be something that you can point out that is not right.

Below is my crypto portion on my router config:

crypto isakmp policy 10

hash md5

authentication pre-share

crypto isakmp key XXXXXXXXXX address rrr.rrr.rrr.rrr

!

!

crypto ipsec transform-set ateam esp-des esp-md5-hmac

!

crypto map sms_tunnel 10 ipsec-isakmp

set peer rrr.rrr.rrr.rrr

set security-association lifetime kilobytes 20480

set security-association lifetime seconds 86400

set transform-set ateam

match address 107

I have the crypto map bound to int e1. I will attach the syslog info from the c831 router when the tunnel has expired and the watchguard network (10.0.0.0/24) tries to initiate the renegotiation.

When reading the document, keep in mind that this is local to the c831, so compared to my message yesterday, the roles of local and remote have swapped.