AWS Client VPN: Default route gets sucked into VPN
This is Hasegawa (@rarirureluis) from the Service Reliability Group (SRG) of the Media Headquarters.
#SRG(Service Reliability Group) is a group that mainly provides cross-sectional support for the infrastructure of our media services, improving existing services, launching new ones, and contributing to OSS.
The purpose of this article is to share the issues I encountered when setting up AWS Client VPN and to help others who may be experiencing the same problem.
AWS Client VPN default route is absorbed by VPNThe mystery of suddenly losing internet connectionAWS Client VPN: What it does behind the scenesHow to solve it by adding one lineHow pull-filter works and its advantages and disadvantagesmeritDisadvantagesWhat is TunnelCrack?Conclusion
AWS Client VPN default route is absorbed by VPN
Even though your only purpose is to access the VPC, all traffic ends up going through the VPN.
We'll explain how this problem can be solved by adding a single line to your client configuration.
The mystery of suddenly losing internet connection
A user suddenly lost internet connectivity immediately after successfully connecting to AWS Client VPN.
But it's fine in my environment.
Thinking, "I only want to access resources within the VPC...", you check the route table for the user in question and notice that for some reason the route to 0.0.0.0/0 is directed to the VPN's tun device.
I have split tunneling enabled, but for some reason all my traffic is being sucked into the VPN.
Why is this happening if I haven't added a default route on the server side?
AWS Client VPN: What it does behind the scenes
In fact, this is a "safety measure" implemented by AWS Client VPN.
If you read the official AWS documentation, you'll find the following:
If the client's LAN IP address range is outside the standard private IP address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or 169.254.0.0/16), the Client VPN endpoint automatically pushes the OpenVPN directive "redirect-gateway block-local" to the client, forcing all LAN traffic through the VPN.
This means that if your client device uses an IP address range other than those listed above, AWS Client VPN will force all traffic through the VPN "for security reasons."
This is done to increase security through your VPN connection, but can get in the way if you want to use split tunneling.
How to solve it by adding one line
To solve this problem, simply add the following line to your client configuration file (.ovpn file):
It works with the official AWS Client VPN software.
This setting will cause the server to ignore any "redirect-gateway block-local" directives sent by the server.
The actual configuration file looks like this:
After adding this setting, when you reconnect to the VPN, your internet traffic will flow through your local network while you maintain access to your AWS resources.
How pull-filter works and its advantages and disadvantages
Pull-filter is a feature available in OpenVPN 2.4 and later that selectively filters the settings pushed from the server.
It works with the official AWS Client VPN software.
The syntax is as follows:
pull-filter [accept|ignore|reject] "オプション"accept
ignore
reject
In this case, we are using ignore to silently ignore the redirect-gateway block-local instruction sent by the server.
merit
- Bandwidth savings: AWS Client VPN reduces bandwidth usage and costs by not routing all traffic over the VPN.
- Preserve existing configuration: Unlike route-nopull, you can ignore specific route configurations while preserving other route configurations.
Disadvantages
- Security considerations: Not sending all traffic through the VPN, which may be an issue depending on your security policies.
- Possibility of Tunnel Crack: One of the reasons AWS Client VPN enforces this setting is to protect against a security risk called "Tunnel Crack." Ignoring this setting could theoretically expose you to that risk.
What is TunnelCrack?
The following is an explanation by AI (DYOR)
The nature of the TunnelCrack vulnerability
TunnelCrack, which was announced in August 2023, refers to a group of fundamental vulnerabilities in the routing process of VPN clients. The following two types of attacks are at the core of the vulnerability:14：
LocalNet attack (CVE-2023-36672)
- Injecting fake local network routes via malicious access points
- Leaking traffic outside the VPN tunnel and intercepting plaintext communications
- CVSS score 6.8 (medium risk)
ServerIP Attack (CVE-2023-36673)
- DNS tampering to disguise the VPN server IP
- Intercepting traffic at the initial connection stage
- CVSS score 7.4 (high risk)
Security implications of pull-filter configuration
Using this is a double-edged sword in terms of the TunnelCrack vulnerability.
Benefits and trade-offs
- Disables local network traffic isolation, exposing vulnerability to LocalNet attacks
- However, encrypted communications such as HTTPS are protected.1
- OpenVPN officialFlagging is recommended, but it is not a complete solution4
Realistic Risk Assessment
- A successful attack requires a connection to a malicious network2
- Problems become apparent in high-risk environments such as when using public Wi-Fi
- In a trusted environment such as a corporate network, the risk is within the acceptable range.
Defense in depth in practice
If the vulnerability cannot be completely eliminated, recommended measures include:
- Application Layer Protection
- Enforcing TLS 1.3 on all services (using Let's Encrypt, etc.)1
- HSTS preload list enforcement
- Optimizing VPN settings
textredirect-gateway autolocal ipv6
block-outside-dns
tls-version-min 1.3- OS-level measures
- Block unexpected outbound traffic with the client firewall
- Enforcing DNS over HTTPS/TLS
Vendor support status
Status of major vendors (as of April 2025):
Conclusion
AWS Client VPN is a useful service, but under certain conditions it forces all traffic through the VPN.
This is due to the "redirect-gateway block-local" directive being pushed automatically.
By adding the pull-filter ignore "redirect-gateway block-local" to your client configuration, you can achieve split tunneling, directing only necessary traffic through the VPN and communication to the Internet via your local network.
SRG is looking for people to work with us.
If you're interested, please contact us here.