Azure VPN Client not routing traffic from some P2S workstations

Question

Azure VPN Client not routing traffic from some P2S workstations

Mike Crowley 216

We have a few file servers running in Azure and on occasion, a P2S VPN user will not be able to reach them. When we use Test-NetConnection <fqdn> -Port 445 the name resolves correctly, however the TCP connection will fail. On occasion, Ping will succeed, but this isn't consistent. Get-NetRoute returns the correct routes for our simple VNET, with the same properties as healthy workstations. The problem only seems to occur on ~10% of the VPN users, and doing an AutoPilot Reset "fixes" the issue, but obviously this is not an appropriate solution.

Client: Windows 11 Azure AD Joined
Auth: Azure AD
Tunnel Type: OpenVPN / SSL
Gateway SKU: VpnGw2

I saw kb5026372 was causing users issues, but as far as I can tell, none of our users have this update.

Nothing stood out to me in the AzureVpnCxn.log file.

On one occasion, I did a packet capture from an impacted workstation and saw the traffic wasn't being sent over the correct (WAN Miniport) interface. I have also occasionally seen Event 2505 in the System log:

The server could not bind to the transport \Device\NetBT_Tcpip_{B771EE23-8FE4-4E7B-858D-EA8A1EBBB6FE} because another computer on the network has the same name. The server could not start.

I am not sure the above error is related, but it makes sense to me that if the VPN adapter can't bind properly, the routing would be broken, though this is the guid for the user's wifi adapter, not their miniport adapter, so maybe unrelated.

I'm not sure where else to look.

Is there additional routing logic beyond the routing table?

Is there any way to reset or otherwise ensure the adapter is healthy?

Has anyone seen this before?

Sadly it always works on my machine...

Bas Pruijn 956 Reputation points

2023-05-25T06:43:06.3066667+00:00
I have seen connection issues before in two cases:

the user has an entry in their host-file overriding the DNS lookup and therefor sending data to the wrong IP address

the user accesses the desired location BEFORE turning on the VPN. In that case, the local application usually caches the wrong IP address. Switching on the VPN afterwards does not fix this. In this case the local application needed a restart.

Especially the second one is hard to debug, since users usually do not tell they started using the application before starting the VPN.

If the response helped, do "Accept Answer" and up-vote it
GitaraniSharma-MSFT 50,096 Reputation points Microsoft Employee Moderator

2023-05-25T06:55:53.1666667+00:00
Hello @Mike Crowley ,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

This issue seems to be related to Windows and as it is happening only for a few users, it is difficult to troubleshoot this issue without looking at the actual setup/requests and collection of logs/traffic capture.

Hence, to troubleshoot the exact issue here, we will need a specialized 1:1 session, where a support engineer can have a screen share session to pinpoint the issue. So, if you have a support plan, I request you file a support ticket, else please do let us know, we will try and help you get a one-time free technical support.

In case you need help with a one-time free technical support, please send an email with subject line "ATTN gishar | Azure VPN Client not routing traffic from some P2S workstations" to AzCommunity[at]Microsoft[dot]com with the following details, I will follow-up with you.

Reference this Q&A thread

Your Azure Subscription ID

Azure VPN gateway name

Note: Do not share any PII data as a public comment.

We will post a summarized answer once the issue is resolved.

Regards, Gita
Mike Crowley 216 Reputation points

2023-05-25T19:58:47.5366667+00:00

@Bas Pruijn , thanks for your reply, however as I mentioned, the name resolves correctly, however the TCP connection will fail.

@GitaraniSharma-MSFT , thanks for your offer for a support case. The customer does not have a support agreement, so I'll email you for next steps.
Bas Pruijn 956 Reputation points

2023-05-26T13:10:23.2633333+00:00

@Mike Crowley I do understand the nslookup is succesful. I have seen this with other applications too. The application somehow caches the wrong (public) IP address of the service, while when I do a lookup of the domain name with the VPN switched on, the correct internal IP address is used. In my case this was especially when using a client connecting to SQL Server.

Since in your case it is concerning a connection to Azure Files, I can imagine the user is having a shortcut, mapped drive or something like this to the Azure Files location. If this defined connection is verified during startup of windows, the public IP address is cached and will not be refreshed easily.

I do not know if it is the same pool of users where this issue usually occurs. If that is the case, you could try to provide the desired internal IP address in the host file of the users. That would lead to the connection being forced on an internal IP address.

2 answers

Your answer

Bas Pruijn 956 Reputation points

2023-05-25T06:43:06.3066667+00:00

I have seen connection issues before in two cases:

the user has an entry in their host-file overriding the DNS lookup and therefor sending data to the wrong IP address

the user accesses the desired location BEFORE turning on the VPN. In that case, the local application usually caches the wrong IP address. Switching on the VPN afterwards does not fix this. In this case the local application needed a restart.

Especially the second one is hard to debug, since users usually do not tell they started using the application before starting the VPN.

If the response helped, do "Accept Answer" and up-vote it
GitaraniSharma-MSFT 50,096 Reputation points Microsoft Employee Moderator

2023-05-25T06:55:53.1666667+00:00

Hello @Mike Crowley ,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

This issue seems to be related to Windows and as it is happening only for a few users, it is difficult to troubleshoot this issue without looking at the actual setup/requests and collection of logs/traffic capture.

Hence, to troubleshoot the exact issue here, we will need a specialized 1:1 session, where a support engineer can have a screen share session to pinpoint the issue. So, if you have a support plan, I request you file a support ticket, else please do let us know, we will try and help you get a one-time free technical support.

In case you need help with a one-time free technical support, please send an email with subject line "ATTN gishar | Azure VPN Client not routing traffic from some P2S workstations" to AzCommunity[at]Microsoft[dot]com with the following details, I will follow-up with you.

Reference this Q&A thread

Your Azure Subscription ID

Azure VPN gateway name

Note: Do not share any PII data as a public comment.

We will post a summarized answer once the issue is resolved.

Regards, Gita
Mike Crowley 216 Reputation points

2023-05-25T19:58:47.5366667+00:00

@Bas Pruijn , thanks for your reply, however as I mentioned, the name resolves correctly, however the TCP connection will fail.

@GitaraniSharma-MSFT , thanks for your offer for a support case. The customer does not have a support agreement, so I'll email you for next steps.
Bas Pruijn 956 Reputation points

2023-05-26T13:10:23.2633333+00:00

@Mike Crowley I do understand the nslookup is succesful. I have seen this with other applications too. The application somehow caches the wrong (public) IP address of the service, while when I do a lookup of the domain name with the VPN switched on, the correct internal IP address is used. In my case this was especially when using a client connecting to SQL Server.

Since in your case it is concerning a connection to Azure Files, I can imagine the user is having a shortcut, mapped drive or something like this to the Azure Files location. If this defined connection is verified during startup of windows, the public IP address is cached and will not be refreshed easily.

I do not know if it is the same pool of users where this issue usually occurs. If that is the case, you could try to provide the desired internal IP address in the host file of the users. That would lead to the connection being forced on an internal IP address.

Answer 1

Mike Crowley 216

For the sake of simplicity, I am not involving applications or cache.

On a working computer, Test-NetConnection <IP Address> -Port 445 works and on a non-working computer, it doesn't. (no DNS in this example)

The layer4 traffic isn't being routed to the host.

I'm not using Azure Files, but likely it would be the same difference, if used with a private endpoint.

I now have a support case open and will return any insights to this thread.

Have a great weekend!

Answer 2

Mike Crowley 216

FWIW, the Azure guys transferred me to general windows support and that team didn't respond until 2 months later. By then, we had obviously found other solutions for the users, but unfortunately, we never nailed this down.

Share via

Azure VPN Client not routing traffic from some P2S workstations

2 answers

Your answer