Hub-spoke support (static routing) with VMware NSX for vSphere 6.1.x

Products

• VMware NSX

Issue/Introduction

This article provides information about Hub-spoke support (static routing) with VMware NSX for vSphere 6.1.x and to resolve communication problem within localsubnet when overlapping subnets are deployed in hub-spoke mode (in this specific deployment scenario).

Overlapping subnet between spoke and hub

Let us consider this deployment scenario:



Hub B:

vNic_0: 10.117.35.205/24 vNic_1: 192.168.0.1/16
VPN-to-SpokeA: localsubnet=192.168.0.0/16, peersubnet=192.168.2.0/24
VPN-to-SpokeC: localsubnet=192.168.0.0/16, peersubnet=192.168.3.0/24

Spoke A:

vNic_0: 10.117.35.202/24 vNic_1: 192.168.2.1/24, vNic_2: 192.168.4.1/24
VPN-to-HubB: localsubnet=192.168.2.0/24, peersubnet=192.168.0.0/16
Internal route : dst 192.168.0.0/16 via vNic_0

Spoke C:

vNic_0: 10.117.35.203/24 vNic_1: 192.168.3.1/24
VPN-to-HubB: localsubnet=192.168.3.0/24, peersubnet=192.168.0.0/16

G 1:

interface_0: 192.168.2.253/24 interface_1: 192.168.6.253/24

Traffic between Spoke A, Spoke C and Hub B

• Spoke A and Hub B create a VPN tunnel for subnets 192.168.2.0/24 and 192.168.0.0/16.
• Spoke C and Hub B create a VPN tunnel for subnets 192.168.3.0/24 and 192.168.0.0/16.
• The traffic between subnets 192.168.2.0/24 and 192.168.3.0/24 are through Hub B over preceding two tunnels.

Since there is an overlapping between Hub B subnet 192.168.0.0/16 and Spoke A subnet 192.168.2.0/24, or between Hub B subnet 192.168.0.0/16 and Spoke C subnet 192.168.3.0/24 in the preceding deployment scenario, which results in these traffic problems:

• Traffic from subnet 192.168.2.0/24 of Spoke A to all other subnets 192.168.2.0/24, 192.168.4.0/24, 192.168.6.0/24
• Traffic from subnet 192.168.4.0/24 of Spoke A to other subnets like 192.168.2.0/24, 192.168.4.0/24, 192.168.6.0/24

Environment

VMware NSX for vSphere 6.1.x

Cause

This issue occurs because the traffic from Spoke A to hosts in subnet 192.168.2.0/24 matches IPSec policy localsubnet=192.168.2.0/24 and peersubnet=192.168.0.0/16. So the traffic will go over the VPN tunnel between Spoke A and Hub B instead of a plain traffic within subnets.

Resolution

To resolve this issue, configure passthroughSubnets in the extension option. If a problem arises in the communication between localsubnet and target subnet, input the target subnet into this key value pair. For example:

Spoke A:

• For traffic within subnet 192.168.2.0/24 (for example, ping from 192.168.2.1 to 192.168.2.2), configure as this:
  
  <extension>passthroughSubnets=192.168.2.0/24</extension>
  
  
• For local traffic between 192.168.2.0/24 and 192.168.4.0/24:
  
  <extension>passthroughSubnets=192.168.4.0/24</extension>
  
  
• For local traffic between 192.168.4.0/24 and 192.168.6.0/24:
  
  <extension>passthroughSubnets=192.168.6.0/24</extension>
  
  
• Overall for traffic between 192.168.2.0/24, 192.168.4.0/24, 192.168.6.0/24:
  
  <extension>passthroughSubnets=192.168.2.0/24,192.168.4.0/24,192.168.6.0/24</extension>
  

Spoke C:

• For traffic within 192.168.3.0/24 (for example, ping from 192.168.3.1 to 192.168.3.2), configure as this:
  
  <extension>passthroughSubnets=192.168.3.0/24</extension>