Configuring network ACLs for use with VPN

Scenario 1: VPN gateway and virtual server instance are in the same subnet

In this scenario, both the VPN gateway and the virtual server instance reside within the same subnet in the VPC and are protected by a shared NACL. This setup simplifies network control by applying a consistent set of rules to both resources.

These steps describe the packet flow through the shared NACL subnet pair, as illustrated in the following diagram.

1. Encrypted traffic flows between your on-premises (peer) gateway and the shared subnet, covering IP ranges from both sides, which are a part of the encrypted domain (On-premises private CIDR, VPC CIDR).
2. After the packet reaches the VPC VPN gateway, it is decrypted and forwarded to the virtual server instance in the same subnet.
3. The response packets to your on-premises network travel back to the VPN gateway.
4. Finally, the packets are encrypted and returned to the on-premises gateway from the shared subnet.

When the VPN gateway and virtual server instance are in the shared subnet and you create a shared NACL, you must add the following rules for bidirectional traffic flow between your on-premises gateway and the shared subnet NACL pair. For more information, see Setting up network ACLs.

1. The first pair of inbound and outbound rules in the table allow management traffic. This traffic uses IKE and IPsec protocols for establishing and maintaining the VPN connection between your on-premises gateway and the VPN gateway.
2. The second pair of inbound and outbound rules allow VPN tunnel traffic, which flows between your on-premises network and the VPC CIDR through the established VPN tunnel.
3. Optional: The last inbound rule allows traffic for connectivity tests, such as pinging the VPN gateway or VPC virtual server instance for reachability checks and troubleshooting.

For example, the following table shows the source and destination IP addresses for inbound and outbound rules. In this example, both the VPN gateway and the virtual server instance are in the shared subnet CIDR 10.240.0.0/24. The CIDR IP address of the VPN gateway is 10.240.0.4/32.

Scenario 2: VPN gateway and virtual server instance are in different subnets in the same VPC

In this scenario, the VPN gateway and the virtual server instance reside in different subnets within the same VPC, and a shared NACL is applied to manage traffic between them. This configuration requires addiotnal considerations for traffic routing between the subnets.

These steps describe the packet flow through the shared NACL and different subnets, as illustrated in the following diagram.

1. Encrypted traffic flows between your on-premises (peer) gateway and the VPN gateway subnet, covering IP ranges from both sides, which are a part of the encrypted domain (On-premises private CIDR, VPC CIDR).
2. After the packet reaches the VPC VPN gateway, it is decrypted and forwarded from the VPN subnet to the VPC virtual server subnet.
3. The response packets to your on-premises network travel back to the VPN subnet.
4. Finally, the packets are encrypted and returned to the on-premises gateway from the VPN subnet.

When the VPN gateway and virtual server instance are in different subnets and you create a shared NACL, you must add the following rules for bidirectional traffic flow between your on-premises gateway and the different subnets.

For example, the following table shows the source and destination IP addresses for inbound and outbound rules. In this example, the VPN gateway is in the subnet CIDR 10.240.0.0/24 and the virtual server instance is in the subnet CIDR 10.240.2.0/24.

Scenario 1: VPN gateway and virtual server instance in different subnets with separate NACLs

When the VPN gateway and virtual server instance are in different subnets and you create two NACLs: one attached to the VPN gateway subnet, and the other attached to the virtual server subnet, you must add the following rules for traffic flow between your on-premises gateway and the different subnets.

Encrypted traffic flows between your on-premises gateway and the VPN gateway subnet, covering both on-premises and VPC IP ranges within the encrypted domain. After the packet reaches the VPC VPN gateway, it is decrypted and forwarded to the VPC virtual server subnet. The response packets are then sent back through the VPN subnet, where they are encrypted again and returned to the on-premises gateway.

Scenario 2: VPN gateway and virtual server instance in different VPCs connected through a transit gateway

In this scenario, the VPN gateway and the virtual server instance reside in different subnets within different VPCs connected by a transit gateway. This configuration uses the same procedure as the preceding scenarios to forward packets through the subnets in different VPCs.

1. Encrypted traffic flows between your on-premises gateway and the VPN gateway subnet.
2. After the packet reaches the VPC VPN gateway, it is decrypted and forwarded to the VPC virtual server subnet.
3. The response packets are then sent back through the VPN subnet, where they are encrypted again and returned to the on-premises gateway.
4. The transit gateway is responsible for interconnecting the two VPCs and forwarding packets between them.

When the VPN gateway and virtual server instance are in different VPCs with different subnets and different NACLs, you must add the following rules for traffic flow between your on-premises gateway and the subnets in different VPCs.