Reports

The issue you're experiencing, where the internet stops working after connecting to the Azure VPN Client, is likely due to the VPN configuration routing all traffic through the VPN tunnel by default, which can disrupt access to the public internet. Your configuration already includes excluderoutes to keep public internet traffic off the VPN tunnel, but it seems the settings might not be fully effective, or additional configuration is needed to ensure split tunneling works correctly.Here’s a step-by-step analysis and solution to rectify the issue:1. Understand the Current ConfigurationYour configuration includes:

Exclude Routes:
- 0.0.0.0/1 and 128.0.0.0/1 are used to exclude public internet traffic from the VPN tunnel. These two routes together cover the entire IPv4 address space (0.0.0.0/0), which is a common way to implement split tunneling, ensuring non-VNet traffic bypasses the VPN.
Include Routes:
- 10.0.0.0/16 routes traffic destined for your Azure Virtual Network (VNet) through the VPN tunnel.
Protocol: Uses UDP for the SSL transport protocol, which is generally fine but could be revisited if connectivity issues persist.

Despite these settings, the internet is being blocked, which suggests that either:

The Azure VPN Client is not honoring the excluderoutes correctly.
The Azure Gateway is configured to override client-side routing and force all traffic through the VPN (full tunneling).
There may be a misconfiguration in the Azure VPN Gateway or client settings.

2. Steps to Rectify the Issuea. Verify Split Tunneling in Azure VPN GatewayThe Azure VPN Gateway may be configured to route all traffic (including internet traffic) through the VPN tunnel, overriding the client-side excluderoutes. To ensure split tunneling is enabled on the Azure side:

Check the Point-to-Site Configuration in Azure:
- Go to the Azure Portal > Navigate to your Virtual Network Gateway > Point-to-site configuration.
- Ensure that the Address Pool only includes the VNet address range (e.g., 10.0.0.0/16) and does not include 0.0.0.0/0 (which would route all traffic through the VPN).
- If 0.0.0.0/0 is present in the address pool, remove it to enable split tunneling.
Download a Fresh VPN Profile:
- After confirming or updating the Point-to-Site configuration, download a new VPN profile from the Azure Portal and compare it with your current configuration.
- Update your XML file with any new settings from the downloaded profile, ensuring the fqdn, servervalidation, and certificate details match.

b. Adjust the Client ConfigurationYour current excluderoutes configuration (0.0.0.0/1 and 128.0.0.0/1) is correct for split tunneling, as it covers the entire public internet address space while allowing 10.0.0.0/16 to go through the VPN. However, you can make the configuration more explicit or troubleshoot further:

Ensure Correct Syntax: Verify that the XML syntax is correct and that the Azure VPN Client is parsing it properly. Your configuration looks well-formed, but ensure there are no extra spaces, line breaks, or encoding issues in the file.
Try a Single Exclude Route: Some VPN clients may not handle split 0.0.0.0/1 and 128.0.0.0/1 correctly. As a test, try replacing the two exclude routes with a single 0.0.0.0/0 exclude route to explicitly bypass all non-VNet traffic:

xml
```
<excluderoutes>
  <route>
    <destination>0.0.0.0</destination><mask>0</mask>
  </route>
</excluderoutes>
```
Then, test the connection. Note that this approach may require Azure Gateway support for split tunneling (as described above).

c. Check DNS SettingsIf the internet is inaccessible, it could be due to DNS resolution issues rather than routing. When connected to the VPN, the client might be using the Azure VNet’s DNS servers, which may not resolve public internet domains correctly.

Specify Public DNS Servers: In the Azure VPN Client, manually configure public DNS servers (e.g., Google’s 8.8.8.8 and 8.8.4.4 or Cloudflare’s 1.1.1.1) for the VPN connection:
1. Open the Azure VPN Client.
2. Go to the imported profile settings.
3. Add custom DNS servers under the network settings for the VPN connection.
Azure Gateway DNS: In the Azure Portal, ensure the Point-to-Site configuration includes appropriate DNS servers. If your VNet has custom DNS servers, verify they can resolve public internet domains, or add public DNS servers to the configuration.

d. Test with TCP Instead of UDPYour configuration uses UDP (<transportprotocol>udp</transportprotocol>), which is generally faster but can be less reliable in some network environments due to NAT or firewall issues. If the internet issue persists, try switching to TCP:

xml

<transportprotocol>tcp</transportprotocol>

After making this change, reconnect and test internet access.e. Verify Azure VPN Client VersionEnsure you’re using the latest version of the Azure VPN Client, as older versions may have bugs or compatibility issues with split tunneling:

Check for updates in the Microsoft Store (for Windows) or the respective app store for your platform.
Re-import the updated VPN profile after updating the client.

f. Check Local Firewall or Network SettingsYour local machine’s firewall or network settings might block internet access when the VPN is active:

Windows Firewall:
- Ensure the Azure VPN Client and related processes (e.g., OpenVPN components) are allowed through the firewall.
- Temporarily disable the firewall to test if it’s the cause.
Antivirus/Endpoint Protection:
- Some antivirus software may interfere with VPN routing. Temporarily disable any third-party security software to test.
Network Adapters:
- Check the routing table on your machine while connected to the VPN:
  - On Windows, run route print in Command Prompt.
  - Ensure there’s a default route (0.0.0.0/0) pointing to your local gateway (not the VPN tunnel) for non-VNet traffic.
  - If the VPN is overriding the default route, the excluderoutes may not be applied correctly.

g. Test ConnectivityAfter making changes:

Re-import the modified VPN profile into the Azure VPN Client.
Connect to the VPN.
Test internet access by visiting a public website (e.g., google.com).
Verify VNet access by pinging or connecting to a resource in the 10.0.0.0/16 range.
If the issue persists, check the Azure VPN Client logs (available in the client’s diagnostic section) for errors related to routing or DNS.

3. Sample Adjusted ConfigurationHere’s a modified version of your configuration with a single excluderoutes entry and DNS settings (if supported by the client):

xml

<?xml version="1.0" encoding="utf-8"?>
<AzVpnProfile>
  <clientconfig>
    <!-- Keep public internet OFF the VPN tunnel -->
    <excluderoutes>
      <route>
        <destination>0.0.0.0</destination><mask>0</mask>
      </route>
    </excluderoutes>
    <!-- Send only your VNet over the tunnel -->
    <includeroutes>
      <route>
        <destination>10.0.0.0</destination><mask>16</mask>
      </route>
    </includeroutes>
    <!-- Optional: Specify public DNS servers -->
    <dnsservers>
      <dns>8.8.8.8</dns>
      <dns>8.8.4.4</dns>
    </dnsservers>
  </clientconfig>

  <name>Geovert-VM-vnet</name>
  <protocolconfig>
    <sslprotocolConfig>
      <transportprotocol>tcp</transportprotocol> <!-- Switched to TCP for testing -->
    </sslprotocolConfig>
  </protocolconfig>

  <serverlist>
    <ServerEntry>
      <displayname i:nil="true" />
      <fqdn>azuregateway-0ad30063-afcb-4d23-9960-b3fc2f4b4b06-ae638e987919.vpn.azure.com</fqdn>
    </ServerEntry>
  </serverlist>

  <servervalidation>
    <Cert>
      <hash>DF3C24F9BFD666761B268073FE06D1CC8D4F82A4</hash>
      <issuer i:nil="true" />
    </Cert>
    <serversecret></serversecret>
    <type>cert</type>
  </servervalidation>

  <version>1</version>
</AzVpnProfile>

Note: The <dnsservers> section may not be supported in all Azure VPN Client versions. If it causes an error, remove it and configure DNS manually in the client or Azure Gateway settings.4. If the Issue PersistsIf none of the above resolves the issue:

Contact Azure Support: Provide them with your VPN profile, Azure Gateway configuration details, and logs from the Azure VPN Client. They can verify if the gateway is enforcing full tunneling or if there’s a client-side issue.
Alternative Client: If the Azure VPN Client continues to misbehave, consider using the native Windows OpenVPN client with the downloaded OpenVPN profile from the Azure Portal, as it may offer more control over routing.
Check for Conflicting VPNs: Ensure no other VPN clients or profiles are active, as they may interfere with routing.

5. Additional Notes

Azure Documentation: Refer to the Azure Point-to-Site VPN documentation for guidance on split tunneling and DNS configuration.
Testing Tools: Use tracert (Windows) or traceroute (macOS/Linux) to see where internet traffic is being routed when the VPN is active.
Backup Your Profile: Before making changes, save a copy of your original VPN profile to avoid losing access to the VNet.

If you need further assistance with specific steps (e.g., checking the Azure Portal, interpreting logs, or testing routes), please let me know, and I can provide more detailed instructions or analyze any additional details you share (e.g., logs or Azure Gateway settings).

79740641