Trying to connect to Cisco via IPsec but getting " aggressive mode message #1 (ERROR)"

[WillB]

Hi all, We have a number of FG-100As (FG100A-3.00-FW-build733-081121) and have been using them for years for IPsec VPNs to one another, as well as to a Nortel router. Now we are trying to set up IPsec to a Cisco device run by a third party, but we' re getting the " Initiator: parsed G.G.G.G aggressive mode message #1 (ERROR)" message - even after double-checking the keys with one another and reentering at both ends. I' ve read that this error can sometimes be due to other phase 1 settings not matching, but have checked them and they seem correct (I presume phase 2 settings are not relevant at this stage, but we believe they are correct too). The routing is working well enough to trigger the fortigate to try and bring the connection up, so using diag debug enable and diag debug appli ike 2, here is what I see on the fortigate: 0:AEMO:2537: initiator: aggressive mode is sending 1st message... 0:AEMO:2537: cookie fa669c197d8884a0/0000000000000000 0:AEMO:2537: sent IKE msg (agg_i1send): ME.ME.ME.ME:500->G.G.G.G:500, len=488 AEMO: Initiator: sent G.G.G.G aggressive mode message #1 (OK) 0: comes G.G.G.G:500->ME.ME.ME.ME:500,ifindex=2.... 0: exchange=Aggressive id=fa669c197d8884a0/ffb0d8a1666d76de len=428 0: found AEMO ME.ME.ME.ME 2 -> G.G.G.G:500 0:AEMO:2537: initiator: aggressive mode get 1st response... 0:AEMO:2537: VID CISCO-UNITY 0:AEMO:2537: VID draft-ietf-ipsra-isakmp-xauth-06.txt 0:AEMO:2537: VID DPD 0:AEMO:2537: DPD negotiated 0:AEMO:2537: VID draft-ietf-ipsec-nat-t-ike-02 0:AEMO:2537: VID FRAGMENTATION 0:AEMO:2537: unknown VID (16): 1F07F70EAA6514D3B0FA96542A500100 0:AEMO:2537: negotiation result 0:AEMO:2537: proposal id = 1: 0:AEMO:2537: protocol id = ISAKMP: 0:AEMO:2537: trans_id = KEY_IKE. 0:AEMO:2537: encapsulation = IKE/none 0:AEMO:2537: type=OAKLEY_ENCRYPT_ALG, val=3DES_CBC. 0:AEMO:2537: type=OAKLEY_HASH_ALG, val=MD5. 0:AEMO:2537: type=AUTH_METHOD, val=PRESHARED_KEY. 0:AEMO:2537: type=OAKLEY_GROUP, val=1024. 0:AEMO:2537: ISKAMP SA lifetime=86400 0:AEMO:2537: info_send_n1, type 23 0:AEMO:2537: sent IKE msg (p1_notify_23): ME.ME.ME.ME:500->G.G.G.G:500, len=60 AEMO: Initiator: parsed G.G.G.G aggressive mode message #1 (ERROR) 0:AEMO:2537: sent IKE msg (P1_RETRANSMIT): ME.ME.ME.ME:500->G.G.G.G:500, len=488 (and then it repeats) Does anyone know of any particular issues with Cisco interop that might cause this? From the unknown VID line I believe this is a Cisco VPN Concentrator. I have tried setting this VPN up both as a route-based VPN (which is the way that we usually do things) and also as a policy-based VPN as suggested by the ' FortiGate to Cisco PIX VPN' knowledge page. Both give the same results. I notice that that page suggests using SHA1, but the other party explicitly specifies MD5 (and we tried SHA1 too just in case). Here are the details they gave us: Connection Type: AEMO will answer only Authentication: Pre-Share Keys Encryption: 3DES Hash: MD5 DH group: 2 Lifetime: 86400 Speed: 256Kbps Transform Set: esp-3des esp-md5-hmac I' ve attached our phase 1 configuration. Our phase 2 has 3DES, MD5, PFS off, 86400 keylife, and we' ve tried both with and without entering quick mode selectors (though as above, I believe that stuff isn' t relevant at the early stage the above error occurs anyway?). We went through it on the phone and they are not getting much more info at their end in their logs (unfortunately they terminate hundreds of clients so not easy to talk them into using debug mode) - they did have some " Information Exchange processing failed" errors from our IP but that could actually have just been when I was trying out variations on the settings. Any suggestions? Thanks, Will

[rwpatterson]

Welcome to the forums. Your device is capable of running much newer and cleaner code than v3, MR7, Patch 2. I would start with something that' s been produced in the past year. Your version is November 2008. I would personally go to v4, MR1, Patch 10. It' s still the green version of code (no learning curve involved), and it' s much newer. My two cents

[ede_pfau]

Well, it should work OK if all parameters are set correctly, and only after confirming this you could suspect a bug in the firmware. I am not a friend of ' have trouble, will upgrade' . There are implications and possibly configuration changes involved with an upgrade, esp. when changing the main version. Nonetheless, your code is (ancient) a bit outdated. You can occasionally update to v3.00MR7patch10 (build 754). But this won' t fix your current problem IMHO. Please disable the DH parameter in phase1. This is settable both in p1 and p2, and often other vendors specify it for p2 only. Then, enable NAT-T. Will harm if needed and disabled, but won' t if not needed and enabled. One caveat: when changing parameters, be sure to tear down the tunnel before trying. You discard the SAs by typing ' diag vpn tunnel flush' . This kills ALL tunnels, though.

[WillB]

Thanks both for those suggestions, I' ll try them in turn. edu_pfau, if I try to disable the DH group 2 setting in phase one I get an error ' You must select at least one DH group' . Perhaps that restriction has been removed in a later firmware level? FWIW, I don' t get the option to select a DH setting in phase 2 because PFS is turned off and that disables the radiobuttons. I disabled PFS based on the fortigate article - do you think I should turn it on? I have turned NAT-T on now - I did try it on earlier and it didn' t seem to help, but will leave it on. Thanks, Will

[rwpatterson]

Later versions need a DH group in phase 1 as well. As far as PFS is concerned, it needs to match what' s on the other end, regardless of the Fortinet guide.

[WillB]

Yeah, we were told they use PFS off, though I tried it with PFS on too just in case phase 2 was relevant. So anything else I should try before I try and get a firmware upgrade? These are pretty old so probably out of their original warranty now. Thanks, Will

[ede_pfau]

Sorry about the phase1 DH group setting, right, you cannot disable it. There should be a matching setting on the Cisco side then, get that information. One line that I don' t understand from the debug output is ' VID FRAGMENTATION' . I don' t see that in the negotiations of the tunnels on my box. If nothing else helps then start upgrading, to 3.00MR7 patch10 first as this won' t change your configuration. Make a backup of it first. Then you might upgrade to the 4.1 branch; see the Release Notes for the correct upgrade path (i.e., intermediate versions).

[rwpatterson]

I would start first with getting a copy of the Cisco configuration, then secondly try the upgrade to v3 mR7 P10. By the way, have you tried main mode as opposed to aggressive mode?

[WillB]

We went through it on the phone and confirmed that it matched our settings (DH group 2, aggressive mode, etc.). So time for a firmware upgrade I think, if we can get it. Cheers, Will

[emnoc]

Why are you trying to use aggressive mode vrs main-mode for IKE? On the VID FRAGMENTATION, don' t worry about that. That' s just the Vendor ID of what cisco supports being passed. It will be ignored and not service effecting if the other end does not negoiated it.

' VID FRAGMENTATION'