Check Network ACLs configuration

Network ACLs are stateless and require explicit rules for both inbound and outbound traffic.

1. Identify the ACL attached to the subnet that is hosting your virtual server instances and the ACL attached to the subnet that is hosting the VPN gateway.

2. Ensure that both ACLs allow UDP traffic on ports 500 and 4500 for VPN negotiation and encapsulation. The following table shows the ACL configuration for correct traffic flow:

   Required ACL rules for VPN traffic

   Direction	Protocol	Source	Destination	Source Port	Dest Port	Action
   Inbound	UDP	Any	Any	Any	500	Allow
   Inbound	UDP	Any	Any	Any	4500	Allow
   Outbound	UDP	Any	Any	500	Any	Allow
   Outbound	UDP	Any	Any	4500	Any	Allow

3. Adjust the rules to match your networks. For example, for traffic to flow from VPC subnet 10.0.0.0/16 to on-premises network 192.168.0.0/16, configure the following rules on the VPC subnet ACL:

   ACL rules for application traffic

   Direction	Protocol	Source	Destination	Action
   Outbound	All or specific	10.0.0.0/16	192.168.0.0/16	Allow
   Inbound	All or specific	192.168.0.0/16	10.0.0.0/16	Allow

4. Ensure that ACLs allow the specific protocols that are required by your applications. For example, ICMP traffic for ping tests might be blocked even when TCP or UDP application traffic is allowed.

5. If you replace broad "allow any-to-any" rules with restrictive TCP-only rules, you might inadvertently block required VPN flows. When you implement restrictive rules, consider the following conditions:

   • Allow all protocols between VPN gateway subnet and workload subnets.
   • Test the connection thoroughly after each ACL change and verify that no implicit deny rules exist that can block traffic.

   To confirm ACLs are the issue, temporarily add an allow-all rule and test connectivity. If traffic flows, the problem is ACL configuration. For more information on ACL configuration guidance, see About network ACLs, and Configuring network ACLs for use with VPN.

Check security groups configuration

Security groups are stateful but still require proper configuration for VPN traffic.

1. For virtual server instances, ensure that security groups allow:

   • Inbound traffic from on-premises CIDR ranges
   • Outbound traffic to on-premises CIDR ranges
   • Required application protocols and ports

2. Verify that no security group is blocking traffic at the subnet level to the other resources.

Verify VPC routing configuration

1. Check the routing table associated with your workload subnet.

   • Go to Infrastructure > Network > Routing tables.
   • Select your VPC and identify the routing table for the subnet.
   • Verify that a route exists for the on-premises CIDR pointing to the VPN connection.

2. Verify policy-based VPN routing configuration.

   • Go to Infrastructure > Network > Routing tables.
   • Check whether the routing table has Accept routes from VPN gateway turned on, which allows the VPN gateway to automatically create routes in the routing table for peer CIDRs. For more information, see Creating a route.

   For policy-based VPN, don't create any routes manually to on-premises networks that overlap with VPN-managed routes. This action can cause routing conflicts.

3. Avoid VPN gateway and workload in the same subnet: If the VPN gateway and virtual server instances are in the same subnet, routing issues can occur. Move workloads to a separate, nonoverlapping subnet.

4. Verify route-based VPN routing configuration.

   • Verify that the routes in the routing table point to the VPN gateway and not to private IP addresses. For more information, see About routing tables and routes.
   • Check that routes don't create loops or conflicts.
   • Ensure that the distribute_traffic property is set when the VPN uses dual tunnels. For more information, see Distributing traffic for a route-based VPN.

   For more information on resolving routing and reachability issues, see Why do routing and reachability issues exist with my site-to-site VPN?.

5. Verify route avertisement to Transit Gateway

   • When your architecture integrates Transit Gateway for forwarding traffic from another environment to the VPN gateway VPC, check whether the Advertise to toggle is turned on. This option advertises the learned routes to other VPCs through the Transit Gateway. For more information, see Configuring route propagation for VPN gateways.

Verify on-premises routing configuration

Traffic must be routed correctly on the on-premises side:

1. Confirm that routes exist for VPC CIDRs on your on-premises network.
2. Verify that the return traffic is directed back through the VPN tunnel, not through other paths.
3. Check for asymmetric routing where traffic goes through the VPN in one direction but returns through a different path.

Resolve Transit Gateway routing issues

In dynamic route-based VPNs that use Transit Gateway, route advertisement, route conflicts, or Transit Gateway configuration issues can prevent traffic from reaching its destination even when the IPsec tunnel is established.

1. Verify Transit Gateway connection: Confirm that the VPN is connected to the Transit Gateway and check that the service connection status shows as Up. Dynamic routing requires this connection even if IPsec is up.

2. Review the Transit Gateway route report,

   • Go to Interconnectivity > Transit Gateway.
   • Select your Transit Gateway and click Generate report in the Routes section.
   • Verify that both source and destination IP addresses appear in the report.
   • The on-premises IP addresses must be advertised from the VPN connection.
   • IBM Cloud IP addresses must be advertised from VPC or other connections.

3. Check for route conflicts: Look for overlapping routes in the report and resolve conflicts by adjusting VPC address prefixes. Ensure that advertised routes don't exceed quota limits. For more information, see How to resolve VPN quota limit issues?.

4. Verify ACLs on destination VPCs: Check ACLs on both the VPN VPC and destination VPCs and make sure that appropriate allow rules exist for cross-VPC traffic with Transit Gateway.

Review traffic selector narrowing

When you configure multiple local and remote CIDRs on an IBM Cloud VPN connection, the VPN gateway sends all CIDRs in its traffic selector proposal. However, some peer devices respond with only one CIDR pair during IKE negotiation, a behavior called "traffic selector narrowing."

Example scenario:

• IBM VPN configuration:

  • Local CIDRs: 192.168.1.0/24, 192.168.2.0/24
  • Remote CIDRs: 10.0.1.0/24, 10.0.2.0/24

• Peer device negotiates between 192.168.1.0/24 and 10.0.1.0/24

• Result:

  • Traffic from 192.168.1.5 to 10.0.1.1 works.
  • Traffic from 192.168.2.10 to 10.0.1.1 fails.

Resolve multi-CIDR traffic issues

1. Review logs: Review IKE and IPsec logs to identify which CIDR pairs were successfully negotiated. If a specific IP address is not present, the tunnel does not exist for that IP. If only one CIDR pair is negotiated but multiple pairs are configured, your peer device is narrowing traffic selectors.

   selecting traffic selectors for us:
   config: 192.168.1.0/24, received: 192.168.1.5/32 => match: 192.168.1.5/32
   config: 192.168.2.0/24, received: 192.168.1.5/32 => no match
   
   selecting traffic selectors for other:
   config: 10.0.1.0/24, received: 10.0.1.1/32 => match
   config: 10.0.2.0/24, received: 10.0.1.1/32 => no match
   config: 10.0.3.0/24, received: 10.0.1.1/32 => no match
   
   CHILD_SA peer established with TS 192.168.1.5/32 === 10.0.1.1/32
   

   In route-based VPNs, the peer gateway can narrow the proposed traffic selectors, which may result in the tunnel covering only a subset of the intended CIDR ranges. For example, if the local side proposes 0.0.0.0/0 and the peer responds with 192.168.0.0/16, the resulting tunnel covers only 192.168.0.0/16. If traffic for certain networks is failing, review the VPN negotiation logs and ensure that the peer gateway configuration includes all required CIDR ranges and that the negotiated selectors match the intended tunnel coverage.

2. Check peer device capabilities: Consult peer documentation for multi-CIDR support and verify whether the peer supports multiple traffic selectors per tunnel. Check for configuration options that are related to tunnel sharing or CIDR limits. For more information, see Connecting to your on-premises network.

3. Configure CIDR handling (for policy-based VPN):

   1. Split into separate connections (recommended): Create individual VPN connections for each CIDR pair. This setup enables each connection to negotiate its own tunnel and provides clear separation for easier troubleshooting.

   2. Configure peer to accept multiple CIDRs: If supported by your peer device, modify the peer configuration to allow multiple CIDRs per tunnel. After you make changes, test the setup thoroughly to ensure that all CIDR pairs are negotiated.

   3. Consolidate CIDRs: Use larger network ranges instead of multiple smaller ones. For example, use 10.243.0.0/24 instead of 8 separate /32 addresses. Remove unnecessary or overlapping CIDRs that can cause traffic selector mismatches or partial connectivity failures.

4. Generate traffic from the peer side: Some peer devices establish IPsec tunnels only when traffic originates from their side. If traffic must originate from on-premises, generate initial traffic from the peer toward the VPN gateway, which triggers tunnel establishment for all configured CIDR pairs. After the tunnel is established, bidirectional traffic must work.

Planing peer CIDR updates

Before you update peer CIDRs, keep the following considerations in mind:

• Expect a brief traffic interruption while existing routes are removed and new routes are applied.

• Schedule CIDR updates during maintenance windows or other low-traffic periods to minimize user impact.

• Review the existing peer CIDRs and identify opportunities to consolidate smaller CIDR blocks into larger summarized ranges (for example, replacing multiple /24 subnets with a /23 subnet).

During the update, follow these steps:

• Remove the existing peer CIDRs and add the new consolidated CIDR block.

• Verify that the updated routes appear in the routing table.

• Test connectivity and monitor traffic to confirm that service is restored as expected.

• Communicate the expected interruption to affected users before making the change.

Reducing the impact of configuration changes

Use the following practices to minimize the impact of VPN configuration changes:

• Use route-based VPNs when possible, as they generally handle routing changes more flexibly than policy-based VPNs.

• Test configuration changes in a nonproduction environment before applying them to production workloads.

• Make changes incrementally to simplify validation and troubleshooting.

• Monitor connection status and traffic flow during and after configuration updates.

• Maintain a rollback plan by documenting the current configuration before making changes.