Azure VPN Client MacOS communication between peers

Samuel Turcotte 30 Reputation points
2023-02-01T20:33:54.2833333+00:00

Hi all,

Azure VPN Gateway configured and working. Point-to-Side OVPN with Azure AD Authentication.

Client connecting with Azure VPN Client.

Here is my problem :

On Windows, everything works fine, I can ping every one on the vpn subnet. MacOS clients can only communicate with servers on azure. All routes are present, both windows and macos clients uses the same configuration file. Tested the OVPN configuration on Mac with an other VPN client (viscosity) and it's working.

Does anyone knows if there is some limitation on the Azure VPN client on Macos ?

Does the Macos client exclude VPN lan subnet by default ?

Azure VPN Gateway
Azure VPN Gateway
An Azure service that enables the connection of on-premises networks to Azure through site-to-site virtual private networks.
1,380 questions

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Samuel Turcotte 30 Reputation points
    2023-02-03T15:47:02.9266667+00:00

    Hi @ChaitanyaNaykodi-MSFT

    Thank you for your answer. I've done some tests with the clientconfig tag. There is no duplicate in the xml.

    On MacOS, the connexion log says :

     INFO com.microsoft.AzureVpnMac.packetTunnelProvider TID=83340 PacketTunnelProviderConnection.swift: 597 (configureSplitTunnel(clientConfig:settings:profileName:)) Excluding IPv4 routes: address: 10.232.148.0, mask: 255.255.255.0

    There is no excluderoute in the configuration. The same XML configuration file is used for MacOS and Windows.

    Any clues?

    0 comments
  2. ChaitanyaNaykodi-MSFT 22,776 Reputation points Microsoft Employee
    2023-02-20T01:49:31.6466667+00:00

    @Samuel Turcotte

    Thank you for your response and adding details regarding the connection log. Using this information, I was able to take a deeper into similar issues internally and I found that this is actually a limitation by design for Azure VPN Client for Mac OS. Transit between two clients is actually not a supported behavior. I understand this is currently not documented and I will work with the team to add this to the documentation.

    In order to resolve this issue can you perform a traceroute for any peer in the VPN LAN subnet? and check which route it takes.

    The issue I referred to internally, the route for VPN LAN subnet was added to the physical ethernet interface and also to the Virtual tunnel interface. The issue was mitigated for them when the route for VPN LAN subnet was removed from physical ethernet interface's route table and as the communication should take place via the tunnel interface. Please let me know if this helps in resolving the issue. Thank you!

    0 comments