AWS Security Hub · EC2
EC2.51: Client VPN endpoints should log connections
Written and reviewed by Emnode · Last reviewed
What does AWS Security Hub EC2.51 check?
EC2.51 fails any Client VPN endpoint whose ConnectionLogOptions.Enabled flag is false — the default when you create an endpoint and skip the logging settings. It is change-triggered, backed by the AWS Config rule ec2-client-vpn-endpoint-client-logging-enabled, so a fix clears the finding almost immediately.
Why does EC2.51 matter?
A Client VPN endpoint is a remote-access door from the internet into your VPCs. Connection logging records who connected, when, from which source IP, and when they disconnected — the audit trail you need to answer "who was on the VPN when the breach happened?" Without it, that question has no answer, and NIST 800-53, NIST 800-171, and PCI DSS all treat remote-access logging as table stakes.
How do I fix EC2.51?
- Audit every Client VPN endpoint across all regions and read ConnectionLogOptions.Enabled.
- Create or reuse a dedicated CloudWatch Logs group such as /aws/clientvpn/<purpose> and set an explicit retention policy.
- Run modify-client-vpn-endpoint with --connection-log-options Enabled=true,CloudwatchLogGroup=<group> for each flagged endpoint — the change is non-disruptive.
- Bake ConnectionLogOptions into the Terraform/CloudFormation/CDK module so new endpoints ship with logging on.
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-oncallFull walkthrough (console steps, edge cases and verification) in the lesson Secure Site-to-Site VPN connections.
Is EC2.51 a false positive?
Connection logging is distinct from VPC flow logs — it records session-level access events, not packet-level flow. Satisfying EC2.51 does not satisfy any flow-logging control, and having flow logs on the associated subnets does not satisfy EC2.51.
More EC2 controls
- 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