Client VPN Endpoint local traffic routing disfunctional

Based on your description, it sounds like you're experiencing an issue with client-to-client communication in AWS Client VPN. This is likely related to how AWS Client VPN handles routing between clients.

For AWS Client VPN, there are a few key points to understand:

1. By default, the Client VPN endpoint NATs all traffic from clients to the elastic network interface (ENI) in the subnet. This NAT behavior provides one-way access where clients can reach the private network, but bidirectional connectivity between clients is not automatically supported.

2. While you've correctly set up a route with destination CIDR 172.16.48.0/20 with a target of local, there might be an issue with how the traffic is being routed between different subnets within your Client VPN CIDR range.

3. The issue you're seeing where clients in 172.16.48.* cannot communicate with clients in 172.16.49.* suggests that there might be limitations in how the local target handles routing across different subnets within the Client VPN CIDR block.

To address this issue, you could try:

1. Enable client-to-client access in your Client VPN endpoint configuration if it's available. This option specifically allows communication between clients connected to the same VPN endpoint.

2. Consider using a smaller subnet mask for your Client VPN CIDR to ensure all clients fall within the same subnet (e.g., use a /24 instead of /20).

3. Check if there are any security groups or network ACLs that might be blocking traffic between these IP ranges.

4. Verify that your authorization rules properly allow traffic between the Client VPN CIDR ranges.

If these solutions don't resolve the issue, it might indeed be a limitation of how AWS Client VPN handles routing between different subnets within the assigned CIDR range.
Sources
Bidirectional Client VPN Endpoint connectivity | AWS re:Post

Hello,

I understand you've configured a Client VPN endpoint with CIDR 172.16.48.0/20 and set up a local route, but clients in the 172.16.48. range cannot communicate with clients in the 172.16.49. range. Let me help you resolve this issue.

You have configured:

• Client VPN CIDR: 172.16.48.0/20
• Local route: 172.16.48.0/20 → local
• Authorization rules: 0.0.0.0/0 and 10.16.0.0/16 (Access all: true)
• VPC routing: Verified and working correctly

If there is any incorrect understanding, please feel free to reply from this answer.

Despite this configuration, clients cannot communicate with each other across different subnets within the VPN CIDR range.

Short-term Resolution (Immediate Action)

1.Enable Client-to-Client Traffic Option (Most Critical)

This is the most likely root cause of your issue. By default, AWS Client VPN uses iptables rules to block traffic between clients, even when a local route is configured. The "Enable client-to-client traffic" option must be explicitly activated.

To enable this option:

• Navigate to VPC Console → Client VPN Endpoints
• Select your endpoint → "Modify Client VPN endpoint"
• Check the "Enable client-to-client traffic" option
• Save changes and have clients reconnect

Without this option enabled, the local route you configured will not function for client-to-client communication. AWS Client VPN actively blocks inter-client traffic at the network layer unless this feature is explicitly enabled.

2. Authorization Rule Review

Verify that you have an explicit authorization rule for the Client VPN CIDR range itself (172.16.48.0/20). Your current rules allow 0.0.0.0/0 and 10.16.0.0/16, but you should add:

• Destination CIDR: 172.16.48.0/20
• Access: Authorize all groups

This ensures all connected clients have permission to send traffic to other clients within the VPN CIDR range.

3. Security Group Validation

The security group attached to your Client VPN endpoint must allow traffic from the Client VPN CIDR range: Required inbound rule:

• Source: 172.16.48.0/20
• Protocol: All traffic (or specific protocols like ICMP, TCP, SSH)
• Action: Allow

Self-referencing rule: Consider adding a rule where the security group allows traffic from itself, which effectively enables communication between all VPN clients.

4. VPC Route Table Validation

Verify the route tables in your data plane VPC:

• Identify which subnet is associated with your Client VPN endpoint
• Confirm the VPC's local route handles traffic appropriately
• Ensure no conflicting routes interfere with client-to-client communication

Long-term Resolution (Architectural Improvements)

1. Network Architecture Review

• Current architecture: AWS Client VPN uses NAT by default to process traffic from clients to the elastic network interface. This provides one-way access where clients can reach the private network, but bidirectional connectivity between clients requires the client-to-client feature enabled.
• Recommended pattern: Design your deployment with client-to-client communication in mind from the start. Plan CIDR ranges carefully to avoid conflicts with existing VPC networks and consider future scalability needs.

2. Split Tunnel Configuration Review

• Split tunnel behavior: If enabled, only traffic for explicitly pushed routes traverses the VPN tunnel. Verify that the route for 172.16.48.0/20 is being pushed to clients and properly installed in their local routing tables.
• Client-side verification: Clients should show a route directing traffic for the VPN CIDR range through the VPN interface. If this route is missing, clients will attempt to route traffic through their local network, which will fail.
• Full tunnel alternative: If client-to-client communication is critical and you're experiencing routing issues, consider full tunnel mode where all client traffic routes through the VPN.

3. Network ACLs Validation

• Subnet-level controls: Network ACLs are stateless and operate at the subnet level. The subnet associated with your Client VPN endpoint must have rules permitting traffic from and to 172.16.48.0/20.
• Required rules:
• Inbound: Allow traffic from 172.16.48.0/20
• Outbound: Allow traffic to 172.16.48.0/20

If using the default Network ACL (allows all traffic), this is unlikely your issue. However, custom ACLs require careful review.

Detailed Troubleshooting Process

Phase 1: Configuration Verification

• Client VPN Endpoint Settings: Examine your endpoint configuration focusing on client connect options to confirm whether client-to-client traffic is enabled. Verify the endpoint status shows "available" and check the VPN protocol, split tunnel settings, and DNS configuration.
• Route Table Examination: Confirm the local route for 172.16.48.0/20 is present, active, and shows target "local" with status "active." Check for conflicting routes with higher priority.
• Authorization Rules Audit: Review all authorization rules to ensure coverage for both VPC resources and the Client VPN CIDR range itself.

Phase 2: Connectivity Testing

• Basic tests: From one client, attempt to ping another client in a different subnet. Try multiple protocols (ping, SSH, HTTP) to determine if the issue is protocol-specific.
• Traceroute analysis: Perform traceroute to see where packets are dropped. In a properly configured setup, you should see a direct path through the VPN interface.
• Bidirectional testing: Test connectivity in both directions to rule out asymmetric routing issues.

Phase 3: Data Plane Verification

• ENI analysis: The Client VPN endpoint creates multiple ENIs (management, VPN, egress). Verify they are healthy with no errors.
• Security group review: Examine the security group attached to the VPN ENI in detail. It must allow traffic from 172.16.48.0/20 to itself.
• Source/destination check: Verify that source/destination checking is disabled on the VPN ENI to allow traffic forwarding between clients.

Additional Verification Points

1. Subnet Mask Is Not the Root Cause The suggestion to reduce your CIDR from /20 to /24 is not a fundamental solution. AWS Client VPN handles client-to-client communication across the entire assigned CIDR range when the feature is enabled. The issue is configuration, not subnet size.

2. CIDR Block Overlap Check Verify that 172.16.48.0/20 does not overlap with your data plane VPC CIDR or other connected networks. Overlap causes routing ambiguity.

3. Client Configuration Validation Windows/Linux/macOS: Verify that clients have the correct route for 172.16.48.0/20 pointing to the VPN interface. Check VPN client logs for errors and ensure clients use up-to-date AWS Client VPN software.

Summary and Next Steps

Immediate Actions:

• Enable the "client-to-client traffic" option on your Client VPN endpoint (most critical)
• Add authorization rule for 172.16.48.0/20 if missing
• Verify security group allows inbound traffic from 172.16.48.0/20
• Enable CloudWatch Logs for ongoing troubleshooting

Validation Steps:

• Have clients disconnect and reconnect after configuration changes
• Perform ping and SSH tests between clients in different subnets
• Review CloudWatch Logs to confirm successful authorization

Long-term Improvements:

• Review Network ACL configuration
• Document your Client VPN architecture including CIDR ranges, routing, and security controls
• Consider split tunnel vs. full tunnel based on your use case

Based on your symptoms, the most likely cause is that the "Enable client-to-client traffic" option is disabled. This option must be explicitly enabled for direct client communication, even with a local route configured. Once enabled and clients reconnect, the issue should be resolved.

Please let me know if you need clarification on any of these steps or if the issue persists after enabling client-to-client traffic.

Best regards, Dayeon Yang

Reference

• What is AWS Client VPN?: https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/
• AWS Client VPN routes: https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/cvpn-working-routes.html
• Control traffic to your AWS resources using security groups: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
• Configure route tables: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html