cancel
Showing results for 
Search instead for 
Did you mean: 
ethjul
Level 7
Report Inappropriate Content
Message 1 of 10

AGGRESSIVE_MODE exchange processing failed

Jump to solution

I have a VPN setup on my Secure Firewall (Sidewinder) that has been working for a few years but recently ran into a problem while connecting. IKE phase 1 is failing and all the logs on the firewall are showing is "AGGRESSIVE_MODE exchange processing failed". Using the SoftRemote client. I think I have narrowed down the problem to a new router at my home. I recently replaced my home wireless router and all settings should be the same between the new and old routers. However, when I swap back to the old router I am able to connect the VPN with no errors using the same client. I am thinking this may be a configuration problem with the new router, but can't figure what it might be. Below is from the firewall logs (some numbers changed to keep anonymity):

Cky_i 8971b0e35df79c5a
Cky_r 5b2183bb2c52d785
Cmd ikmpd
Date Aug 28 2010 PDT
Facility isakmp_daemon
Hostname fw.mydomain.com
Information [detailed info]   [error]     AGGRESSIVE_MODE exchange processing failed
Local_gw 21.135.31.66
Remote_gw 68.123.158.21
Remote_id 10.10.10.2
Syslog Errors (3)
Time 19:47:23
Type error
Vpn_name MY_VPN

There are 3 of these. From the client side I see the request go out and then timeout 3 times with no response. Verified that aggressive mode is selected for both ends of the connection.

Any help is greatly appreciated.

1 Solution

Accepted Solutions
sliedl
Level 14
Report Inappropriate Content
Message 8 of 10

Re: AGGRESSIVE_MODE exchange processing failed

Jump to solution

It looks like the other end of the tunnel is not responding back to the firewall after the tunnel is created:

Sep 18 07:18:46 2010 PDT  f_isakmp_daemon a_vpn t_info p_major
information: Session creation -
[session details]
  vpn_name: MY_VPN, state: ALIVE, flags: INITIAL_CONTACT

Sep 18 07:19:02 2010 PDT  f_isakmp_daemon a_vpn t_error p_major
information: [detailed info]
  [error]
    AGGRESSIVE_MODE exchange processing failed

Sep 18 07:19:17 2010 PDT  f_isakmp_daemon a_vpn t_error p_major
information: [detailed info]
  [error]
    AGGRESSIVE_MODE exchange processing failed

Sep 18 07:19:32 2010 PDT  f_isakmp_daemon a_vpn t_error p_major
information: [detailed info]
  [error]
    AGGRESSIVE_MODE exchange processing failed

Sep 18 07:19:58 2010 PDT  f_isakmp_daemon a_vpn t_info p_major
information: [detailed info]
  [info]
    AGGRESSIVE_MODE exchange terminated - AGGRESSIVE_MODE negotiation timed out (retransmission threshold reached)

If you look at the times of the 'AGGRESSIVE_MODE exchange processing failed' messages, they are all 15 seconds apart (except the first one, which is 16 seconds later).  This would indicate to me the firewall is trying to contact the other side of the tunnel on some preset timer.

Do you have 'Forced Rekey' set in the Advanced tab of your VPN definition (at the bottom)?  Off the top of my head that is all I could think that could cause this. (Note: the Help for the firewall says "Do not enable the Forced Rekey option if you have HA/LS configured and are using static IP addresses for your VPNs.  Doing so will cause all firewalls in the cluster to attempt to instantiate the VPN at the same time, resulting in failure.").

If you don't have Forced Rekey set then perhaps this is how the VPN tunnels work (I don't know enough about VPN processing to say "The firewall is going to contact the other side of the tunnel every 15 seconds").

No matter what is 'causing' this, the fact is the firewall is trying to contact the other side of the tunnel and that side of the tunnel is not responding (retransmission threshold reached).  If you took a tcpdump on the external interface (tcpdump -npi intf_name port 500 or port 4500 or proto 50) I bet you'll see each one of these packets go out the firewall's interface (probably on port 500) and no response will come back.  If so, you'll have to check the other side to see if these packets are getting there and if so, why it is not responding to you.

on 9/23/10 5:17:13 PM CDT

View solution in original post

9 Replies
oreeh
Level 10
Report Inappropriate Content
Message 2 of 10

Re: AGGRESSIVE_MODE exchange processing failed

Jump to solution

Check if your router is natting the IKE packets (UDP 500) retaining the source port (also 500). Some routers claim to be able to passthrough IPSEC but violate the RFCs by changing the source port.

ethjul
Level 7
Report Inappropriate Content
Message 3 of 10

Re: AGGRESSIVE_MODE exchange processing failed

Jump to solution

Thanks! I ran a tcpdump on the firewall and verified that UDP port 500 is both the source and destination. Here is the dump:

11:56:45.573429 IP (tos 0x0, ttl 116, id 414, offset 0, flags [none], proto: UDP (17), length: 488) 68.123.158.21.500 > 21.135.31.66.500: isakmp 1.0 msgid : phase 1 I agg: [|sa]
11:56:45.634444 IP (tos 0x0, ttl  64, id 612, offset 0, flags [none], proto: UDP (17), length: 424) 21.135.31.66.500 > 68.123.158.21.500: isakmp 1.0 msgid : phase 1 R agg: [|sa]
11:56:48.578986 IP (tos 0x0, ttl  64, id 681, offset 0, flags [none], proto: UDP (17), length: 424) 21.135.31.66.500 > 68.123.158.21.500: isakmp 1.0 msgid : phase 1 R agg: [|sa]
11:56:54.585985 IP (tos 0x0, ttl  64, id 1242, offset 0, flags [none], proto: UDP (17), length: 424) 21.135.31.66.500 > 68.123.158.21.500: isakmp 1.0 msgid : phase 1 R agg: [|sa]
11:57:00.837239 IP (tos 0x0, ttl 116, id 449, offset 0, flags [none], proto: UDP (17), length: 488) 68.123.158.21.500 > 21.135.31.66.500: isakmp 1.0 msgid : phase 1 I agg: [|sa]
11:57:09.591975 IP (tos 0x0, ttl  64, id 1765, offset 0, flags [none], proto: UDP (17), length: 424) 21.135.31.66.500 > 68.123.158.21.500: isakmp 1.0 msgid : phase 1 R agg: [|sa]
11:57:15.820469 IP (tos 0x0, ttl 116, id 734, offset 0, flags [none], proto: UDP (17), length: 488) 68.123.158.21.500 > 21.135.31.66.500: isakmp 1.0 msgid : phase 1 I agg: [|sa]
11:57:30.819442 IP (tos 0x0, ttl 116, id 762, offset 0, flags [none], proto: UDP (17), length: 488) 68.123.158.21.500 > 21.135.31.66.500: isakmp 1.0 msgid : phase 1 I agg: [|sa]

sliedl
Level 14
Report Inappropriate Content
Message 4 of 10

Re: AGGRESSIVE_MODE exchange processing failed

Jump to solution

Can you please send me the output of 'cf package list' from your firewall?

I have seen a few tickets with this same message (AGGRESSIVE_MODE exchange processing failed) even though both sides of the tunnel are using Aggressive Mode.  I would like to reproduce it.  If your package output matches some other customer's package output I can install those packages and hopefully reproduce the issue.

You can send me a Private Message if you'd like.

ethjul
Level 7
Report Inappropriate Content
Message 5 of 10

Re: AGGRESSIVE_MODE exchange processing failed

Jump to solution

Thanks. I'll send the cf package list output in a private message shortly.

Also, I have looked around for reports with this router model to see if others were having similar problems. Didn't find anything for the specific model but for Belkins in general. Supposedly fixed in a firmware update, but I have the latest firmware available. Model is Belkin F5D7234-4.

Highlighted
sliedl
Level 14
Report Inappropriate Content
Message 6 of 10

Re: AGGRESSIVE_MODE exchange processing failed

Jump to solution

You're not on the same version as the other tickets I've seen, so the version has nothing to do with it.

The 'processing failed' message is a standard error message; it means 'it didn't work.'  In the Sidewinder's audit there should be more information as to what the problem was with the tunnel.

You can look for just VPN related audits with this audit filter:

$> acat -e "area vpn" | less

You can look for just -this- VPN tunnel with this audit filter:

$> acat -e "vpn_name MY_VPN" | less

You can also run the commands on the past audits (the audits that have 'rolled', or been gzipped, already):

$> acat -e "area vpn" /var/log/audit.raw.[date-range].gz | less

You do not have to unzip the files to use the acat command on them.

Or you can run a 'live' audit and test your traffic and then look at the data right then:

$> acat -ke "area vpn" > liveaudit.txt

Then open the file:

$> less liveaudit.txt

(use 'q' to quit out of less when you're done)

ethjul
Level 7
Report Inappropriate Content
Message 7 of 10

Re: AGGRESSIVE_MODE exchange processing failed

Jump to solution

I ran acat against a previous (but very recent) log. It shows both the initial attempt that failed, and then the subsequent attempt (with the old router) that worked. I'll send you a private message with that output. I don't really see much difference, except the obvious that one worked and the other didn't. Hopefully you can tell more from it than me.

sliedl
Level 14
Report Inappropriate Content
Message 8 of 10

Re: AGGRESSIVE_MODE exchange processing failed

Jump to solution

It looks like the other end of the tunnel is not responding back to the firewall after the tunnel is created:

Sep 18 07:18:46 2010 PDT  f_isakmp_daemon a_vpn t_info p_major
information: Session creation -
[session details]
  vpn_name: MY_VPN, state: ALIVE, flags: INITIAL_CONTACT

Sep 18 07:19:02 2010 PDT  f_isakmp_daemon a_vpn t_error p_major
information: [detailed info]
  [error]
    AGGRESSIVE_MODE exchange processing failed

Sep 18 07:19:17 2010 PDT  f_isakmp_daemon a_vpn t_error p_major
information: [detailed info]
  [error]
    AGGRESSIVE_MODE exchange processing failed

Sep 18 07:19:32 2010 PDT  f_isakmp_daemon a_vpn t_error p_major
information: [detailed info]
  [error]
    AGGRESSIVE_MODE exchange processing failed

Sep 18 07:19:58 2010 PDT  f_isakmp_daemon a_vpn t_info p_major
information: [detailed info]
  [info]
    AGGRESSIVE_MODE exchange terminated - AGGRESSIVE_MODE negotiation timed out (retransmission threshold reached)

If you look at the times of the 'AGGRESSIVE_MODE exchange processing failed' messages, they are all 15 seconds apart (except the first one, which is 16 seconds later).  This would indicate to me the firewall is trying to contact the other side of the tunnel on some preset timer.

Do you have 'Forced Rekey' set in the Advanced tab of your VPN definition (at the bottom)?  Off the top of my head that is all I could think that could cause this. (Note: the Help for the firewall says "Do not enable the Forced Rekey option if you have HA/LS configured and are using static IP addresses for your VPNs.  Doing so will cause all firewalls in the cluster to attempt to instantiate the VPN at the same time, resulting in failure.").

If you don't have Forced Rekey set then perhaps this is how the VPN tunnels work (I don't know enough about VPN processing to say "The firewall is going to contact the other side of the tunnel every 15 seconds").

No matter what is 'causing' this, the fact is the firewall is trying to contact the other side of the tunnel and that side of the tunnel is not responding (retransmission threshold reached).  If you took a tcpdump on the external interface (tcpdump -npi intf_name port 500 or port 4500 or proto 50) I bet you'll see each one of these packets go out the firewall's interface (probably on port 500) and no response will come back.  If so, you'll have to check the other side to see if these packets are getting there and if so, why it is not responding to you.

on 9/23/10 5:17:13 PM CDT

View solution in original post

ethjul
Level 7
Report Inappropriate Content
Message 9 of 10

Re: AGGRESSIVE_MODE exchange processing failed

Jump to solution

I did notice the 15 second intervals between retransmission and assumed that was just the default retry period. Also, I did run a tcpdump on the external interface and posted previously. It didn't click for me that the firewall is indeed trying to respond. I'll see if I can find out why the other end is not responding. That will take me a little time. I may also tinker with some of the VPN settings to see if I can find one that is triggering the endpoint router to not respond.

Regarding the "Forced Rekey", yes I do have that set and I recall reading that line in the manual. However, we are not using HA/LS so I figured it would be fine. Regardless, I appreciate the help and will look into the other end and post back what I find.

ethjul
Level 7
Report Inappropriate Content
Message 10 of 10

Re: AGGRESSIVE_MODE exchange processing failed

Jump to solution

Well, I couldn't find a way to determine why the router was not responding. It's a fairly cheap home router so the options are limited. Looking at the packets didn't really do much since they look fine coming in...and then there is nothing going back out since the router simply didn't respond.

It seems strange to me that both the new and old routers that I am working with were of the same brand and, as far as I could make it, the same configuration. Only difference was a few years age, yet the old worked and the new didn't. I would expect the opposite, but...

In the end yet another router...different brand...did the trick well enough. Many thanks for the help.

More McAfee Tools to Help You
  • Subscription Service Notification (SNS)
  • How-to: Endpoint Removal Tool
  • Support: Endpoint Security
  • eSupport: Policy Orchestrator
  • Community Help Hub

      New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

    • Find Forum FAQs
    • Learn How to Earn Badges
    • Ask for Help
    Go to Community Help

    Join the Community

      Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

    • Get helpful solutions from McAfee experts.
    • Stay connected to product conversations that matter to you.
    • Participate in product groups led by McAfee employees.
    Join the Community
    Join the Community