Azure VPN Client on Mac: Put DNS Servers in the Profile

Three different questions get answered with the same shrug on macOS. Which client is this? Where do its DNS servers come from? And after the setting is in place, why does a short name still fail? They have separate answers, and only the first one is about the profile file. Getting the order right turns a vague DNS problem into one verifiable step at a time.

Confirm which client you are configuring

This is Microsoft's Azure VPN Client using OpenVPN for point-to-site access. Its XML is not a native macOS IKEv2 profile, and it is not a configuration file for every third-party OpenVPN client either.

If the Mac connects through the built-in system dialog, you are in the wrong document.

DNS lives inside the profile XML

Download the current profile for the intended gateway and authentication method, then keep an unmodified copy before touching anything. Edit the working copy only, and do not paste its authentication material into a support ticket.

The optional settings guide puts the DNS entries inside a clientconfig element. A minimal fragment looks like this, with an address your organization actually runs.

<clientconfig>
    <dnsservers>
        <dnsserver>10.20.2.4</dnsserver>
    </dnsservers>
</clientconfig>

That address is illustrative, not an Azure-provided resolver. Integrate the entries into the existing configuration rather than pasting a second clientconfig element, because Microsoft states that duplicate elements are unsupported on macOS. Generated profiles may also carry a nil placeholder where the real configuration belongs, and appending settings next to a nil element is not a repair.

Import is the change

Saving the file changes nothing on its own. Open Azure VPN Client, choose Import, select the revised XML, complete any required fields and save the connection.

Then reconnect through that imported connection. A profile sitting on disk while an older connection stays active is the most common reason a correct edit appears to do nothing.

The suffix limitation decides your first test

As documented on 30 October 2026, additional DNS suffix values in this configuration do not persist correctly on macOS. Copying a Windows suffix example and promising identical behaviour is how a working resolver gets reported as broken. Enter the suffixes, save, reconnect, and check whether they survived the reconnect. If they did not, plan around fully qualified names instead of fighting the client.

Test with a fully qualified private hostname first. If the FQDN resolves and the short name does not, you have learned something specific: the resolver is reachable and short-name expansion is missing. That is a different defect from an unreachable DNS server, and it needs a different owner.

The resolver still needs a path

Listing an address in XML does not create a DNS service. The address has to run an authorized resolver that can answer or forward the private namespace, and the Mac has to be permitted to reach it through the tunnel. If that resolver sits behind a firewall rule that does not know the tunnel range, queries time out with no useful error. The timeout then looks exactly like a wrong address, and people re-edit the XML for an hour.

Inspect the connected Mac's active resolver state, then query that server directly to isolate its answer from the application's choice of resolver. A direct query proves the server works. It does not prove ordinary lookups select it.

Hand off three separate results

Keep these apart in the handoff: the revised profile was imported, the intended resolver answered the requested name, and the application reached the returned address. Each has a different owner and a different fix.

One line per result is enough, and it stops the next person from re-editing a profile that was already correct.