NitWings
Lesson 243 · AWS Learning Path

AWS 243: AWS Client VPN operations and troubleshooting

· Published · 11 min read

Labelled process diagram for AWS 243: Remote client and identity to TLS and Client VPN endpoint to Authorization, route, and target VPC to Application connection and log evidence, with decision, proof and rejection...

Why this lesson matters

AWS Client VPN is a managed, OpenVPN-based remote-access service. A successful tunnel does not guarantee application access: TLS, user/device authentication, client address allocation, network authorization, endpoint routes, target return routes, security controls, DNS, and application health are separate gates.

This lesson teaches that chain for a Linux-capable beginner and the design tradeoffs an architect must own.

Outcomes

You will be able to:

  • explain endpoint, association, client CIDR, tunnel, route, authorization, and target controls;
  • compare mutual-certificate, Active Directory, and SAML authentication;
  • distinguish VPC-subnet and Transit Gateway association models;
  • operate split and full tunnel, IPv4/IPv6/dual-stack, DNS, SGs, NACLs, logs, and metrics;
  • diagnose TLS, authentication, authorization, routing, DNS, MTU, and client failures;
  • manage certificate renewal/revocation and profile distribution safely;
  • estimate association, connection, public IPv4, logging, Lambda, directory, TGW, and transfer cost;
  • produce correction, rollback, retest, prevention, and no-change proof.

Safety boundary

  • Do not create an endpoint for this lesson: endpoint associations and active connections are hourly billed.
  • Never publish a client private key, certificate bundle, .ovpn profile, SAML assertion, user/device IP, directory ID, or complete log entry.
  • Do not import certificates, CRLs, change authorization/routes, or terminate sessions.
  • Use fictional supplied cases. If inspecting an owned endpoint, use read-only metadata and redacted evidence.
  • Production remains untouched.

History and current service shape

  • 2018: AWS Client VPN launched as managed remote access using OpenVPN-compatible clients.
  • 2019: split tunnel allowed selected destination routes instead of forcing all IPv4 traffic through VPN.
  • 2020: AWS added its desktop client, SAML federation, self-service portal, and client-to-client connectivity.
  • 2026: Quickstart simplified initial setup; current endpoints support IPv4-only, IPv6-only, and dual-stack choices, and can integrate directly with Transit Gateway. AWS VPN Client 6 added GUI/CLI parity and administration controls.

Old profiles and endpoints remain operationally relevant. Check endpoint creation/configuration and client version instead of assuming the newest behavior.

End-to-end control chain

device network/DNS
  -> endpoint public DNS and TLS server certificate
  -> client/user authentication
  -> client IP allocation and session
  -> authorization rule for destination
  -> Client VPN route
  -> VPC-subnet association or TGW attachment
  -> SG/NACL/firewall and destination route
  -> application
  -> return path to client

Troubleshoot top to bottom. A connected session proves the first gates, not the later ones.

Endpoint and client address design

The endpoint is Regional. Its server certificate must be in ACM in that Region. Endpoint address type controls the protocol clients use to reach the endpoint; traffic IP type controls traffic between clients and destinations.

For classic IPv4 design, the client CIDR:

  • must be between /22 and /12;
  • cannot overlap associated VPC CIDRs or manually added endpoint routes;
  • cannot be changed after endpoint creation;
  • should contain roughly twice the addresses required for planned concurrent users because the service reserves addresses for availability.

Current service options include IPv4, IPv6, and dual-stack. IPv6 traffic preserves client IPv6 source and is not NATed. Check current modification limits: some endpoint/traffic IP combinations require replacement, and IPv6 client-to-client communication has restrictions.

In the VPC-subnet model, client IPv4 traffic is source translated to an endpoint ENI address while the original source port is normally retained (with port translation as needed for collision). Consequently, target logs/SG design may see endpoint addresses or endpoint SG context rather than the user's internet address.

Two network-infrastructure models

VPC-subnet association

Associate at least one subnet for connectivity. Multiple associations improve availability, but all associated subnets must be in one VPC and only one subnet per Availability Zone is allowed.

Associations create Client VPN ENIs. The endpoint becomes available after association. The VPC's default SG is initially applied unless changed; use a dedicated endpoint SG and allow target SG ingress from it where supported.

Endpoint routes require a destination and target association subnet. For reliable behavior, every associated subnet must have the same route destinations. A route to a peered VPC, S3, on-premises, or internet also needs the corresponding VPC/TGW/VPN/gateway route and return path.

Direct Transit Gateway association

A current endpoint can attach natively to one same-Region Transit Gateway for multi-VPC/hybrid access. It cannot mix TGW and VPC-subnet associations.

Important differences:

  • Client source IP is preserved; Client VPN does not SNAT.
  • SG-based authorization on Client VPN associations is not supported; use network authorization and downstream controls.
  • Endpoint routes are manually defined; TGW routes do not automatically populate them.
  • Return routes in attached VPCs must send client CIDRs to TGW.
  • TGW association/propagation and non-overlapping attachment CIDRs still apply.
  • Cross-account TGW must be shared through RAM; cross-Region TGW peering is not the Client VPN attachment target.

Choose VPC association for simple single-VPC termination and SG referencing. Choose TGW association for centralized remote-user routing when preserved source addresses and TGW governance fit.

Authentication: who may form a session

Every endpoint needs a TLS server certificate. Client authentication can be:

MethodIdentity proofOperational ownership
Mutual authenticationClient certificate signed by trusted CAPKI issuance, private-key protection, CRL/revocation
Active DirectoryDirectory username/password; MFA through supported directory setupDirectory Service/AD health, groups, MFA
SAML federationSigned SAML assertion from one configured IdPIAM SAML provider, IdP app/metadata/groups/MFA

Mutual authentication can be combined with AD or SAML; then both must pass. Authentication method and client certificate configuration have creation-time limits - do not promise an in-place conversion without checking current modification support.

Mutual TLS

The server certificate and chain are in ACM. Client private keys remain on protected devices/credential stores. Prefer per-user/device client certificates so one identity can be revoked rather than sharing one key.

Check certificate validity, key usage/chain, trusted CA, client clock, CRL validity/content, and endpoint propagation. Failed mutual-auth attempts are not recorded in Client VPN connection logs, so client TLS logs and PKI evidence are essential.

Active Directory and SAML

AD authentication uses AWS Directory Service and can integrate supported MFA. The directory and endpoint account relationship matters.

SAML requires signed response/assertion, correct ACS/audience, validity times, email-format NameID, and exact case-sensitive memberOf attribute for group authorization. The AWS-provided client is required for federated browser flow and reserves local TCP port 35001 for the response. IdP MFA is supported.

Monitor changes to IAM SAML provider metadata: a wrong/malicious URL can break login or create phishing risk. Certificate/metadata updates can take hours to propagate.

Authorization is separate from authentication

Network-based authorization rules allow a destination CIDR to all clients or to an AD/SAML group. A route does not grant access; an authorization rule does not create a route. Both must exist.

For each requested destination prove:

  1. Authenticated identity and group claim.
  2. Authorization destination covers the traffic.
  3. Endpoint route covers the traffic.
  4. Association/TGW and destination route provide forward/return path.
  5. SG/NACL/firewall allows the translated or preserved source.
  6. Application listens and authorizes at its own layer.

Avoid broad 0.0.0.0/0 authorization simply to diagnose. Group IDs - not friendly names - must match the provider/directory output.

Split tunnel and full tunnel

With split tunnel enabled, endpoint route destinations are pushed into the client route table at connection establishment. Other traffic follows the client's local network.

Without split tunnel, the client is normally given a default 0.0.0.0/0 route through VPN. Internet access then requires endpoint default route, matching authorization, target/VPC internet path, DNS, and security controls.

Adding 0.0.0.0/0 to a split-tunnel endpoint defeats the design and can disrupt connectivity. Any endpoint route-table modification while split tunnel is enabled resets client connections. Schedule and communicate changes, test duplicate routes across associations, and have rollback.

Split tunnel reduces AWS egress and preserves local internet performance but allows simultaneous local and corporate paths. Full tunnel centralizes inspection/control but adds bandwidth, latency, NAT/public IPv4, and outage blast radius.

DNS and client profile

The endpoint can push DNS server IPs. Those servers must be reachable through a route and authorization rule, and UDP/TCP 53 must pass controls. For Route 53 private zones, use a VPC Resolver-capable design or Resolver endpoints/rules for hybrid names.

Distinguish:

  • failure resolving Client VPN endpoint public DNS before tunnel;
  • successful tunnel but failure resolving private application name;
  • correct DNS answer but unreachable destination.

The exported profile identifies endpoint, transport, certificates, and options. remote-random-hostname intentionally prevents endpoint-IP caching by prepending random labels; pinging the configured endpoint DNS is not a valid service test.

Profiles with embedded client private keys are secrets. Use secure distribution, device management, filesystem permissions, revocation, and version ownership. AD clients may require profile redistribution after enabling MFA. SAML users can use the self-service portal where configured; mutual-only authentication does not support that portal.

Connection lifecycle, logs, and metrics

Connection logging publishes JSON events to CloudWatch Logs for attempts, connections, resets, updates, and disconnects. Fields can include endpoint/connection IDs, status/failure reason, assigned client IP, certificate common name, device type/public IP, port, and timestamps. Treat these as identity/security data.

Again, failed mutual authentication attempts are not logged there.

Use:

  • endpoint and target-association state/status messages;
  • describe-client-vpn-connections for active session metadata;
  • connection logs for time/user/status;
  • client OpenVPN/AWS VPN Client logs for DNS/TLS/auth/route injection;
  • VPC Flow Logs on endpoint/target ENIs;
  • CloudWatch Client VPN connection, authentication, bytes/packets metrics where available;
  • CloudTrail for control-plane changes;
  • directory/IdP, Resolver, firewall, and application logs.

Endpoint changes - including certificates, DNS, split mode/routes, CRL, authorization, and port - can reset sessions and may take up to four hours to take effect. Separate propagation from a failed repair.

Safe read-only CLI

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text

aws ec2 describe-client-vpn-endpoints +  --query 'ClientVpnEndpoints[].{Id:ClientVpnEndpointId,Status:Status.Code,ClientCidr:ClientCidrBlock,EndpointIp:EndpointIpAddressType,TrafficIp:TrafficIpAddressType,Transport:TransportProtocol,Split:SplitTunnel,Dns:DnsServers,ServerCert:ServerCertificateArn,Auth:AuthenticationOptions,Tgw:TransitGatewayId,Log:ConnectionLogOptions}'

aws ec2 describe-client-vpn-target-networks +  --client-vpn-endpoint-id cvpn-endpoint-REDACTED
aws ec2 describe-client-vpn-routes +  --client-vpn-endpoint-id cvpn-endpoint-REDACTED
aws ec2 describe-client-vpn-authorization-rules +  --client-vpn-endpoint-id cvpn-endpoint-REDACTED
aws ec2 describe-client-vpn-connections +  --client-vpn-endpoint-id cvpn-endpoint-REDACTED +  --query 'Connections[].{Id:ConnectionId,User:Username,ClientIp:ClientIp,Status:Status.Code,Start:ConnectionEstablishedTime,Last:ConnectionEndTime}'

Do not export a client profile or show full authentication options in shared evidence. Redact IDs, users, IPs, certificate ARNs, and log destination.

Linux client evidence:

ip -brief address
ip route show
resolvectl status
getent ahosts internal.example.invalid
curl --connect-timeout 5 -I https://internal.example.invalid/
journalctl --since '15 minutes ago' -u openvpn-client@PROFILE

Never upload the journal without reviewing/redacting credentials and identity data.

Troubleshooting decision tree

  1. Endpoint name does not resolve/reach: local DNS/firewall, ISP/captive portal, endpoint DNS/profile/transport.
  2. TLS fails: server validity/chain/Region, client cert/key/CA/CRL, clock, protocol/client compatibility.
  3. User authentication fails: AD/IdP health, MFA, assertion size/signature/time/audience, browser/port 35001, group attribute.
  4. No client IP/session: endpoint/association state, client CIDR capacity/overlap, quotas.
  5. Session connects but one network fails: authorization destination/group, endpoint route, association/TGW route, return path.
  6. IP works but name fails: pushed DNS, route/authorization to resolver, TCP/UDP 53, private-zone/rule association.
  7. Intermittent: unequal routes among associations, one AZ path, stale client routes, propagation, MTU, endpoint bandwidth/quota, DNS.
  8. Large transfers fail: MTU/path-MTU discovery, fragmentation/firewall, packet loss; test controlled sizes rather than applying a magic MTU globally.

Change one layer under approval, preserve original configuration, reconnect if required, and retest authentication, route, DNS, app, and return path.

Practical investigation

Download:

Diagnose all eight failures without changing AWS. Each answer requires first failed gate, safe evidence, smallest correction, rollback, retest, and prevention.

Cost, resilience, and cleanup

Client VPN charges each endpoint association and each active connection by the hour. Current pricing also calls out public IPv4 charges for tunnel addresses where applicable. Additional owners include:

  • data transfer and internet/NAT path;
  • TGW attachment/data processing;
  • CloudWatch Logs/metrics;
  • Lambda client-connect handler;
  • Directory Service/IdP dependencies;
  • ACM/private PKI lifecycle and Route 53 Resolver.

More AZ associations improve capacity/availability and increase association cost. Full tunnel can increase AWS processing/egress; split tunnel changes security exposure. Price the exact Region, associations, average concurrent connection-hours, address family, transfer path, and logging.

This lesson creates nothing. Match before/after endpoint, association, route, authorization, session, log-group, Lambda, certificate, EIP, and TGW inventories.

Knowledge check

  1. What does a connected tunnel prove and not prove?
  2. Why must client CIDR avoid every routed destination?
  3. Compare VPC-subnet and TGW association source-address/security behavior.
  4. Why are route and authorization both required?
  5. When must both certificate and user authentication pass?
  6. Why can failed mutual auth be absent from connection logs?
  7. What route changes reset split-tunnel sessions?
  8. Why is 0.0.0.0/0 usually wrong in split mode?
  9. Which evidence separates endpoint DNS from private application DNS failure?
  10. Why does one healthy association not prove multi-AZ consistency?
  11. What certificate/profile material is secret?
  12. Which dimensions drive cost and resilience?

Lesson acceptance

A passing submission includes endpoint/IP/association model; all authentication layers; exact route plus authorization; forward/return and SG/NACL path; split/full-tunnel reasoning; DNS/profile/certificate lifecycle; logs/metrics and blind spots; all eight supplied cases; correction/rollback/retest/prevention; current cost evidence; no sensitive material; and no-change/production-untouched proof.

Official sources

View complete AWS learning path
Advertisement