EC2.183: VPN is using deprecated IKEv1

Written and reviewed by Emnode · Last reviewed 27 May 2026

What does AWS Security Hub EC2.183 check?

EC2.183 fails any Site-to-Site VPN connection whose tunnel options include ikev1 in the IkeVersions list. Evaluated every 12 hours, it fails whenever either tunnel still permits IKEv1 — even if the live session happens to be running on IKEv2.

Why does EC2.183 matter?

IKEv1 is the 1998 protocol with known weaknesses: a chatty nine-message handshake, optional dead-peer-detection, no MOBIKE, no native EAP, and a permissive cipher menu that historically allowed 3DES and SHA1. IKEv2 (RFC 7296) replaces it with a 4-message handshake, mandatory DPD, and a tighter cipher set. Leaving IKEv1 listed permits a downgrade even when both sides could negotiate v2.

How do I fix EC2.183?

Inventory which VPNs and tunnels still accept IKEv1 across every region, grouping by customer-gateway model.
Verify the customer gateway supports IKEv2 before touching AWS — almost all modern firewalls do, but very old gear may not.
Migrate one tunnel at a time in a low-traffic window with modify-vpn-tunnel-options, watching BGP reconverge on the other tunnel before doing the second.
Enable VPN tunnel logging (EC2.171) to watch the renegotiation, and bake IKEv2-only into your IaC so it cannot creep back.

Remediation script · bash

# List every Site-to-Site VPN that currently has a tunnel DOWN.
aws ec2 describe-vpn-connections \
  --query 'VpnConnections[?VgwTelemetry[?Status==`DOWN`]].VpnConnectionId' --output text

# Lock a tunnel to IKEv2 only and turn logging on, one tunnel at a time.
aws ec2 modify-vpn-tunnel-options \
  --vpn-connection-id vpn-0a1b2c3d4e5f6a7b8 \
  --vpn-tunnel-outside-ip-address 203.0.113.20 \
  --tunnel-options '{"IKEVersions":[{"Value":"ikev2"}],"StartupAction":"start","LogOptions":{"CloudWatchLogOptions":{"LogEnabled":true,"LogGroupArn":"arn:aws:logs:us-east-1:111122223333:log-group:/aws/vpn/s2s","LogOutputFormat":"json"}}}'

# Turn on connection logging for a Client VPN endpoint.
aws ec2 modify-client-vpn-endpoint \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8 \
  --connection-log-options Enabled=true,CloudwatchLogGroup=/aws/clientvpn/prod-access

# Alarm on tunnel state (0 = down) so the next drop pages on-call, not the next scan.
aws cloudwatch put-metric-alarm --alarm-name vpn-tunnel2-down \
  --namespace AWS/VPN --metric-name TunnelState \
  --dimensions Name=VpnId,Value=vpn-0a1b2c3d4e5f6a7b8 Name=TunnelIpAddress,Value=203.0.113.20 \
  --statistic Minimum --period 300 --evaluation-periods 1 \
  --threshold 1 --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:111122223333:network-oncall

Full walkthrough (console steps, edge cases and verification) in the lesson Secure Site-to-Site VPN connections.

Is EC2.183 a false positive?

Removing the failed status requires both tunnels to negotiate IKEv2 exclusively. Leaving ikev1 in the IkeVersions list keeps the finding open even if the active session is on v2, because the configuration still permits a downgrade.

Full lesson Secure Site-to-Site VPN connections Step-by-step remediation with CLI, code and persona-specific context.

AWS documentation for EC2 controls ↗ Check your own account for EC2.183 →

Part of the learning path Trim your network spend

EC2.1 An EBS snapshot is publicly restorable by any account
EC2.2 Default security groups still allow traffic
EC2.3 Attached EBS volumes are not encrypted at rest
EC2.4 Long-stopped instances are abandoned attack surface
EC2.6 No VPC flow logs, so there is no network audit trail
EC2.7 New EBS volumes are not encrypted by default
EC2.8 IMDSv1 lets an SSRF steal instance credentials
EC2.9 Instances are directly reachable on public IPv4
EC2.10 EC2 API traffic leaves the VPC over the internet
EC2.13 SSH (port 22) is open to the entire internet
EC2.14 RDP (port 3389) is open to the entire internet
EC2.15 Subnets auto-assign public IPs to new instances