- 最新
- 最多得票
- 最多評論
Your route table looks fine but I think the problem here is DNS. What is your DNS server set to?
You can check that the split tunnel is working correctly by doing a ping
to a working external IP address. That's easy to find - when the VPN isn't running do ping www.amazon.com
and take note of the IP address. With the VPN running do ping <IP address>
and see if you get a response. If you do then DNS is definitely the issue.
Make sure that you can reach your DNS server when on the VPN. If the DNS server is in the VPC then it needs to be able to resolve IP addresses and return responses to your computer via the VPN tunnel.
When you enable split-tunnel mode, all the routes in the Client VPN endpoint's route table are added to the client's route table when the VPN connection is established. This operation is different from the default behavior, which overwrites the client's route table with the entry 0.0.0.0/0 to route all traffic over the VPN.
I am assuming the above route table is on your on-premise end. It is not recommended to add a 0.0.0.0/0 route to the Client VPN endpoint's route table when using split-tunnel mode.
Can you confirm if you have added the same ? If yes, can you remove 0.0.0.0/0 and try ?
For the benefit of others I will answer this as i was able to resolve it. The issue here was that I was not fully aware of the proper DNS setting when set vs left empty, to allow the DNS IP address configured on the end user's device to take care of resolving DNS queries. A good article that explains exactly the DNS settings can be found here. In my case it was completely optional as I didn't need to use any specific DNS for my setup, also only needed certain traffic to go through the vpn. I had other hardware routing issues, which could have been also contributing to part of the problem.
my problem is similar and started with AWS VPN client 3.10. I have split-tunnel enabled, and have had client vpn endpoints working with split-tunnel enabled since 2019.
When I upgrade to vpn client 3.10 or newer, my default gateway changes to route all traffic over the vpn, even though split tunnel is enabled.
I roll back to vpn client 3.9.0 and this behavior goes away.
相關內容
- 已提問 2 個月前
- AWS 官方已更新 2 年前
- AWS 官方已更新 1 年前
- AWS 官方已更新 1 年前
- AWS 官方已更新 2 年前
Thank you! I was able to resolve the issue. The idea behind using split tunnel for me is to avoid having non-aws traffic going through the vpn tunnel, as I have a private subnet with no internet access. I wanted to take advantage of the endpoint route table copied on the client side. Note that I have 3 different vpn client endpoints with split tunnel and they all work. After reviewing my work and some trial and error apparently having the client cidr overlap with the VPC, where the client is configured will cause this issue. Overlap documented but didn't realize will cause such issue.
I'm having this exact issue. In order to get internal DNS resolution to work, I utilized AWS Route53 Resolver. In configuring the Client VPN Endpoint, I specified the IP addresses of the AWS Resolver Inbound Endpoint. That enabled me to resolve internal hostnames while on the VPN. However, I am now not able to resolve external DNS queries. I have split tunnel enabled. I can resolve the issue by adding an Authorization Rule on the VPN Client to allow traffic to 0.0.0.0/0, but I don't want to do that for security reasons, and don't think I should have to with the split tunnel solution. Do you have any advice?
Honestly I think AWS support need to look into this issue and do enough testing to understand the reason behind such an intermittent problem. Today suddenly everything is working fine. I was doing some testing with different vpn endpoints, and I haven't figured out the reason this is happening, yet. I would say first thing is avoid the 0.0.0.0/0 entry, since it will copy the client route table to your local machine, as with that you might have issues trying to figure out whats going on. I had to delete my answer below as now the CIDR overlap is no longer to be the issue I guess.