Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Client VPN Endpoints - VPC vs. Client VPN Endpoints - TG

0

We are a small company (50 employees). We currently run Client VPN Endpoints - VPC version which authenticates users using Federated Access to our Active Directory.

We have 5 accounts in our AWS Org and use 3 Regions in each account. US-East-1, US-West-2, and EU-West-1. This gives us 3 Transit Gatways in our Org.

One of our biggest challenges is knowing the IP of the User / Group they authenticated with. Back in the days of using a Fortinet VPN you could assign an IP range to the Group the users authenticated with and then you could easily control access based on that range. With AWS Client VPN, the IP address is assigned from a pool of addresses that you specify when you create the Client VPN endpoint, and it does not directly correlate to the user or group that authenticated.

To address this challenge I have considered splitting the groups into different Client VPN endpoints, each with its own IP address pool. This way, I can assign specific IP ranges to different groups of users, making it easier to manage access control based on the group they belong to. But then Client VPN Endpoints for Transit Gateways came out and it alomost sounds like they are doing this for you.

Can any one see any real benefits to using Client VPN Endpoints for Transit Gateways in our scenario? Or would it be better to just create separate Client VPN endpoints for each group and manage the IP address pools that way?

Topics
Networking & Content Delivery
Tags
AWS Client VPNAWS Transit Gateway
Language
English

asked a month ago41 views

1 Answer
1

Client VPN TGW attachments don't solve your IP-per-group problem. They solve a routing problem (centralised access to multiple VPCs), not an identity-to-IP mapping problem.

What TGW attachments give you:

Instead of associating your Client VPN endpoint with a subnet in a single VPC (and routing through TGW to reach other VPCs), you attach the endpoint directly to a Transit Gateway. Clients can reach any VPC attached to that TGW without needing a "landing" VPC. For your architecture (5 accounts, 3 regions, 3 TGWs), this means 3 endpoints instead of potentially 15 - one per region attached to the regional TGW.

What TGW attachments do NOT do:

  • They don't assign IPs based on authenticated group
  • The IP pool behavior is identical to VPC-attached endpoints - random allocation from your CIDR

How to get group-based access control with Client VPN:

  1. Authorization rules (simplest, no IP correlation needed): Define which AD groups can reach which destination CIDRs. For example: AdminGroup → 10.0.0.0/8, DevGroup → 10.1.0.0/16 only. This is native Client VPN functionality and handles most access control needs without caring about the client's assigned IP.

  2. Separate endpoints per group (if you truly need IP-based segmentation): Create one endpoint per group with a dedicated CIDR (e.g., Admins: 172.16.0.0/22, Devs: 172.16.4.0/22). Write security group rules at destination resources matching these source ranges. Each endpoint can be TGW-attached for centralized routing. Downsides: more endpoints to manage, separate .ovpn configs per group, higher cost.

  3. Client Connect Handler (Lambda-based, advanced): Use a Client Connect Handler Lambda to evaluate group membership at connection time. You can deny connections or log the group-to-IP mapping for auditing. This doesn't fix the IP assignment itself, but lets you enforce policy dynamically.

Recommendation for 50 users across 5 accounts:

  • Deploy 3 Client VPN endpoints (one per region), each TGW-attached
  • Use authorization rules for access control (not IP ranges)
  • Enable connection logging to CloudWatch for audit trail (logs show username + assigned IP + timestamps)
  • Skip the separate-endpoint-per-group approach unless you have a hard requirement for IP-based firewalling at the destination (e.g., third-party systems that can only filter by source IP)

The TGW attachment is worth adopting for the routing simplification, just don't expect it to solve the identity-to-IP problem.

References:

AWS
SUPPORT ENGINEER

answered a month ago

EXPERT

reviewed a month ago

EXPERT

reviewed a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content