IBM Cloud Docs
Configuring network ACLs for use with VPN

Configuring network ACLs for use with VPN

You can set up network access control lists (NACLs) on the VPN gateway subnet and other VPC subnets that communicate over the VPN tunnel.

A NACL is a stateless set of rules that controls incoming and outgoing traffic at the subnet level. Unlike security groups, which filter traffic to and from individual virtual server instances, NACLs manage traffic that flows to and from entire subnets.

A VPN gateway and a VPC virtual server instance can share the same or different NACLs, and can reside in the same or different subnet CIDR blocks.

Use case 1: VPN gateway and virtual server instance share NACL

This use case demonstrates scenarios where the IBM Cloud VPN gateway and the VPC virtual server instance are governed by a shared NACL, enabling consistent traffic control policies. In both scenarios, the VPN gateway and virtual server are part of the same VPC.

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.

Packet flow through VPC NACL
Packet flow through the shared NACL 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.
Inbound and outbound rules on the shared NACL and shared subnet
Inbound and Outbound Rules Protocol Source IP Source Port Destination IP Destination Port
Inbound All Your on-premises gateway public IP N/A VPN gateway's subnet N/A
Outbound All VPN gateway's subnet N/A On-premises gateway public IP N/A
Inbound All On-premises, private CIDR N/A VPC CIDR N/A
Outbound All VPC CIDR N/A On-premises, private CIDR N/A
Inbound (optional) ICMP Any N/A Any N/A

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 192.168.1.0/24.

Inbound and outbound rules on the shared NACL and shared subnet example
Inbound and Outbound Rules Protocol Source IP Source Port Destination IP Destination Port
Inbound All Your on-premises gateway public IP[1] N/A 192.168.1.0/24 N/A
Outbound All 192.168.1.0/24 N/A On-premises gateway public IP[2] N/A
Inbound All On-premises, private CIDR N/A 192.168.1.0/24 N/A
Outbound All 192.168.1.0/24 N/A On-premises, private CIDR N/A
Inbound (optional) ICMP Any N/A Any N/A

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.

Packet flow through VPC NACL
Packet flow through the NACL with different subnets

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.

Inbound and outbound rules on the shared NACL and different subnet
Inbound and Outbound Rules Protocol Source IP Source Port Destination IP Destination Port
Inbound All Your on-premises gateway public IP N/A VPN gateway's subnet N/A
Outbound All VPN gateway's subnet N/A On-premises gateway public IP N/A
Inbound All On-premises, private CIDR N/A VPC CIDR N/A
Outbound All VPC CIDR N/A On-premises, private CIDR N/A
Inbound (optional) ICMP Any N/A Any N/A

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 192.168.1.0/24 and the virtual server instance is in the subnet CIDR 192.168.2.0/24.

Inbound and outbound rules on the shared NACL and different subnet example
Inbound and Outbound Rules Protocol Source IP Source Port Destination IP Destination Port
Inbound All Your on-premises gateway public IP[3] N/A 192.168.1.0/24 N/A
Outbound All 192.168.1.0/24 N/A On-premises gateway public IP[4] N/A
Inbound All On-premises, private CIDR N/A 192.168.2.0/24 N/A
Outbound All 192.168.2.0/24 N/A On-premises, private CIDR N/A
Inbound (optional) ICMP Any N/A Any N/A

Use case 2: VPN gateway and virtual server instance use different NACLs

This use case demonstrates scenarios where the IBM Cloud VPN gateway and the VPC virtual server instance are governed by different NACL, enabling consistent traffic control policies. In the first scenario, the VPN gateway and virtual server are part of the same VPC, whereas in the second scenario they are in different VPCs connected by a transit gateway.

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.

Packet flow through different VPC NACLs
Packet flow through different NACLs with different subnets

Configuring NACL for VPN gateway subnet

This NACL is attached to the VPN gateway subnet. The traffic rules for the VPN gateway subnet must cover the management traffic that is used to set up the VPN tunnel and the encrypted VPN tunnel traffic between your on-premises network and the VPC.

Inbound and outbound rules on VPN gateway's subnet
Inbound and Outbound Rules Protocol Source IP Source Port Destination IP Destination Port
Inbound All Your on-premises gateway public IP N/A VPN gateway's subnet N/A
Outbound All VPN gateway's subnet N/A On-premises gateway public IP N/A
Inbound All On-premises private CIDR N/A VPC CIDR N/A
Outbound All VPC CIDR N/A On-premises, private CIDR N/A
Inbound (optional) ICMP Any N/A Any N/A

Configuring NACL for virtual server instance subnet

This NACL is attached to the virtual server subnet. The traffic rules for the virtual server subnet must cover VPN tunnel traffic for communication between your on-premises network and the virtual server instance.

Inbound and outbound rules on virtual server subnets
Inbound and Outbound Rules Protocol Source IP Source Port Destination IP Destination Port
Inbound All On-premises, private CIDR N/A VPC CIDR N/A
Outbound All VPC CIDR N/A On-premises, private CIDR N/A

Troubleshooting traffic

Optional: This rule allows traffic for connectivity tests, such as pinging the VPN gateway or VPC virtual server instance for reachability checks and troubleshooting.

Rules for traffic troubleshooting
Inbound Rules Protocol Source IP Source Port Destination IP Destination Port
Inbound (optional) ICMP Any N/A Any N/A

Examples: Configuring VPN gateway and virtual server subnets in a shared VPC

The following examples illustrate the specific NACL rules that are applied to both the VPN gateway and virtual server instance subnets. These examples help you to set up your NACLs correctly according to your specific subnet CIDRs and traffic requirements.

This table shows the source and destination IP addresses for inbound and outbound rules. In this example, the VPN gateway is in subnet CIDR 192.168.1.0/24, and the virtual server is in subnet CIDR 192.168.2.0/24.

Inbound and outbound rules on VPN gateway's subnet example
Inbound and Outbound Rules Protocol Source IP Source Port Destination IP Destination Port
Inbound All Your on-premises gateway public IP[5] N/A 192.168.1.0/24 N/A
Outbound All 192.168.1.0/24 N/A On-premises gateway public IP[6] N/A
Inbound All On-premises, private CIDR N/A 192.168.2.0/24 N/A
Outbound All 192.168.2.0/24 N/A On-premises, private CIDR N/A
Inbound (optional) ICMP Any N/A Any N/A

This table illustrates the NACL rules for the virtual server subnet, showing the same type of inbound and outbound traffic flow as described for the VPN gateway subnet.

Inbound and outbound rules on virtual server subnet example
Inbound and Outbound Rules Protocol Source IP Source Port Destination IP Destination Port
Inbound All On-premises, private CIDR N/A 192.168.2.0/24 N/A
Outbound All 192.168.2.0/24 N/A On-premises, private CIDR N/A

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.

Packet flow through different VPC NACLs
Packet flow through different VPCs with different NACLs and subnets

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.

Configuring NACL for VPN gateway subnet

This NACL is attached to the VPN gateway subnet. The traffic rules for the VPN gateway subnet must cover the management traffic used to set up the VPN tunnel and the encrypted VPN tunnel traffic between your on-premises network and the VPC.

Inbound and outbound rules on VPN gateway's subnet
Inbound and Outbound Rules Protocol Source IP Source Port Destination IP Destination Port
Inbound All Your on-premises gateway public IP N/A VPN gateway's subnet N/A
Outbound All VPN gateway's subnet N/A On-premises gateway public IP N/A
Inbound All On-premises private CIDR N/A VPC CIDR N/A
Outbound All VPC CIDR N/A On-premises, private CIDR N/A
Inbound (optional) ICMP Any N/A Any N/A

Configuring NACL for virtual server instance subnet

This NACL is attached to the virtual server subnet. The traffic rules for the virtual server subnet must cover VPN tunnel traffic for communication between your on-premises network and the virtual server instance.

Inbound and outbound rules on virtual server subnets
Inbound and Outbound Rules Protocol Source IP Source Port Destination IP Destination Port
Inbound All On-premises, private CIDR N/A VPC CIDR N/A
Outbound All VPC CIDR N/A On-premises, private CIDR N/A

Troubleshooting traffic

Optional: This rule allows traffic for connectivity tests, such as pinging the VPN gateway or VPC virtual server instance for reachability checks and troubleshooting.

Rules for traffic troubleshooting
Inbound Rules Protocol Source IP Source Port Destination IP Destination Port
Inbound (optional) ICMP Any N/A Any N/A

Examples: Configuring VPN gateway and virtual server subnets in different VPC

The following examples illustrate the specific NACL rules that are applied to both the VPN gateway and virtual server instance subnets in different VPC. These examples help you to set up your NACLs correctly according to your specific subnet CIDRs and traffic requirements.

The following table shows the source and destination IP addresses for inbound and outbound rules. In this example, the VPN gateway in VPC A is in subnet CIDR 192.168.1.0/24, and the virtual server in VPC B is in subnet CIDR 192.168.2.0/24.

Inbound and outbound rules on VPN gateway's subnet example
Inbound and Outbound Rules Protocol Source IP Source Port Destination IP Destination Port
Inbound All Your on-premises gateway public IP[7] N/A 192.168.1.0/24 N/A
Outbound All 192.168.1.0/24 N/A On-premises gateway public IP[8] N/A
Inbound All On-premises, private CIDR N/A 192.168.2.0/24 N/A
Outbound All 192.168.2.0/24 N/A On-premises, private CIDR N/A
Inbound (optional) ICMP Any N/A Any N/A

This table illustrates the NACL rules for the virtual server subnet in VPC B, showing the same type of inbound and outbound traffic flow as described for the VPN gateway subnet in VPC A.

Inbound and outbound rules on virtual server subnet example
Inbound and Outbound Rules Protocol Source IP Source Port Destination IP Destination Port
Inbound All On-premises, private CIDR N/A 192.168.2.0/24 N/A
Outbound All 192.168.2.0/24 N/A On-premises, private CIDR N/A

  1. Set the source IP to your on-premises gateway public IP for the inbound rule. This setting allows traffic from the on-premises subnet to the VPC. ↩︎

  2. Set the destination IP to your on-premises gateway public IP address for the outbound rule. This setting allows traffic from the VPC to the on-premises subnet. ↩︎

  3. Set the source IP to your on-premises gateway public IP for the inbound rule. This setting allows traffic from the on-premises subnet to the VPC. ↩︎

  4. Set the destination IP to your on-premises gateway public IP address for the outbound rule. This setting allows traffic from the VPC to the on-premises subnet. ↩︎

  5. Set the source IP to your on-premises gateway public IP for the inbound rule. This setting allows traffic from the on-premises subnet to the VPC. ↩︎

  6. Set the destination IP to your on-premises gateway public IP address for the outbound rule. This setting allows traffic from the VPC to the on-premises subnet. ↩︎

  7. Set the source IP to your on-premises gateway public IP for the inbound rule. This setting allows traffic from the on-premises subnet to the VPC. ↩︎

  8. Set the destination IP to your on-premises gateway public IP address for the outbound rule. This setting allows traffic from the VPC to the on-premises subnet. ↩︎