Description:
There is a bug in VNS3 4.0.x-4.3.5 which can cause site-to-site IPsec connections which use NAT-T, also called Nat Traversal (IPsec protocol encapsulated over UDP 4500) to drop/disconnect.
This bug is fixed in the latest 4.3.6 release which is available now for "bring your own license" customers, and will be in the cloud marketplaces within the next several weeks.
Symptom:
The situation manifests itself as working site-to-site connections, configured for nat-t, that are working, suddenly lose connection, and do not recover even when restarting the tunnel or restarting the ipsec subsystem.
Workaround:
A reboot will fix the situation, and you will see the site-to-site tunnels connect. However, the issue could recur unless the remediation steps listed in our knowledge base article are followed:
If you are not actively adding/deleting IPsec endpoints to a given VNS3 controller at this time, then the problem will not occur. If you are adding/deleting VNS3 NAT-T endpoints, especially if editing the remote peer IP Address, then the problem could occur.
The attached detailed PDF takes you through the information needed to correct or prevent this from happening.
Our recommendation is in two parts.
1) If you have NAT-T connections currently working on a VNS3 controller and are not actively updating them at this time, we recommend take no action. We assume most customers will want to migrate to the 4.3.6+ release which has the Meltdown/Spectre patches over the next weeks to months. When doing this update you will then receive the fix.
2) If you have a controller with many endpoints, and you are actively doing add/edit/deletes on that controller on a regular basis, we recommend upgrading to 4.3.6 OR in the interim deploy the suggested firewall rules.
If you are familar with the VNS3 firewall and the IPsec setup here is a summary of the firewall rules you CAN add if concerned.
At the top of the VNS3 IPsec page there is a "Local Private IP"...this is a persistent NAT address used to that your IPsec configuration does not change at all between upgrades, VPC changes, instance re-launches etc. This is one address needed. On the upper right of the VNS3 Web UI the cloud "private IP" is listed, this is the actual network interface address of the VNS3 controller.
WIth this data you can add a firewall rule of this format:
POSTROUTING_CUST -p udp --sport 500 -s <Local Private IP> -j SNAT --to <Private IP>:500
POSTROUTING_CUST -p udp --sport 4500 -s <Local Private IP> -j SNAT --to <Private IP>:4500
See the attached PDF for more specific detail.