[Update] AWS Client VPN Now Supports Native Integration with AWS Transit Gateway

[Update] AWS Client VPN Now Supports Native Integration with AWS Transit Gateway

If your environment already uses Transit Gateway, you'll likely want to use the native integration with Transit Gateway from now on.
2026.04.30

This page has been translated by machine translation. View original

I want to identify the Client VPN endpoint's IP address from the destination

Hello, this is Nonpi (@non____97).

When using AWS Client VPN, have you ever wanted to identify the Client VPN endpoint's IP address from the destination? I have.

As introduced in the article below, when communicating via Client VPN, the source IP address is an SNATed IP address.

This is a confusing point, but the source IP as seen from the destination server is not an IP address from this client CIDR. Because the source IP address is NATed by the ENI on the target network, the source IP as seen from the destination server is the one held by the ENI on the target network.

I illustrated the components of AWS Client VPN to understand them and tested how far NetworkACLs and SecurityGroups can be restricted | DevelopersIO

Therefore, the destination cannot determine specifically which user the IP address came from.

The following log is recorded as the Client VPN connection log, but as long as client-ip is shared by multiple users, it is difficult to identify the user.

{
    "connection-log-type": "connection-attempt",
    "connection-attempt-status": "successful",
    "connection-reset-status": "NA",
    "connection-attempt-failure-reason": "NA",
    "connection-id": "cvpn-connection-abc123abc123abc12",
    "client-vpn-endpoint-id": "cvpn-endpoint-aaa111bbb222ccc33",
    "transport-protocol": "udp",
    "connection-start-time": "2020-03-26 20:37:15",
    "connection-last-update-time": "2020-03-26 20:37:15",
    "client-ip": "10.0.1.2",
    "common-name": "client1",
    "device-type": "mac",
    "device-ip": "98.247.202.82",
    "port": "50096",
    "ingress-bytes": "0",
    "egress-bytes": "0",
    "ingress-packets": "0",
    "egress-packets": "0",
    "connection-end-time": "NA",
    "username": "joe"
}

Excerpt: Connection logging for an AWS Client VPN endpoint - AWS Client VPN

With this update, native integration between Transit Gateway and Client VPN is now supported. In other words, instead of associating with a VPC, you associate with a Transit Gateway.

https://aws.amazon.com/jp/about-aws/whats-new/2026/04/aws-client-vpn-transit-gateway/

It has also been posted on the AWS Blogs.

https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-client-vpn-native-aws-transit-gateway-attachment/

Previously, traffic was SNATed to the ENI created in the subnet associated with the Client VPN endpoint, but that no longer happens. This makes it easy to identify communications.

Of course, if you had prepared a dedicated VPC, that dedicated VPC is no longer needed either.

The pricing remains unchanged, which is very welcome.

Prerequisites for native integration between Client VPN and Transit Gateway

The prerequisites for native integration between Client VPN and Transit Gateway are as follows.

  • Transit Gateway requirements
    • Must be in the same Region as the Client VPN endpoint
    • When associating across accounts, use RAM
    • A Transit Gateway CIDR block must be assigned
      • If adopting IPv6 or a dual-stack configuration, also assign an IPv6 CIDR block
  • Network requirements
    • The Client VPN client CIDR block must not overlap with the CIDR blocks of VPCs connected to the Transit Gateway
    • The AZs specified for Client VPN must also be supported by Transit Gateway
    • To route return traffic to Client VPN, define a return route in the route table of the destination VPC

Reference: Transit Gateway integration with Client VPN - AWS Client VPN

Personally, I was curious about how the Transit Gateway CIDR block is used and how to size it. The documentation has no elements that serve as design hints.

Trying it out

Test environment

Let's actually try it.

The test environment is as follows.

検証環境構成図.png

Everything other than Client VPN has already been created.

The Transit Gateway and Transit Gateway route table are as follows.

1.Transit Gateway.png

2.ルートテーブル.png

I was curious about the behavior when the Transit Gateway CIDR block is not specified, so I left it unspecified for now.

Issuing the certificates

We issue the certificates following the AWS official documentation below.

https://docs.aws.amazon.com/ja_jp/vpn/latest/clientvpn-admin/client-auth-mutual-enable.html

$ git clone https://github.com/OpenVPN/easy-rsa.git
Cloning into 'easy-rsa'...
remote: Enumerating objects: 9284, done.
remote: Counting objects: 100% (324/324), done.
remote: Compressing objects: 100% (119/119), done.
remote: Total 9284 (delta 213), reused 209 (delta 204), pack-reused 8960 (from 4)
Receiving objects: 100% (9284/9284), 69.36 MiB | 25.95 MiB/s, done.
Resolving deltas: 100% (4391/4391), done.

$ cd easy-rsa/easyrsa3

$ ./easyrsa init-pki

Notice
------
'init-pki' complete; you may now create a CA or requests.

Your newly created PKI dir is:
* /home/ssm-user/easy-rsa/easyrsa3/pki

$ ./easyrsa build-ca nopass
.........+.+..+++++++++++++++++++++++++++++++++++++++*..+.+++++++++++++++++++++++++++++++++++++++*......+.......+..+...+...+...+..........+......+.....+....+......+......+.....+..........+..+.............+...............+............+..+....+..+............+.+.....+.+.....+.+...+............+..+.+......+...+...+..+..........+..+........................................+......+..+...+...+......+...+.+.................+.......+.....+...+.............+.....................+...........+....+...........+...+....+..+..........+......+...+.....+....+...+..+...+...+..........+.....+.......+...+..+.........+..........+...+.................+...+......+......+...+.+..+...............+...............+.......+......+.........+..+......+.......+........+.......+......+..............+.......+...+..+......+....+......+...+..+.........+...+............+......+....+......+...+............+...+...........+.............+........+....+...+...........+....+.....+.+..+.......+.....+...+.............+.....+....+...+..+......+......+.+..+.......+........+............+.+.....+.........+.++++++
.......+..+.+..+++++++++++++++++++++++++++++++++++++++*....+..+...+.+......+..+.+.........+..+.+..+.+.....+++++++++++++++++++++++++++++++++++++++*....+......+.........+......++++++
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [Easy-RSA CA]:non-97 CA

Notice
------
CA creation complete. Your new CA certificate is at:
* /home/ssm-user/easy-rsa/easyrsa3/pki/ca.crt

Build-ca completed successfully.

$ ./easyrsa --san=DNS:server build-server-full server nopass
.+.........+...+..+.............+...+..+.......+.........+++++++++++++++++++++++++++++++++++++++*.....+..+....+.......................+...+++++++++++++++++++++++++++++++++++++++*.++++++
.+...+.+......+...+++++++++++++++++++++++++++++++++++++++*..+..+...+....+...+........+.+........+.+++++++++++++++++++++++++++++++++++++++*......+...+.....+...+...+....+..+..........+.....+......+...............+...+......+.........+....++++++
-----

Notice
------
Private-Key and Public-Certificate-Request files created.
Your files are:
* req: /home/ssm-user/easy-rsa/easyrsa3/pki/reqs/server.req
* key: /home/ssm-user/easy-rsa/easyrsa3/pki/private/server.key

You are about to sign the following certificate:

  Requested CN:     'server'
  Requested type:   'server'
  Valid for:        '825' days


subject=
    commonName                = server

            X509v3 Subject Alternative Name:
                DNS:server

Type the word 'yes' to continue, or any other input to abort.
  Confirm requested details: yes

Using configuration from /home/ssm-user/easy-rsa/easyrsa3/pki/5e8f7136/temp.02
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'server'
Certificate is to be certified until Aug  1 15:55:02 2028 GMT (825 days)

Write out database with 1 new entries
Database updated

WARNING
=======
INCOMPLETE Inline file created:
* /home/ssm-user/easy-rsa/easyrsa3/pki/inline/private/server.inline

Missing TLS Key, see 'easyrsa help gen-tls'


Notice
------
Certificate created at:
* /home/ssm-user/easy-rsa/easyrsa3/pki/issued/server.crt

$ ./easyrsa build-client-full client1.domain.tld nopass
....+.........+............+.....+....+.........+.....+.+++++++++++++++++++++++++++++++++++++++*.....+.......+...+.....+....+........+.+..+...+.......+.....+...+.+.....+...+......+.........+++++++++++++++++++++++++++++++++++++++*.........+.....+.......+...........+....+...+......+..+.......+..+.........+......+...+.+..............+.......+...+........+.......+.....+.......+..............+.+..................+.....+.+.....+.......+..+.+..+..........+.........+...........+.........+..........+.........+..+.......+........+...+....+......+...............+..+.......+..+.+............+..+.+...+..+...+......+..........+........+...+...+................+...+.....+......+.+........+.+.........+..+.+..............+.+........+.........+.......+...+..+.....................+...+.........+................+.........+........+....+.....+.............+...+..+.......+...+.....+.+.........+......++++++
...+.....................+++++++++++++++++++++++++++++++++++++++*.........+..+...+....+...+..+................+...........+.+............+......+.....+.+...+++++++++++++++++++++++++++++++++++++++*.........+....+......+..++++++
-----

Notice
------
Private-Key and Public-Certificate-Request files created.
Your files are:
* req: /home/ssm-user/easy-rsa/easyrsa3/pki/reqs/client1.domain.tld.req
* key: /home/ssm-user/easy-rsa/easyrsa3/pki/private/client1.domain.tld.key

You are about to sign the following certificate:

  Requested CN:     'client1.domain.tld'
  Requested type:   'client'
  Valid for:        '825' days


subject=
    commonName                = client1.domain.tld

Type the word 'yes' to continue, or any other input to abort.
  Confirm requested details: yes

Using configuration from /home/ssm-user/easy-rsa/easyrsa3/pki/6014a4ac/temp.02
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'client1.domain.tld'
Certificate is to be certified until Aug  1 15:55:15 2028 GMT (825 days)

Write out database with 1 new entries
Database updated

WARNING
=======
INCOMPLETE Inline file created:
* /home/ssm-user/easy-rsa/easyrsa3/pki/inline/private/client1.domain.tld.inline

Missing TLS Key, see 'easyrsa help gen-tls'


Notice
------
Certificate created at:
* /home/ssm-user/easy-rsa/easyrsa3/pki/issued/client1.domain.tld.crt

$ mkdir ~/custom_folder/
$ cp pki/ca.crt ~/custom_folder/
$ cp pki/issued/server.crt ~/custom_folder/
$ cp pki/private/server.key ~/custom_folder/
$ cp pki/issued/client1.domain.tld.crt ~/custom_folder
$ cp pki/private/client1.domain.tld.key ~/custom_folder/
$ cd ~/custom_folder/
$ aws acm import-certificate --certificate fileb://server.crt --private-key fileb://server.key --certificate-chain fileb://ca.crt
{
    "CertificateArn": "arn:aws:acm:us-east-1:<AWSアカウントID>:certificate/5309c0e4-a468-4689-8ab9-22b47197e261"
}

$ aws acm import-certificate --certificate fileb://client1.domain.tld.crt --private-key fileb://client1.domain.tld.key --certificate-chain fileb://ca.crt
{
    "CertificateArn": "arn:aws:acm:us-east-1:<AWSアカウントID>:certificate/5692a55a-a6e3-4687-8495-4554b29ecdb7"
}

The server certificate and client certificate are now registered in ACM.

Creating the Client VPN endpoint

Next, we create the Client VPN endpoint.

There is nothing particularly notable other than that the association target is a Transit Gateway rather than a VPC, and that you specify the AZs at this point.

3.Client VPNエンドポイントの作成.png

When I tried to create it like this, it failed with the error Transit Gateway configuration error- There is no IPv4 or IPv6 CIDR block associated with the Transit Gateway. As expected, assigning a Transit Gateway CIDR block seems to be mandatory.

4.Transit Gateway configuration error- There is no IPv4 or IPv6 CIDR block associated with the Transit Gateway..png

We specify a Transit Gateway CIDR block that does not overlap with the VPC CIDR or the Client VPN client IPv4 CIDR block.

5.Transit Gateway CIDRブロックの追加.png

After adding the Transit Gateway CIDR block, I requested creation of the Client VPN endpoint with the same parameters as before, and it was accepted successfully.

6.Client VPN作成済み.png

The association with the AZs has already been done.

We configure an authorization rule and routes so that it can communicate with the VPC connected to the Transit Gateway.

8.承認ルール.png

9.ルートテーブル.png

When I checked the Transit Gateway attachments in this state, one with the resource type Client VPN had been created.

7.リソースタイプがClient VPNのTransit Gateway attachment.png

Also, checking the Transit Gateway route table, a route to the range specified as the Client VPN client IPv4 CIDR block had been added. It is a mystery why routes more specific than the one specified as the Client VPN client IPv4 CIDR block, such as 10.1.0.0/24, are configured.

10.Transit Gateway route table.png

Verifying operation

Now let's verify operation.

Download the client configuration file of the Client VPN endpoint and enter the client certificate and private key in the configuration file.

Specify the configuration file in a Client VPN profile and connect.

I think the following article explains the overall flow clearly.

https://dev.classmethod.jp/articles/krsk-client-vpn-20250213/

In this state, I ping the EC2 instance in the VPC from my local machine.

> ping -c 4 10.0.12.144
PING 10.0.12.144 (10.0.12.144): 56 data bytes
64 bytes from 10.0.12.144: icmp_seq=0 ttl=125 time=185.791 ms
64 bytes from 10.0.12.144: icmp_seq=1 ttl=125 time=187.940 ms
64 bytes from 10.0.12.144: icmp_seq=2 ttl=125 time=187.484 ms
64 bytes from 10.0.12.144: icmp_seq=3 ttl=125 time=183.719 ms

--- 10.0.12.144 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 183.719/186.233/187.940/1.658 ms

Nice.

I start nginx on the EC2 instance in the VPC and access it with curl.

> curl 10.0.12.144
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

> curl 10.0.12.144 -I
HTTP/1.1 200 OK
Server: nginx/1.28.3
Date: Wed, 29 Apr 2026 21:33:09 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Tue, 31 Mar 2026 20:27:53 GMT
Connection: keep-alive
ETag: "69cc2e49-267"
Accept-Ranges: bytes

> curl 10.0.12.144 -Iv
*   Trying 10.0.12.144:80...
* Connected to 10.0.12.144 (10.0.12.144) port 80
> HEAD / HTTP/1.1
> Host: 10.0.12.144
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx/1.28.3
Server: nginx/1.28.3
< Date: Wed, 29 Apr 2026 21:33:16 GMT
Date: Wed, 29 Apr 2026 21:33:16 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 615
Content-Length: 615
< Last-Modified: Tue, 31 Mar 2026 20:27:53 GMT
Last-Modified: Tue, 31 Mar 2026 20:27:53 GMT
< Connection: keep-alive
Connection: keep-alive
< ETag: "69cc2e49-267"
ETag: "69cc2e49-267"
< Accept-Ranges: bytes
Accept-Ranges: bytes
<

* Connection #0 to host 10.0.12.144 left intact

It is accessible without any problems.

Checking nginx's access log at this point, the IP address is indeed within the IP address range I assigned.

$ sudo cat /var/log/nginx/access.log
10.1.3.2 - - [29/Apr/2026:21:28:11 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/8.7.1" "-"
10.1.3.2 - - [29/Apr/2026:21:33:09 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/8.7.1" "-"
10.1.3.2 - - [29/Apr/2026:21:33:16 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/8.7.1" "-"

This IP address matches the client IP address that can be checked from the Client VPN connection history. This is convenient.

11.接続履歴.png

Checking Transit Gateway Flow Logs

Let's also check the Transit Gateway Flow Logs.

Since I want to run queries in Athena, I execute the following DDL.

CREATE EXTERNAL TABLE `tgw_flow_logs`(
  `version` int, 
  `resource_type` string, 
  `account_id` string, 
  `tgw_id` string, 
  `tgw_attachment_id` string, 
  `tgw_src_vpc_account_id` string, 
  `tgw_dst_vpc_account_id` string, 
  `tgw_src_vpc_id` string, 
  `tgw_dst_vpc_id` string, 
  `tgw_src_subnet_id` string, 
  `tgw_dst_subnet_id` string, 
  `tgw_src_eni` string, 
  `tgw_dst_eni` string, 
  `tgw_src_az_id` string, 
  `tgw_dst_az_id` string, 
  `tgw_pair_attachment_id` string, 
  `srcaddr` string, 
  `dstaddr` string, 
  `srcport` int, 
  `dstport` int, 
  `protocol` bigint, 
  `packets` bigint, 
  `bytes` bigint, 
  `start` bigint, 
  `end` bigint, 
  `log_status` string, 
  `type` string, 
  `packets_lost_no_route` bigint, 
  `packets_lost_blackhole` bigint, 
  `packets_lost_mtu_exceeded` bigint, 
  `packets_lost_ttl_expired` bigint, 
  `tcp_flags` int, 
  `region` string, 
  `flow_direction` string, 
  `pkt_src_aws_service` string, 
  `pkt_dst_aws_service` string)
PARTITIONED BY ( 
  `aws_account_id` string, 
  `aws_region` string, 
  `datehour` string)
ROW FORMAT SERDE 
  'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' 
STORED AS INPUTFORMAT 
  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat' 
OUTPUTFORMAT 
  'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'
LOCATION
  's3://bucket-tgw-flow-logs-956004e0-b408-11ee-8ba7-0af1bc648567/AWSLogs'
TBLPROPERTIES (
  'projection.enabled'='true', 
  'has_encrypted_data'='true', 
  'classification'='parquet',
  'projection.aws_account_id.type'='enum', 
  'projection.aws_account_id.values'='<AWSアカウントID>', 
  'projection.aws_region.type'='enum', 
  'projection.aws_region.values'='us-east-1', 
  'projection.datehour.format'='yyyy/MM/dd/HH', 
  'projection.datehour.interval'='1', 
  'projection.datehour.interval.unit'='HOURS', 
  'projection.datehour.range'='NOW-1YEARS,NOW', 
  'projection.datehour.type'='date', 
  'projection.enabled'='true', 
  'skip.header.line.count'='1', 
  'storage.location.template'='s3://bucket-tgw-flow-logs-956004e0-b408-11ee-8ba7-0af1bc648567/AWSLogs/${aws_account_id}/vpcflowlogs/${aws_region}/${datehour}', 
  'transient_lastDdlTime'='1705373737')

We extract the logs of the traffic during the connectivity check.

SELECT 
    * 
FROM 
    "default"."tgw_flow_logs"
WHERE
    datehour='2026/04/29/21' AND
    (
        srcaddr='10.0.12.144' OR
        dstaddr='10.0.12.144'
    )
;

The execution results are as follows.

version,resource_type,account_id,tgw_id,tgw_attachment_id,tgw_src_vpc_account_id,tgw_dst_vpc_account_id,tgw_src_vpc_id,tgw_dst_vpc_id,tgw_src_subnet_id,tgw_dst_subnet_id,tgw_src_eni,tgw_dst_eni,tgw_src_az_id,tgw_dst_az_id,tgw_pair_attachment_id,srcaddr,dstaddr,srcport,dstport,protocol,packets,bytes,start,end,log_status,type,packets_lost_no_route,packets_lost_blackhole,packets_lost_mtu_exceeded,packets_lost_ttl_expired,tcp_flags,region,flow_direction,pkt_src_aws_service,pkt_dst_aws_service,aws_account_id,aws_region,datehour
6,TransitGateway,<AWSアカウントID>,tgw-03d2485a985829417,tgw-attach-0056b0ec6fa18076d,<AWSアカウントID>,<AWSアカウントID>,'-,vpc-03495edd159790772,'-,subnet-078545a6acad5a157,'-,eni-0c845bf8606c21517,use1-az6,use1-az6,tgw-attach-0865fae232c417ff1,10.1.3.2,10.0.12.144,58760,80,6,6,398,1777498091,1777498091,OK,IPv4,0,0,0,0,,us-east-1,ingress,'-,'-,<AWSアカウントID>,us-east-1,2026/04/29/21
6,TransitGateway,<AWSアカウントID>,tgw-03d2485a985829417,tgw-attach-0865fae232c417ff1,<AWSアカウントID>,<AWSアカウントID>,'-,vpc-03495edd159790772,'-,subnet-078545a6acad5a157,'-,eni-0c845bf8606c21517,use1-az6,use1-az6,tgw-attach-0056b0ec6fa18076d,10.1.3.2,10.0.12.144,58760,80,6,6,398,1777498091,1777498091,OK,IPv4,0,0,0,0,,us-east-1,egress,'-,'-,<AWSアカウントID>,us-east-1,2026/04/29/21
6,TransitGateway,<AWSアカウントID>,tgw-03d2485a985829417,tgw-attach-0865fae232c417ff1,<AWSアカウントID>,<AWSアカウントID>,vpc-03495edd159790772,'-,subnet-078545a6acad5a157,'-,eni-0c845bf8606c21517,'-,use1-az6,use1-az6,tgw-attach-0056b0ec6fa18076d,10.0.12.144,10.1.3.2,80,58760,6,4,1069,1777498091,1777498091,OK,IPv4,0,0,0,0,0,us-east-1,ingress,'-,'-,<AWSアカウントID>,us-east-1,2026/04/29/21
6,TransitGateway,<AWSアカウントID>,tgw-03d2485a985829417,tgw-attach-0056b0ec6fa18076d,<AWSアカウントID>,<AWSアカウントID>,vpc-03495edd159790772,'-,subnet-078545a6acad5a157,'-,eni-0c845bf8606c21517,'-,use1-az6,use1-az6,tgw-attach-0865fae232c417ff1,10.0.12.144,10.1.3.2,80,58760,6,4,1069,1777498091,1777498091,OK,IPv4,0,0,0,0,0,us-east-1,egress,'-,'-,<AWSアカウントID>,us-east-1,2026/04/29/21
6,TransitGateway,<AWSアカウントID>,tgw-03d2485a985829417,tgw-attach-0865fae232c417ff1,<AWSアカウントID>,<AWSアカウントID>,vpc-03495edd159790772,'-,subnet-078545a6acad5a157,'-,eni-0c845bf8606c21517,'-,use1-az6,use1-az6,tgw-attach-0056b0ec6fa18076d,10.0.12.144,10.1.3.2,0,0,1,4,336,1777498375,1777498378,OK,IPv4,0,0,0,0,0,us-east-1,ingress,'-,'-,<AWSアカウントID>,us-east-1,2026/04/29/21
6,TransitGateway,<AWSアカウントID>,tgw-03d2485a985829417,tgw-attach-0056b0ec6fa18076d,<AWSアカウントID>,<AWSアカウントID>,vpc-03495edd159790772,'-,subnet-078545a6acad5a157,'-,eni-0c845bf8606c21517,'-,use1-az6,use1-az6,tgw-attach-0865fae232c417ff1,10.0.12.144,10.1.3.2,0,0,1,4,336,1777498375,1777498378,OK,IPv4,0,0,0,0,0,us-east-1,egress,'-,'-,<AWSアカウントID>,us-east-1,2026/04/29/21
6,TransitGateway,<AWSアカウントID>,tgw-03d2485a985829417,tgw-attach-0056b0ec6fa18076d,<AWSアカウントID>,<AWSアカウントID>,'-,vpc-03495edd159790772,'-,subnet-078545a6acad5a157,'-,eni-0c845bf8606c21517,use1-az6,use1-az6,tgw-attach-0865fae232c417ff1,10.1.3.2,10.0.12.144,58926,80,6,6,399,1777498389,1777498389,OK,IPv4,0,0,0,0,,us-east-1,ingress,'-,'-,<AWSアカウントID>,us-east-1,2026/04/29/21
6,TransitGateway,<AWSアカウントID>,tgw-03d2485a985829417,tgw-attach-0865fae232c417ff1,<AWSアカウントID>,<AWSアカウントID>,'-,vpc-03495edd159790772,'-,subnet-078545a6acad5a157,'-,eni-0c845bf8606c21517,use1-az6,use1-az6,tgw-attach-0056b0ec6fa18076d,10.1.3.2,10.0.12.144,58926,80,6,6,399,1777498389,1777498389,OK,IPv4,0,0,0,0,,us-east-1,egress,'-,'-,<AWSアカウントID>,us-east-1,2026/04/29/21
6,TransitGateway,<AWSアカウントID>,tgw-03d2485a985829417,tgw-attach-0865fae232c417ff1,<AWSアカウントID>,<AWSアカウントID>,vpc-03495edd159790772,'-,subnet-078545a6acad5a157,'-,eni-0c845bf8606c21517,'-,use1-az6,use1-az6,tgw-attach-0056b0ec6fa18076d,10.0.12.144,10.1.3.2,80,58930,6,4,454,1777498395,1777498396,OK,IPv4,0,0,0,0,0,us-east-1,ingress,'-,'-,<AWSアカウントID>,us-east-1,2026/04/29/21
6,TransitGateway,<AWSアカウントID>,tgw-03d2485a985829417,tgw-attach-0056b0ec6fa18076d,<AWSアカウントID>,<AWSアカウントID>,'-,vpc-03495edd159790772,'-,subnet-078545a6acad5a157,'-,eni-0c845bf8606c21517,use1-az6,use1-az6,tgw-attach-0865fae232c417ff1,10.1.3.2,10.0.12.144,58930,80,6,6,399,1777498395,1777498396,OK,IPv4,0,0,0,0,,us-east-1,ingress,'-,'-,<AWSアカウントID>,us-east-1,2026/04/29/21
6,TransitGateway,<AWSアカウントID>,tgw-03d2485a985829417,tgw-attach-0865fae232c417ff1,<AWSアカウントID>,<AWSアカウントID>,'-,vpc-03495edd159790772,'-,subnet-078545a6acad5a157,'-,eni-0c845bf8606c21517,use1-az6,use1-az6,tgw-attach-0056b0ec6fa18076d,10.1.3.2,10.0.12.144,58930,80,6,6,399,1777498395,1777498396,OK,IPv4,0,0,0,0,,us-east-1,egress,'-,'-,<AWSアカウントID>,us-east-1,2026/04/29/21
6,TransitGateway,<AWSアカウントID>,tgw-03d2485a985829417,tgw-attach-0056b0ec6fa18076d,<AWSアカウントID>,<AWSアカウントID>,vpc-03495edd159790772,'-,subnet-078545a6acad5a157,'-,eni-0c845bf8606c21517,'-,use1-az6,use1-az6,tgw-attach-0865fae232c417ff1,10.0.12.144,10.1.3.2,80,58930,6,4,454,1777498395,1777498396,OK,IPv4,0,0,0,0,0,us-east-1,egress,'-,'-,<AWSアカウントID>,us-east-1,2026/04/29/21
6,TransitGateway,<AWSアカウントID>,tgw-03d2485a985829417,tgw-attach-0056b0ec6fa18076d,<AWSアカウントID>,<AWSアカウントID>,vpc-03495edd159790772,'-,subnet-078545a6acad5a157,'-,eni-0c845bf8606c21517,'-,use1-az6,use1-az6,tgw-attach-0865fae232c417ff1,10.0.12.144,10.1.3.2,80,58926,6,4,454,1777498389,1777498389,OK,IPv4,0,0,0,0,0,us-east-1,egress,'-,'-,<AWSアカウントID>,us-east-1,2026/04/29/21
6,TransitGateway,<AWSアカウントID>,tgw-03d2485a985829417,tgw-attach-0865fae232c417ff1,<AWSアカウントID>,<AWSアカウントID>,vpc-03495edd159790772,'-,subnet-078545a6acad5a157,'-,eni-0c845bf8606c21517,'-,use1-az6,use1-az6,tgw-attach-0056b0ec6fa18076d,10.0.12.144,10.1.3.2,80,58926,6,4,454,1777498389,1777498389,OK,IPv4,0,0,0,0,0,us-east-1,ingress,'-,'-,<AWSアカウントID>,us-east-1,2026/04/29/21
6,TransitGateway,<AWSアカウントID>,tgw-03d2485a985829417,tgw-attach-0865fae232c417ff1,<AWSアカウントID>,<AWSアカウントID>,'-,vpc-03495edd159790772,'-,subnet-078545a6acad5a157,'-,eni-0c845bf8606c21517,use1-az6,use1-az6,tgw-attach-0056b0ec6fa18076d,10.1.3.2,10.0.12.144,0,0,1,4,336,1777498375,1777498378,OK,IPv4,0,0,0,0,0,us-east-1,egress,'-,'-,<AWSアカウントID>,us-east-1,2026/04/29/21
6,TransitGateway,<AWSアカウントID>,tgw-03d2485a985829417,tgw-attach-0056b0ec6fa18076d,<AWSアカウントID>,<AWSアカウントID>,'-,vpc-03495edd159790772,'-,subnet-078545a6acad5a157,'-,eni-0c845bf8606c21517,use1-az6,use1-az6,tgw-attach-0865fae232c417ff1,10.1.3.2,10.0.12.144,0,0,1,4,336,1777498375,1777498378,OK,IPv4,0,0,0,0,0,us-east-1,ingress,'-,'-,<AWSアカウントID>,us-east-1,2026/04/29/21

Here too, the source/destination IP addresses are within the IP address range assigned to the Client VPN endpoint that we checked earlier.

I also checked whether IP addresses within the range assigned to the Transit Gateway CIDR block are recorded in the Transit Gateway Flow Logs, as shown below, but the result was 0 records.

SELECT 
    * 
FROM 
    "default"."tgw_flow_logs"
WHERE
    datehour='2026/04/29/21' AND
    (
        srcaddr LIKE '10.2.%' OR
        dstaddr LIKE '10.2.%'
    )
;

So I can't tell how it is being used.

If you're in an environment that uses Transit Gateway, you'll probably use the native integration with Transit Gateway from now on

I introduced the update in which AWS Client VPN supports native integration with AWS Transit Gateway.

If you're in an environment that uses Transit Gateway, you'll probably use the native integration with Transit Gateway from now on.

I hope this article helps someone.

This was Nonpi (@non____97) of the Consulting Department, Cloud Business Division!

Share this article

AWSのお困り事はクラスメソッドへ