---
title: "Comment by Duko tools on \"AWS Client VPN with Mutual Authentication: A Complete Guide to Securely Access Private Resources\" | Hashnode"
description: "The note about needing to re-download the client config after changing routes/split-tunnel is the kind of gotcha that costs people an hour of confused debugging"
url: "https://hashnode.com/posts/aws-client-vpn/6a82d49f515b7ea804a0ef04/comment/6a845ffe83637f637b384046"
---

[Discussion](https://hashnode.com/posts/aws-client-vpn/6a82d49f515b7ea804a0ef04)

Comment [AWS Client VPN with Mutual Authentication: A Complete Guide to Securely Access Private Resources](https://hashnode.com/posts/aws-client-vpn/6a82d49f515b7ea804a0ef04)

[Duko tools](https://hashnode.com/@talha24ramzan)

[Aug 18](https://hashnode.com/posts/aws-client-vpn/6a82d49f515b7ea804a0ef04/comment/6a845ffe83637f637b384046)

The note about needing to re-download the client config after changing routes/split-tunnel is the kind of gotcha that costs people an hour of confused debugging, "why isn't my new route working" when the actual answer is a stale local profile, not a server-side misconfiguration.

The authorization-rules-are-deny-by-default point is worth emphasizing too, easy to assume a working VPN connection means access to everything in the VPC, when actually nothing's reachable until you explicitly allow the CIDR range. That's a good default from a security standpoint but a confusing one the first time you hit it.

Solid end-to-end walkthrough, the cert generation → ACM import → endpoint → authorization → route table sequence is exactly the order people get stuck skipping steps in.