How to Fix IKE Aggressive Mode with Pre-Shared Key (Nessus 62694)

IKE Aggressive Mode with Pre-Shared Key means a VPN gateway accepts IKEv1 Aggressive Mode handshakes authenticated with a pre-shared key (PSK). In that mode the gateway sends a hash derived from the PSK to any unauthenticated initiator, and the hash can be cracked offline. Fix it by disabling IKEv1 Aggressive Mode, then move tunnels to IKEv2 or certificates.

The configuration change is one line on most gateways. The planning is in finding which remote-access groups and dialup peers still depend on Aggressive Mode before you turn it off.

What the scanner is actually detecting

Tenable’s synopsis is short: “The remote IKEv1 service supports Aggressive Mode with Pre-Shared key.” In other words, the gateway answered an IKEv1 Aggressive Mode request that offered PSK authentication.

IKEv1 phase 1 has two modes. Main Mode takes six messages, and the peers exchange identities and authentication hashes only after the Diffie-Hellman exchange, encrypted. Aggressive Mode compresses phase 1 into three messages: the initiator sends its proposal, key exchange, nonce and identity in the first packet, and the responder replies with its own identity and an authentication hash before the initiator has proven anything. With PSK authentication that hash is computed from keying material derived from the PSK. The strongSwan project describes it as a hash of the PSK transmitted in the clear, open to offline dictionary or brute force attack.

The CVE attached to the plugin, CVE-2002-1623, covers the other half of the problem: identities are not encrypted during Aggressive Mode, so responses can reveal valid user or group names.

Real-world risk

Anyone who can send packets to UDP 500 on the gateway, and who knows or guesses an identity the gateway accepts, can collect the hash without logging in. Cracking then happens offline, so account lockout and login rate limits do not apply. The ike-scan package even ships a companion cracker, psk-crack, for exactly this purpose.

How much that matters depends on two things:

• PSK strength. Short, human-chosen or reused keys are realistic to crack. A long random key makes offline cracking impractical, although the finding stays because it is about the mode, not the key.
• What the key protects. On a site-to-site tunnel that only accepts a fixed peer IP, a cracked key alone rarely opens a tunnel. On a remote-access group, the key is usually shared by every user, rarely rotated, and XAUTH user credentials become the only remaining barrier. A known group key also helps an attacker who can intercept users’ traffic to pose as the gateway.

Tenable rates it Medium. Prioritize internet-facing gateways with IKEv1 remote-access groups; an internal-only lab gateway with a random 40-character key is a much smaller problem. If you are still deciding which internet-facing addresses belong in routine scans, see how to scope external attack surface management.

How to confirm it on the host

From a Linux host you are authorized to test from, send an Aggressive Mode probe with ike-scan. It uses UDP source port 500 by default, which normally requires root.

sudo ike-scan -A -M <gateway-ip>
sudo ike-scan -A -M --id=<group-or-peer-id> <gateway-ip>

A line reading Aggressive Mode Handshake returned confirms the finding. A notify message such as NO-PROPOSAL-CHOSEN only means the probe’s transforms or ID were not accepted. ike-scan defaults to Diffie-Hellman group 2, so match your gateway’s IKEv1 policy before concluding anything. For example, AES-256, SHA-1, PSK authentication and group 14:

sudo ike-scan -A -M --id=<group-or-peer-id> --trans=7/256,2,1,14 --dhgroup=14 <gateway-ip>

Some gateways only answer when the ID matches a configured tunnel group or peer ID, so test with the IDs you actually use. Then check the configuration directly:

• Cisco ASA: Aggressive Mode is enabled by default and the default is not shown. show running-config | include am-disable returning nothing means it is still allowed. In show crypto isakmp sa, a state of AM_ACTIVE marks a live Aggressive Mode SA, while MM_ACTIVE is Main Mode.
• Cisco IOS and IOS XE: show running-config | include aggressive-mode|client configuration group. Easy VPN groups with a key rely on Aggressive Mode.
• FortiGate: show vpn ipsec phase1-interface (and show vpn ipsec phase1 for policy-based tunnels). Main Mode and IKE version 1 are the defaults and stay hidden, so look for set mode aggressive on tunnels without set ike-version 2.
• strongSwan: grep -rn aggressive /etc/swanctl/ /etc/strongswan.conf /etc/strongswan.d/

How to fix it

Cisco ASA

In global configuration mode, disable inbound IKEv1 Aggressive Mode and save. On software older than 8.4(1) the same command is crypto isakmp am-disable.

ciscoasa(config)# crypto ikev1 am-disable
ciscoasa(config)# write memory

Cisco IOS and IOS XE

This blocks Aggressive Mode requests to and from the router, regardless of whether they use PSKs or RSA signatures:

Router(config)# crypto isakmp aggressive-mode disable
Router(config)# end
Router# copy running-config startup-config

FortiGate (FortiOS)

Set each IKEv1 phase 1 to Main Mode. Repeat under config vpn ipsec phase1 for policy-based tunnels.

config vpn ipsec phase1-interface
    edit "<tunnel-name>"
        set mode main
    next
end

If both ends support it, set ike-version 2 is the better change. Where several dialup tunnels share one interface and were told apart by peer ID in Aggressive Mode, Fortinet documents using set network-overlay enable and set network-id with IKEv2 instead.

strongSwan

Both relevant settings default to off, so the fix is removing any override. In swanctl.conf, each connection should have aggressive = no or no aggressive line at all. In strongswan.conf, the charon option i_dont_care_about_security_and_use_aggressive_mode_psk must be absent or no; without it, strongSwan refuses to act as an Aggressive Mode PSK responder. Reload connections with swanctl –load-all and restart the strongSwan service after editing strongswan.conf.

The better fix: migrate IKEv1 to IKEv2 or certificates

IKEv2 has no Aggressive Mode and encrypts identities and authentication payloads, so an unauthenticated scanner cannot pull a PSK hash the same way. A weak PSK is still weak under IKEv2, so certificates are the stronger option where your peers support them. On ASA, Cisco documents the migrate l2l command, which converts IKEv1 site-to-site tunnels to IKEv2 while keeping IKEv1 running in parallel. You also need crypto ikev2 enable outside. The ASA prefers IKEv2 and falls back to IKEv1, so remove the IKEv1 settings once each peer is confirmed on IKEv2.

If a PSK has to stay

• Replace short keys with long random ones. strongSwan’s security recommendations generate one with openssl rand -base64 33. Change it on both peers in the same window.
• Allow UDP 500 and 4500 to the gateway only from known peer addresses. On ASA, to-the-box traffic is filtered with a control-plane ACL, which has no implicit deny at the end:

access-list CP-IKE extended permit udp host <peer-ip> any eq 500
access-list CP-IKE extended permit udp host <peer-ip> any eq 4500
access-list CP-IKE extended deny udp any any eq 500
access-list CP-IKE extended deny udp any any eq 4500
access-group CP-IKE in interface outside control-plane

How to verify the fix and rescan

1. Repeat the exact ike-scan commands you used to confirm the finding, with the same IDs and transforms. There should be no Aggressive Mode Handshake returned line.
2. A plain sudo ike-scan <gateway-ip> may still show Main Mode Handshake returned. That is expected and is not what plugin 62694 reports.
3. Recheck the configuration: crypto ikev1 am-disable or crypto isakmp aggressive-mode disable should now appear in the running configuration, and no FortiGate or strongSwan tunnel should still use Aggressive Mode.
4. Watch real tunnels through at least one rekey. On ASA, IKEv1 SAs should show MM_ACTIVE, and migrated tunnels should appear in show crypto ikev2 sa.
5. Rescan with Nessus and make sure the policy probes UDP 500, or the finding disappears without being fixed.

What can break and how to roll back

Failures can surface at the next phase 1 negotiation or rekey rather than the moment you commit, so schedule the change in a window where you can watch remote users reconnect. Back up the running configuration first.

Common false positive reasons

• True false positives are rare. If ike-scan gets an Aggressive Mode handshake with PSK, the condition is real. Most disputes are about exposure or ownership.
• Wrong device. UDP 500 may be forwarded by NAT to a VPN server behind the firewall, or answered by a cluster address. Fix the device that actually terminates IKE.
• Stale results. The scan predates the change, or the rescan policy skipped UDP.
• Negative manual test. An ike-scan run with the wrong ID or transforms can look clean while the scanner’s probe was accepted. That is a gap in the manual test, not a false positive.

FAQ

Does IKEv2 have this problem?

No. IKEv2 has no Aggressive Mode, and plugin 62694 checks IKEv1 only. PSK strength still matters under IKEv2.

Is Main Mode with a PSK acceptable?

It removes the unauthenticated hash leak this finding describes. Keep the key long and random, and prefer certificates or IKEv2 where peers support them.

Will a stronger PSK close the finding?

No. It lowers the cracking risk, but the scanner detects the mode, so the finding remains until Aggressive Mode is disabled.

Does disabling Aggressive Mode drop existing tunnels?

It affects new phase 1 negotiations. Peers that depend on Aggressive Mode usually fail at their next reconnect or rekey.

Tracking this finding across many hosts

VPN gateways tend to be few but scattered across sites and owners. SITEY, a self-hosted vulnerability management platform, imports Nessus results from an uploaded .nessus export and can re-test an individual Nessus finding such as 62694 after a gateway change. Duplicates are merged per scanner, so the same gateway reported by two different scanners appears as two findings.

Sources

• Tenable: Internet Key Exchange (IKE) Aggressive Mode with Pre-Shared Key (Nessus 62694)
• Cisco Secure Firewall ASA Command Reference: crypto ikev1 am-disable
• Cisco IOS Security Command Reference: crypto isakmp aggressive-mode disable
• Fortinet FortiOS CLI Reference: config vpn ipsec phase1-interface
• strongSwan Documentation: Security Recommendations