If you're experiencing issues with your AWS services, then please refer to the AWS Health Dashboard. You can find the overall status of ongoing outages, the health of AWS services, and the latest updates from AWS engineers.
Securing Remote Access with AWS Client VPN Client Routes Enforcement
This article explains Client Routes Enforcement (CRE), a feature of AWS Client VPN that prevents end users from overriding or bypassing VPN-pushed routes on their local devices. Before CRE, administrators configured routes on the Client VPN endpoint, but users with local administrator privileges on their devices could modify their local routing tables to send traffic outside the VPN tunnel. This article covers the problem CRE solves, how it works, how to set it up, and how to verify it.
Table of Contents
- Problem Statement
- What Is Client Routes Enforcement?
- Architecture Overview
- How CRE Works (Workflow)
- Prerequisites
- Implementation Guide
- Verification
- Limitations and Considerations
- Summary
1. Problem Statement
AWS Client VPN allows remote users to connect to AWS VPCs and on-premises networks through an OpenVPN-based TLS tunnel. Administrators define routes on the Client VPN endpoint that get pushed to connected clients. These routes tell the client operating system which destination CIDRs to send through the VPN tunnel.
The problem: a user with local administrator access on their device can modify their routing table after connecting. They can add a more specific route that directs traffic to their local internet gateway instead of the VPN tunnel. This creates two risks.
First, it breaks network security controls. Traffic that the organization intended to inspect, filter, or log through centralized security appliances in the VPC bypasses those controls entirely. An employee connecting from a coffee shop, for example, could route corporate application traffic over the public internet instead of through the encrypted tunnel and the organization's inspection stack.
Second, it creates a data exfiltration path. If a user can selectively route traffic outside the tunnel, they can send data to destinations that the organization's network security policies would otherwise block. Without CRE, the Client VPN endpoint has no mechanism to detect or prevent this behavior because route enforcement happened at the client OS level, where the user had full control.
2. What Is Client Routes Enforcement?
Client Routes Enforcement is a configuration option on the AWS Client VPN endpoint that instructs the AWS-provided VPN client application to lock down the routing table on the connected device. When CRE is active, the AWS VPN client enforces that all routes pushed by the server remain in the client's routing table for the duration of the VPN session. The client application prevents local modifications to those routes and blocks attempts to add conflicting routes that would divert traffic away from the tunnel.
CRE operates at the application level within the AWS VPN Client software. It does not require kernel drivers or OS-level agents beyond the standard AWS VPN Client. When the client connects and receives the route table from the server, it activates route protection. If a user or process attempts to alter the protected routes, the AWS VPN Client detects the change and either blocks it or restores the original routes.
This feature works with both split-tunnel and full-tunnel configurations. In split-tunnel mode, CRE ensures that traffic destined for the specified CIDRs goes through the tunnel and cannot be rerouted locally. In full-tunnel mode (where all traffic routes through the VPN), CRE prevents users from adding split routes that would send specific traffic outside the tunnel.
3. Architecture Overview
The architecture involves four components that interact during a CRE-enforced VPN session.
The first component is the AWS Client VPN Endpoint, which is the server-side resource deployed in your AWS account. It holds the VPN configuration, including the route table, authorization rules, and the CRE setting. The endpoint associates with one or more subnets in your VPC, and each association creates an elastic network interface (ENI) in that subnet.
The second component is the AWS VPN Client application running on the user's device (Windows, macOS, or Linux). This application establishes the OpenVPN TLS tunnel to the endpoint. When CRE is active, the client application takes on the additional responsibility of monitoring and enforcing the local routing table.
The third component is the VPC route infrastructure. Traffic that enters the VPN endpoint ENI routes according to the VPC route table, security groups, and network ACLs associated with the endpoint's subnet. From there, traffic can reach other subnets in the VPC, peered VPCs, Transit Gateway-attached networks, or on-premises networks through AWS Direct Connect or Site-to-Site VPN.
The fourth component is the authentication and authorization layer. Client VPN supports Active Directory authentication, mutual TLS (certificate-based), SAML-based federated authentication, or a combination. Authorization rules control which network CIDRs a connected user can access. CRE works alongside these controls: authorization rules determine what a user is allowed to reach, and CRE ensures the user's traffic for those destinations actually traverses the tunnel.
Architecture Overview
┌─────────────────────────────────────────────────────────────────────┐
│ End-User Device │
│ │
│ ┌──────────────┐ ┌──────────────────────┐ │
│ │ Applications│────▶│ OS Routing Table │ │
│ └──────────────┘ │ ┌────────────────┐ │ │
│ │ │ VPN Routes │ │ │
│ ┌──────────────┐ │ │ (admin-defined)│ │ │
│ │ Other │────▶│ ├────────────────┤ │ │
│ │ Processes │ │ │ Local Routes │ │ │
│ └──────────────┘ │ │ (LAN, default) │ │ │
│ │ └────────────────┘ │ │
│ └──────────┬───────────┘ │
│ │ │
│ ┌──────────▼───────────┐ │
│ │ CRE Monitor Engine │◀── Continuously │
│ │ (AWS VPN Client) │ monitors routes │
│ │ │ │
│ │ • Detects conflicts │ │
│ │ • Removes bad routes │ │
│ │ • Restores originals │ │
│ └──────────┬───────────┘ │
│ │ │
│ ┌──────────▼───────────┐ │
│ │ AWS Client | |
| | VPN Tunnel │ |
│ │ │ │
│ └──────────┬───────────┘ │
└──────────────────────────────────┼──────────────────────────────────┘
│
┌──────────▼───────────┐
│ AWS Client VPN │
│ Endpoint │
│ │
│ CRE Setting: │
│ Enforced = true │
└──────────┬───────────┘
│
┌──────────────┼──────────────┐
│ │ │
┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
│ VPC │ │ On-Prem │ │ Internet │
│ Subnets │ │ Network │ │ (via NAT)│
│ 10.0.0/24│ │ (via VGW)│ │ │
└───────────┘ └───────────┘ └───────────┘
4. How CRE Works (Workflow)
The CRE workflow follows six steps from connection initiation to active enforcement.
Step 1: The user launches the AWS VPN Client and initiates a connection to the Client VPN endpoint. The client performs TLS handshake and authenticates the user through the configured authentication method (certificate, Active Directory, SAML, or a combination).
Step 2: After authentication succeeds, the Client VPN endpoint pushes the VPN configuration to the client. This configuration includes the route table (which CIDRs to send through the tunnel), DNS settings, and the CRE enforcement flag. The CRE flag tells the client application that route enforcement is active for this session.
Step 3: The AWS VPN Client installs the pushed routes into the device's operating system routing table. Each route points the specified CIDR to the VPN tunnel interface as the next hop.
Step 4: The AWS VPN Client activates route protection. It records the installed routes as protected entries and begins monitoring the routing table for changes. The specific enforcement mechanism varies by operating system, but the result is the same: protected routes cannot be modified or overridden by the user or other processes on the device.
Step 5: During the active session, all traffic destined for protected CIDRs enters the VPN tunnel. The traffic arrives at the Client VPN endpoint ENI in the VPC subnet. From there, it routes according to VPC route tables, security group rules, and network ACLs, reaching the intended destination within AWS or on-premises networks.
Step 6: If a user or process attempts to modify a protected route (for example, by running "route add" or "ip route" commands to override a VPN route), the AWS VPN Client blocks the modification. The route remains pointed at the VPN tunnel. The client logs the attempted modification for troubleshooting purposes.
When the user disconnects, the AWS VPN Client removes the VPN routes and deactivates route protection, restoring the device's routing table to its pre-connection state.
How It Tracks User-Added/Modified Routes
┌────────────────────────────────────────────────────────────────────────────┐
│ CLIENT DEVICE (Windows/macOS/Ubuntu) │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ AWS VPN CLIENT (v5.2.0+) │ │
│ │ │ │
│ │ ┌───────────────┐ ┌─────────────────────────────────────────┐ │ │
│ │ │ VPN Session │ │ CRE MONITORING ENGINE │ │ │
│ │ │ Manager │ │ │ │ │
│ │ │ │ │ 1. On connect: snapshot the │ │ │
│ │ │ • Receives │────▶│ "expected" route table from │ │ │
│ │ │ server- │ │ server-pushed routes │ │ │
│ │ │ pushed │ │ │ │ │
│ │ │ routes │ │ 2. Continuously poll the OS │ │ │
│ │ │ │ │ main routing table │ │ │
│ │ └───────────────┘ │ │ │ │
│ │ │ 3. Compare current routes vs │ │ │
│ │ │ expected routes │ │ │
│ │ │ │ │ │
│ │ │ 4. If CONFLICT detected: │ │ │
│ │ │ → Remove conflicting route │ │ │
│ │ │ → Restore expected VPN route │ │ │
│ │ └──────────────┬──────────────────────────┘ │ │
│ │ │ │ │
│ └───────────────────────────────────────┼─────────────────────────────┘ │
│ │ │
│ ┌───────────────────────────────────────▼─────────────────────────────┐ │
│ │ OS MAIN ROUTING TABLE │ │
│ │ │ │
│ │ Dest Next Hop Interface Status │ │
│ │ ────────────── ───────────────── ────────── ────────── │ │
│ │ 10.0.0.0/16 VPN Gateway tun0 ✅ Protected │ │
│ │ 172.16.0.0/12 VPN Gateway tun0 ✅ Protected │ │
│ │ 172.31.1.0/24 Local Gateway eth0 ❌ CONFLICT! │ │
│ │ ▲ │ │ │
│ │ │ User/app added this route that overlaps │ │ │
│ │ │ with VPN route [IP_ADDRESS] │ │ │
│ │ │ ▼ │ │
│ │ │ CRE REMOVES THIS │ │
│ │ │ & RESTORES VPN ROUTE │ │
│ └──┼──────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌──┴─────────────────────────────────────────────────────────────────┐ │
│ │ IGNORED ROUTES (CRE does NOT touch these): │ │
│ │ • 127.0.0.0/8 (loopback) │ │
│ │ • 169.254.0.0/16 (link-local / DHCP) │ │
│ │ • 224.0.0.0/4 (multicast) │ │
│ │ • 255.255.255.255 (broadcast) │ |
│ │ • ::1/128 (IPv6 loopback) │ │
│ │ • fe80::/10 (IPv6 link-local) │ │
│ │ • ff00::/8 (IPv6 multicast) │ │
│ └────────────────────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────────────────┘
Conflict Detection Logic
The CRE engine detects conflicts using CIDR overlap comparison. Here's how:
ADMIN CONFIGURES VPN ROUTE
┌──────────────────────┐
│ 172.31.0.0/16 │
│ (via VPN tunnel) │
└──────────┬───────────┘
│
┌──────────▼───────────┐
│ CRE stores this as │
│ "expected" route │
└──────────┬───────────┘
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
┌────────────────┐ ┌──────────────┐ ┌──────────────────┐
│ User adds: │ │ User adds: │ │ User adds: │
│ 172.31.1.0/24 │ │ 10.0.0.0/8 │ │ 192.168.1.0/24 │
│ via local GW │ │ via local GW │ │ via local GW │
└───────┬────────┘ └──────┬───────┘ └────────┬─────────┘
│ │ │
▼ ▼ ▼
┌────────────────┐ ┌──────────────┐ ┌──────────────────┐
│ ❌ CONFLICT! │ │ ✅ NO │ │ ✅ NO │
│ 172.31.1.0/24 │ │ CONFLICT │ │ CONFLICT │
│ overlaps with │ │ (different │ │ (no overlap with │
│ 172.31.0.0/16 │ │ network) │ │ VPN routes) │
│ │ │ │ │ │
│ → CRE REMOVES │ │ → Allowed │ │ → Allowed │
│ this route │ │ │ │ │
└────────────────┘ └──────────────┘ └──────────────────┘
A conflict occurs when a more-specific route (longer prefix) overlaps with a VPN route and points to a non-VPN gateway. The more-specific route would normally take precedence in IP routing, effectively bypassing the VPN tunnel. CRE detects and removes it.
5. Prerequisites
Before configuring CRE, confirm the following requirements are met.
| Requirement | Detail |
|---|---|
| AWS VPN Client version | Version 4.0.0 or later on Windows, macOS, or Linux. Earlier versions do not support CRE and will ignore the enforcement flag. |
| Client VPN endpoint | An existing Client VPN endpoint, or you will create one during setup. CRE is a property of the endpoint configuration. |
| Authentication | At least one authentication method configured (mutual TLS, Active Directory, or SAML federation). |
| Route table | At least one route configured on the Client VPN endpoint. CRE enforces the routes that exist in the endpoint's route table. |
| Authorization rules | At least one authorization rule granting access to a target network CIDR. Without authorization rules, users authenticate but cannot reach any network. |
| IAM permissions | The administrator configuring CRE needs permissions for the ec2:ModifyClientVpnEndpoint and ec2:CreateClientVpnEndpoint API actions. |
6. Implementation Guide
6.1 Enable CRE on a New Client VPN Endpoint
-
Open the Amazon VPC console at https://console.aws.amazon.com/vpc/. In the left navigation pane, choose Client VPN Endpoints, then choose Create Client VPN Endpoint.
-
Configure the endpoint with your desired settings (server certificate, authentication, client CIDR, VPC, subnets, DNS, and so on). In the "Other parameters" or "Additional configuration" section, locate the Client Routes Enforcement option and set it to Enabled.
-
Choose Create Client VPN Endpoint. After the endpoint reaches the "Available" state, add routes and authorization rules as needed.
6.2 Enable CRE on an Existing Client VPN Endpoint
- Open the Amazon VPC console. Choose Client VPN Endpoints. Select the endpoint you want to modify. Choose Actions, then Modify Client VPN Endpoint.
- Locate the Client Routes Enforcement setting and change it to Enabled. Choose Modify Client VPN Endpoint.
- Active sessions are not affected immediately. Users must disconnect and reconnect for CRE to take effect on their session.
6.3 Add Routes and Authorization Rules
- After enabling CRE, add the routes you want enforced on client devices. Each route you add to the endpoint's route table will be pushed to clients and protected by CRE.
7. Verification
After enabling CRE and connecting a client, verify enforcement is working with these steps.
Step 1: Connect to the Client VPN endpoint using the AWS VPN Client (version 4.0.0 or later). Confirm the connection succeeds and the status shows "Connected."
Step 2: On the client device, inspect the routing table to confirm VPN routes are installed.
On Windows:
route print
On macOS/Linux:
netstat -rn or ip route show
Verify that the routes pushed by the endpoint (for example, 10.0.0.0/16) point to the VPN tunnel interface (for example, utun3 on macOS or a tun/tap interface on Linux).
Step 3: Attempt to override a protected route. This step confirms CRE is blocking modifications.
On Linux:
sudo ip route replace 10.0.0.0/16 via <local-gateway-ip>
The command will either fail or the AWS VPN Client will immediately restore the original route. Check the AWS VPN Client logs to confirm the enforcement action.
Step 4: Test connectivity to a resource in the protected CIDR to confirm traffic flows through the tunnel.
ping 10.0.1.50 traceroute 10.0.1.50
The traceroute output will show the traffic entering the VPN tunnel rather than going through the local internet gateway.
8. Limitations and Considerations
- CRE enforces routes at the AWS VPN Client application level. It does not install kernel-level drivers or modify OS firewall rules. A user with deep technical knowledge and root/administrator access to their device could terminate the AWS VPN Client process and manually configure routes. CRE is a deterrent and enforcement mechanism for standard use, not a replacement for endpoint security solutions (EDR, MDM) in high-security environments.
- CRE requires the AWS-provided VPN Client application. Organizations that allow third-party OpenVPN-compatible clients will not get CRE enforcement on those clients. To enforce CRE across the organization, restrict users to the AWS VPN Client.
- CRE takes effect at connection time. If you enable CRE on an endpoint that has active sessions, those sessions are not affected until the users disconnect and reconnect. Plan a maintenance window or notify users to reconnect after enabling CRE.
- CRE does not replace authorization rules. Authorization rules control which CIDRs a user is permitted to access. CRE controls whether the user's traffic for those CIDRs goes through the tunnel. Both are needed for a complete security posture.
- CRE does not inspect or filter traffic content. It enforces routing paths, not traffic policies. For content inspection, use security groups, network ACLs, AWS Network Firewall, or third-party inspection appliances in the traffic path.
9. Summary
Client Routes Enforcement is a meaningful security improvement for organizations using AWS Client VPN. It addresses the real-world problem of VPN traffic leaks caused by route table modifications on end-user devices — whether accidental, automated, or malicious.
Key takeaways:
- Continuously monitors and auto-remediates routing table changes on connected devices
- Supports both IPv4 and IPv6 (with appropriate client versions)
- Works with both split-tunnel and full-tunnel configurations
- No additional cost
- Simple to enable via Console, CLI, or IaC
- Active only while the VPN tunnel is open; scoped to the main routing table
For the official documentation, see:
- Tags
- AWS Client VPN
- Language
- English
Relevant content
- asked 2 years ago
- AWS OFFICIALUpdated a year ago
