Microsoft Azure Site-to-Site VPN: Can Ping Workstations, No RDP After Prior Success
Cloud services are extremely comprehensive solutions that can have complex problems. While each solution on the market is at different levels of maturity, none are immune to the growing pains that are expected with newer technologies. Here’s one situation I came across that I hope in sharing, will help other admins avoid pulling their hair out.
Chief Complaint
A single user was no longer able to connect to their assigned VM. Remote Desktop Connection reported that the system could not be reached.
The Symptoms
- The VM in question and the user’s local workstation could ping back and forth to each other.
- The VM in question could not connect to the local network printer anymore.
- The user’s local workstation could not connect to any VM via RDP, Active Directory, or file shares.
- Other local workstations in the office experienced no issue at all.
Resolution / Cause
The resolution was to rebuild the VPN gateway designated in Azure. Once the gateway was rebuilt and the information updated on the local equipment, everything went back to normal.
In this situation, I had little tools available at my disposal. Though based on all the evidence before me through diagnosis, this is what seems most plausible as to the cause. The network equipment had an update that morning, and one of the updates resolved potential vulnerabilities in IPsec. Whatever these changes did, it caused certain protocols and services to stop crossing the already configured VPN. Issues progress as time went on suggesting timeout periods were being hit.
Once the VPN gateway was deleted and re-created in Azure, the only local equipment changes were made was the IP to the remote gateway and the new shared key. This all suggests that Azure’s VPN gateway may have still been relying on older configuration that was agreed upon during the Phase 1 setup of the connection prior to the IPsec updates. This information was not discarded by Azure even after local equipment reboots so it just re-established the connection with the older details. For this to work, the local network equipment would have done the same.
In the future, I will probably consider it a best practice scenario that after IPsec gets updates, to have the gateways rebuilt just to avoid the risk. If you’ve run into this before and maybe found a faster way, feel free to comment!