Example scenarios for authorization rules
This section describes how authorization rules work for AWS Client VPN. It includes key points for understanding authorization rules, an example architecture, and discussion of example scenarios that map to the example architecture.
Contents
- Key points
- Example architecture
- Scenario 1: Access to a single destination
- Scenario 2: Using any destination (0.0.0.0/0) CIDR
- Scenario 3: Longer IP prefix match
- Scenario 4: Overlapping CIDR (same group)
- Scenario 5: Additional 0.0.0.0/0 rule
- Scenario 6: Adding rule for 192.168.0.0/24
- Scenario 7: Access for all user groups
Key points for understanding authorization rules
The following points explain some of the behavior of authorization rules:
-
To allow access to a destination network, an authorization rule must be explicitly added. The default behavior is to deny access.
-
You cannot add an authorization rule to restrict access to a destination network.
-
The
0.0.0.0/0
CIDR is handled as a special case. It is processed last, regardless of the order in which the authorization rules were created. -
The
0.0.0.0/0
CIDR can be thought of as "any destination," or "any destination not defined by other authorization rules." -
The longest prefix match is the rule that takes precedence.
Example architecture for authorization rule scenarios
The following diagram shows the example architecture that is used for the example scenarios found in this section.
Scenario 1: Access to a single destination
Rule description | Group ID | Allow access to all users | Destination CIDR |
---|---|---|---|
Provide engineering group access to on-premises network |
S-xxxxx14 |
False |
172.16.0.0/24 |
Provide development group access to development VPC |
S-xxxxx15 |
False |
10.0.0.0/16 |
Provide manager group access to Client VPN VPC |
S-xxxxx16 |
False |
192.168.0.0/24 |
Resulting behavior
-
The engineering group can access only
172.16.0.0/24
. -
The development group can access only
10.0.0.0/16
. -
The manager group can access only
192.168.0.0/24
. -
All other traffic is dropped by the Client VPN endpoint.
Note
In this scenario, no user group has access to the public internet.
Scenario 2: Using any destination (0.0.0.0/0) CIDR
Rule description | Group ID | Allow access to all users | Destination CIDR |
---|---|---|---|
Provide engineering group access to on-premises network |
S-xxxxx14 |
False |
172.16.0.0/24 |
Provide development group access to development VPC |
S-xxxxx15 |
False |
10.0.0.0/16 |
Provide manager group access to any destination |
S-xxxxx16 |
False |
0.0.0.0/0 |
Resulting behavior
-
The engineering group can access only
172.16.0.0/24
. -
The development group can access only
10.0.0.0/16
. -
The manager group can access the public internet and
192.168.0.0/24
, but cannot access172.16.0.0/24
or10.0.0/16
.
Note
In this scenario, because no rules are referencing 192.168.0.0/24
, access to
that network is also provided by the 0.0.0.0/0
rule.
A rule containing 0.0.0.0/0
is always evaluated last regardless of the order
in which the rules were created. Because of this, keep in mind that the rules
evaluated before 0.0.0.0/0
play a role in determining which
networks 0.0.0.0/0
grants access to.
Scenario 3: Longer IP prefix match
Rule description | Group ID | Allow access to all users | Destination CIDR |
---|---|---|---|
Provide engineering group access to on-premises network |
S-xxxxx14 |
False |
172.16.0.0/24 |
Provide development group access to development VPC |
S-xxxxx15 |
False |
10.0.0.0/16 |
Provide manager group access to any destination |
S-xxxxx16 |
False |
0.0.0.0/0 |
Provide manager group access to a single host in development VPC |
S-xxxxx16 |
False |
10.0.2.119/32 |
Resulting behavior
-
The engineering group can access only
172.16.0.0/24
. -
The development group can access
10.0.0.0/16
, except for the single host10.0.2.119/32
. -
The manager group can access the public internet,
192.168.0.0/24
, and a single host (10.0.2.119/32
) within the development VPC, but does not have access to172.16.0.0/24
or any of the remaining hosts in the development VPC.
Note
Here you see how a rule with a longer IP prefix takes precedence over a rule with a
shorter IP prefix. If you want the development group to have access to
10.0.2.119/32
, an additional rule granting the development team
access to 10.0.2.119/32
needs to be added.
Scenario 4: Overlapping CIDR (same group)
Rule description | Group ID | Allow access to all users | Destination CIDR |
---|---|---|---|
Provide engineering group access to on-premises network |
S-xxxxx14 |
False |
172.16.0.0/24 |
Provide development group access to development VPC |
S-xxxxx15 |
False |
10.0.0.0/16 |
Provide manager group access to any destination |
S-xxxxx16 |
False |
0.0.0.0/0 |
Provide manager group access to single host in development VPC |
S-xxxxx16 |
False |
10.0.2.119/32 |
Provide engineering group access to a smaller subnet within on-premises network |
S-xxxxx14 |
False |
172.16.0.128/25 |
Resulting behavior
-
The development group can access
10.0.0.0/16
, except for the single host10.0.2.119/32
. -
The manager group can access the public internet,
192.168.0.0/24
, and a single host (10.0.2.119/32
) within the10.0.0.0/16
network, but does not have access to172.16.0.0/24
or any of the remaining hosts in the10.0.0.0/16
network. -
The engineering group has access to
172.16.0.0/24
, including the more specific subnet172.16.0.128/25
.
Scenario 5: Additional 0.0.0.0/0 rule
Rule description | Group ID | Allow access to all users | Destination CIDR |
---|---|---|---|
Provide engineering group access to on-premises network |
S-xxxxx14 |
False |
172.16.0.0/24 |
Provide development group access to development VPC |
S-xxxxx15 |
False |
10.0.0.0/16 |
Provide manager group access to any destination |
S-xxxxx16 |
False |
0.0.0.0/0 |
Provide manager group access to single host in development VPC |
S-xxxxx16 |
False |
10.0.2.119/32 |
Provide engineering group access to a smaller subnet within on-premises network |
S-xxxxx14 |
False |
172.16.0.128/25 |
Provide engineering group access to any destination |
S-xxxxx14 |
False |
0.0.0.0/0 |
Resulting behavior
-
The development group can access
10.0.0.0/16
, except for the single host10.0.2.119/32
. -
The manager group can access the public internet,
192.168.0.0/24
, and a single host (10.0.2.119/32
) within the10.0.0.0/16
network, but does not have access to172.16.0.0/24
or any of the remaining hosts in the10.0.0.0/16
network. -
The engineering group can access the public internet,
192.168.0.0/24
, and172.16.0.0/24
, including the more specific subnet172.16.0.128/25
.
Note
Notice that both the engineering and manager groups can now access
192.168.0.0/24
. This is because both groups have access to
0.0.0.0/0
(any destination) and no other
rules are referencing 192.168.0.0/24
.
Scenario 6: Adding rule for 192.168.0.0/24
Rule description | Group ID | Allow access to all users | Destination CIDR |
---|---|---|---|
Provide engineering group access to on-premises network |
S-xxxxx14 |
False |
172.16.0.0/24 |
Provide development group access to development VPC |
S-xxxxx15 |
False |
10.0.0.0/16 |
Provide manager group access to any destination |
S-xxxxx16 |
False |
0.0.0.0/0 |
Provide manager group access to single host in development VPC |
S-xxxxx16 |
False |
10.0.2.119/32 |
Provide engineering group access to a subnet in the on-premises network |
S-xxxxx14 |
False |
172.16.0.128/25 |
Provide engineering group access to any destination |
S-xxxxx14 |
False |
0.0.0.0/0 |
Provide manager group access to Client VPN VPC |
S-xxxxx16 |
False |
192.168.0.0/24 |
Resulting behavior
-
The development group can access
10.0.0.0/16
, except for the single host10.0.2.119/32
. -
The manager group can access the public internet,
192.168.0.0/24
, and a single host (10.0.2.119/32
) within the10.0.0.0/16
network, but does not have access to172.16.0.0/24
or any of the remaining hosts in the10.0.0.0/16
network. -
The engineering group can access the public internet,
172.16.0.0/24
, and172.16.0.128/25
.
Note
Notice how adding the rule for the manager group to access 192.168.0.0/24
results in the development group no longer having access to that destination network.
Scenario 7: Access for all user groups
Rule description | Group ID | Allow access to all users | Destination CIDR |
---|---|---|---|
Provide engineering group access to on-premises network |
S-xxxxx14 |
False |
172.16.0.0/24 |
Provide development group access to development VPC |
S-xxxxx15 |
False |
10.0.0.0/16 |
Provide manager group access to any destination |
S-xxxxx16 |
False |
0.0.0.0/0 |
Provide manager group access to single host in development VPC |
S-xxxxx16 |
False |
10.0.2.119/32 |
Provide engineering group access to a subnet in the on-premises network |
S-xxxxx14 |
False |
172.16.0.128/25 |
Provide engineering group access to all networks |
S-xxxxx14 |
False |
0.0.0.0/0 |
Provide manager group access to Client VPN VPC |
S-xxxxx16 |
False |
192.168.0.0/24 |
Provide access to all groups |
N/A |
True |
0.0.0.0/0 |
Resulting behavior
-
The development group can access
10.0.0.0/16
, except for the single host10.0.2.119/32
. -
The manager group can access the public internet,
192.168.0.0/24
, and a single host (10.0.2.119/32
) within the10.0.0.0/16
network, but does not have access to172.16.0.0/24
or any of the remaining hosts in the10.0.0.0/16
network. -
The engineering group can access the public internet,
172.16.0.0/24
, and172.16.0.128/25
. -
Any other user group, for example "admin group," can access the public internet, but not any other destination networks defined in the other rules.