[VMC on AWS] vCenter connectivity issue due to VPN configurations
Article ID: 313646
Updated On:
Products
VMware Cloud on AWS
Issue/Introduction
Symptoms:
The on-Premises is connected to the SDDC via a Policy based VPN and the SDDC is connected to the Transit Gateway via a Route-based VPN. When a new default route is created in VMC, the VDI session in the on-Prem Data center loses access to vCenter within VMC that traverses through a policy-based VPN.
Cause
Whenever a default route is created, all traffic starts moving through the default route. This is the reason why the on-Prem Datacenter is losing connectivity to the vCenter.
Resolution
When a new default route is added to the AWS Transit Gateway and if the on-premises will try to reach cloud vCenter through the policy-based VPN, the traffic gets dropped and there will be a routing issue in the NSX T0 router. This is expected behavior.
1. Check for the reply from the VDI machine if it is reaching cloud vCenter by performing a ping test.
2. Check with on-premises networking for reverse tracert.
The alternative (preferred) solution, would be to migrate the policy-based VPN to a route-based VPN.
In case the Direct Connect (DX) is available, the DX can be used as the primary route that will propagate the Border Gateway Protocol (BGP) routes when the default route is added through the AWS Transit Gateway, and as a backup, the route-based VPN can take precedence in populating the BGP routes if DX were to have any connectivity issues. This is when the "Use VPN as a backup to Direct Connect" slider in VMC UI is selected and switched to "Enabled", and on-premises VDI workloads will still be able to route to cloud vCenter through the AWS Transit Gateway with the default route added.
1. Check for the reply from the VDI machine if it is reaching cloud vCenter by performing a ping test.
2. Check with on-premises networking for reverse tracert.
3. List down the tracert output of the existing configuration (without the Transit Gateway default route).
4. Cross verify if there is a routing issue in the NSX T0 router when the default route is being advertised.
5. Have the Transit Gateway re-added in with the default route and re-attempt the tracert from cloud vCenter to test the machine in order to get a better understanding of the routing path.
The alternative (preferred) solution, would be to migrate the policy-based VPN to a route-based VPN.
In case the Direct Connect (DX) is available, the DX can be used as the primary route that will propagate the Border Gateway Protocol (BGP) routes when the default route is added through the AWS Transit Gateway, and as a backup, the route-based VPN can take precedence in populating the BGP routes if DX were to have any connectivity issues. This is when the "Use VPN as a backup to Direct Connect" slider in VMC UI is selected and switched to "Enabled", and on-premises VDI workloads will still be able to route to cloud vCenter through the AWS Transit Gateway with the default route added.
Additional Information
Impact/Risks:
The default route will not always override the VPN routes. However, there is a need for internet traffic to traverse through the route-based VPN to Transit Gateway.
The default route will not always override the VPN routes. However, there is a need for internet traffic to traverse through the route-based VPN to Transit Gateway.
Feedback
Yes
No
Powered by
