Modification of IPSEC tunnel results in the restart of all IPSEC VPN tunnels on the same ESG
search cancel

Modification of IPSEC tunnel results in the restart of all IPSEC VPN tunnels on the same ESG

book

Article ID: 345892

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

Symptoms:
  • Following an IPSEC VPN configuration change (such as the addition of a new IPSEC VPN tunnel, or even disabling / enabling an existing IPSEC VPN tunnel) OPENSWAN can be seen restarting all of the tunnels with the same local subnet in the vShield Edge logs.

    For example:
     
    Tunnel "2.2.2.2" with a local subnet of "10.10.0.0/16" is restarted through the vSphere Web Client:
    Year-MM-DateT06:00:32+00:00 vse-7xxxxxxa-exx2-4xxe-8cc9-3xxxxxxxxxxb-0 config: [URL.info] INFO :: C_OPENSWAN :: Configuring to restart 2.2.2.2, connection 1.1.1.1_10.10.0.0/16-2.2.2.2_10.20.0.0/16
     
  • Following the restart of tunnel "2.2.2.2", the remainder of the tunnels on the ESG **WITH THE SAME LOCAL SUBNET** are restarted by OPENSWAN:

    Year-MM-DateT06:00:03+00:00 vse-7xxxxxxa-exx2-4xxe-8cc9-3xxxxxxxxxxb-0 config: [URL.info] INFO :: C_OPENSWAN :: Configuring to restart 4.4.4.4, connection 1.1.1.1_10.10.0.0/16-4.4.4.4_10.30.0.0/16
    Year-MM-DateT06:00:03+00:00 vse-7xxxxxxa-exx2-4xxe-8cc9-3xxxxxxxxxxb-0 config: [URL.info] INFO :: C_OPENSWAN :: Configuring to restart 8.8.8.8, connection 1.1.1.1_10.10.0.0/16-8.8.8.8_10.60.0.0/22
    Year-MM-DateT06:00:03+00:00 vse-7xxxxxxa-exx2-4xxe-8cc9-3xxxxxxxxxxb-0 config: [URL.info] INFO :: C_OPENSWAN :: Configuring to restart 12.12.12.12, connection 1.1.1.1_10.10.0.0/16-12.12.12.12_10.60.0.0/16
  • IPSEC VPN tunnels with a different, or more specific subnet, will also be seen to be skipped by OpenSwan and will not be restarted:

    Year-MM-DateT06:00:03+00:00 vse-7xxxxxxa-exx2-4xxe-8cc9-3xxxxxxxxxxb-0 config: [URL.info] INFO :: C_OPENSWAN :: Skipping site 6.6.6.6, connection 1.1.1.1_10.10.1.0/24-6.6.6.6_10.40.1.0/24.It has not changed.

    Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.


Environment

VMware NSX for vSphere 6.2.x
VMware NSX for vSphere 6.4.x
VMware NSX for vSphere 6.3.x

Cause

The behavior is due to a combination of factors:

  1. "leftsourceip" is configured via a script, and it used when traffic generated by an ESG has to traverse an IPSEC VPN tunnel.
    - The script selects the "leftsourceip" by the matching the "leftsubnet", configured within the IPSEC VPN, with the subnet configured on the vNic interfaces.
     
  2. Within the ESG, the vNics are all maintained in a list, which the "leftsourceip" script references in sequential order.
    - The script will assign the IP address of the first interface it reaches in the list, that falls within the "leftsubnet" specified in the configuration of the IPSEC VPN tunnel.
     
  3. Currently, this list is not sorted in anyway and may exist in any random order, which may change between the publication of any two configuration changes.
     
  4. As such, with a "leftsubnet" configured that encompasses more than a single vNic, a published configuration change will initiate the "leftsourceip" script, which may in turn reach a different matching vNic than it had the time previous, causing a restart of all of the IPSEC VPNs configured with the first "leftsourceip".

For example:

Note: Please cite the following tunnel and ESG vNic configurations for the following example.

Tunnel "2.2.2.2" Configurations


conn 1.1.1.1_10.10.0.0/16-2.2.2.2_10.20.0.0/16
left=1.1.1.1
also=global
leftid=1.1.1.1
rightid=2.2.2.2

leftsubnet=10.10.0.0/16
right=2.2.2.2
rightsubnet=10.20.0.0/16  
authby=secret
pfs=yes
phase2alg=aes256-sha1;modp1024
ike=aes256-sha1;modp1024!

# extensions for this conn
leftsourceip=10.10.1.1
 

ESG vNIC Configuration


vNic_1 Link encap:Ethernet HWaddr 00:50:56:X3:XX:F1
          inet addr:10.10.1.1 Bcast:10.10.1.255 Mask:255.255.255.0

vNic_2 Link encap:Ethernet HWaddr 00:50:56:X3:7X:9X
          inet addr:10.10.50.1 Bcast:10.10.50.255 Mask:255.255.255.0
 
As described above, the symptoms described are caused because the ESG is configured with more than 1 vNic that falls within the specified local subnet (leftsubnet) of an IPSEC VPN Tunnel. This is depicted in the example above.
  • We can see that the local subnet specified is 10.10.0.0/16, and that the ESG has two vNics that fall within that subnet:

    vNic_1 --> IP Address of 10.10.1.1/24
    vNic_2 --> IP Address of 10.10.50.1/24
  •  With a "leftsubnet" of 10.10.0.0/16, the first time the "leftsourceip" script runs, it may reach vNic_1 in the list first, which falls under the 10.10.0.0/16 subnet with an IP address of 10.10.1.1/24. The script will then assign the "leftsourceip" an IP address of 10.10.1.1.
  • Following any additional IPSEC VPN configuration changes, the "leftsourceip" will run again, and may reach vNic_2 in the list first, which also has an IP that falls under the scope of the 10.10.0.0/16 subnet, being 10.10.50.0/24. As such, all of the IPSEC VPNs that originally received the "leftsourceip" of 10.10.1.1 will be restarted.

Resolution

This issue is resolved in VMware NSX for vSphere 6.3.6, available at Support Documents and Downloads (broadcom.com).

Note: This is a known issue affecting VMware NSX for vSphere 6.4.x. This issue is resolved in VMware NSX for vSphere 6.4.2.

Workaround

To work around this issue if you do not want to upgrade, modify the IPSEC VPN tunnels impacted, to ensure that the local subnet for each IPSEC VPN tunnel only encompasses the IP address of a single ESG vNic.

For more information, see the Configure IPSec VPN Parameters section of the NSX Administration Guide. Also, see the Configure IPSec VPN Parameters Example section of the NSX Administration Guide.

Powered by Wolken Software