Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

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

Last Updated: 9/29/2023Categories: InformationalTotal Views: 3074Language:
English

Subscribe to get an email
newsletter with new updates

Please provide article feedback:

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.

Cause

The behavior is due to a combination of factors:

"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.

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.

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.

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 VMware Downloads.

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.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

KB
•
Horizon 7 Extended Service Branches (ESB) について (52845)

Results 1-2 of 2

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware NSX for vSphere

Related Versions:

VMware NSX for vSphere 6.4.x

VMware NSX for vSphere 6.3.x

VMware NSX for vSphere 6.2.x

Take Our Survey

Support Assistant