VPN Connection Failed Due to Unsuccessful Domain Name Resolution Fix

“The VPN connection failed due to unsuccessful domain name resolution” means your VPN client could not look up the IP address of the VPN server you typed in, so it never got as far as logging you in. In almost every case the fix is on your side: correct the server address, clear the client’s saved profile files, or sort out the DNS on the network you are using.

The message comes from Cisco AnyConnect (now called Cisco Secure Client in newer versions), which is what most universities and many employers use. The steps below are drawn from university IT knowledge bases, a Boston University incident report and Cisco Community threads. Paths and menu names can shift between client versions, so treat them as accurate as of October 2026 and check your organization’s own help pages too.

What the error actually means

When you click Connect, the client takes the server name, for example vpn.yourschool.edu, and asks a DNS server for its IP address. If that lookup fails or returns something useless, you get this error.

That gives you three places to look:

• The name itself. A typo, an old nickname or a stale entry saved in the client.
• The client’s saved files. AnyConnect keeps XML profile and preference files that can disagree with each other.
• The DNS server you are using. Your router, ISP or a public resolver may be failing or answering incorrectly.

Fix 1: Check the server address in the client

This is the quickest fix and it is surprisingly common.

1. Open Cisco AnyConnect or Cisco Secure Client.
2. Look at the text in the connection box.
3. If it shows a short label rather than a full address, delete it and type the hostname your IT department publishes.

Bucknell’s IT knowledge base describes exactly this: if the box shows the old “Bucknell_VPN” entry, replace it with vpn.bucknell.edu. Your organization’s hostname will be different, so get it from their official help page rather than guessing.

Fix 2: Clear the AnyConnect XML profile files (Windows)

If the address is right and it still fails, the client’s saved files may be out of sync. UConn’s troubleshooting guide says the error occurs when there is a mismatch between addresses in the XML files AnyConnect references, and that deleting them fixes it because the client re-creates them automatically.

Write down your VPN server address first. Then:

1. Quit AnyConnect completely, including the icon in the taskbar’s hidden-icons area, so it is not running in the background.
2. Open File Explorer and paste C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\ into the address bar. ProgramData is hidden by default, so pasting the path is easiest.
3. Delete the file named preferences_global.xml.
4. Open the Profile subfolder and delete the files ending in .xml.
5. Go to C:\Users\<your Windows username>\AppData\Local\Cisco\Cisco AnyConnect Secure Mobility Client\ and delete preferences.xml.
6. Restart the client, type the server address again and connect.

On newer Cisco Secure Client versions the folder may be named differently, so look for the Cisco folder under ProgramData if the exact path is missing.

A Cisco Community thread from an administrator backs this up. After upgrading AnyConnect, their users hit this error, and deleting the user’s Preferences.xml made it go away. In their case a Group Policy was overwriting the profile XML, which suggests the old preferences file conflicted with the new profile.

On a work or school device managed by IT, check with them before deleting these files. Profiles are often pushed centrally, and IT may prefer to fix the source.

Fix 3: Rule out your network’s DNS

If the error appears only on one network, the client is probably fine and your DNS is the problem.

In July 2020, Boston University’s IT status page reported that some users could not connect to the Cisco VPN and saw this exact message. The cause was a Verizon Fios DNS server, not BU’s VPN, and the incident was resolved the same day. In another Cisco Community thread, an admin said affected users could connect after power-cycling their modems, at least for a while, and that flushing DNS and removing static DNS settings did not fully solve it for everyone.

Work through these:

1. Try another network. Connect your laptop to a phone hotspot and try the VPN. If it works there, the issue is your home or office network.
2. Restart your modem and router. Unplug them, wait, and power them back on.
3. Flush your DNS cache on Windows. Open Command Prompt and run ipconfig /flushdns. Microsoft’s documentation says this clears the DNS client resolver cache, including cached failed lookups. It does not remove entries in your Hosts file. Microsoft’s own older pages disagree on whether admin rights are needed, so use an administrator Command Prompt if a normal one refuses.
4. Review custom DNS settings. If you or a utility set a custom DNS server on your network adapter or router, try switching back to automatic and test again. Some troubleshooting blogs say the error shows up more with custom public DNS, but we did not find Cisco confirming that, so treat it as something to test rather than a known rule.
5. Public Wi-Fi. On hotel or café networks, open a browser and finish any sign-in page before starting the VPN.

Fix 4: Reinstall the client

When nothing else works, a clean reinstall is the standard last step. The University of South Dakota’s help page for this error recommends uninstalling and then reinstalling Cisco AnyConnect.

1. Uninstall Cisco AnyConnect or Cisco Secure Client from Windows Settings, Apps.
2. Restart the computer.
3. Download the installer only from your university’s or employer’s official VPN page, not from a third-party download site. Cisco distributes the client through organizations, and IT pages usually link the version that matches their server.
4. Install, enter the server address and connect.

Notes for IT admins

The community threads point to a few server-side and deployment checks worth making when many users report the error at once:

• Profile delivery. If a GPO or script replaces the profile XML, stale per-user Preferences.xml files can clash with it. One admin’s only reliable fix was deleting that file remotely and restarting.
• HostAddress in the profile. A reply in the 2020 Cisco Community thread suggested checking whether the profile’s HostAddress uses a fully qualified domain name, and considering the front-end IP or pushed hosts entries as a workaround.
• Upstream DNS outages. As BU’s case shows, an ISP’s resolver can cause a burst of reports that has nothing to do with your gateway. Ask affected users which ISP they use before changing the VPN.

None of these come from official Cisco documentation; they are reports from administrators, so test them before rolling changes out widely.

When to contact your IT help desk

If the address is correct, the XML files have been cleared, the VPN fails on every network you try, and a reinstall did not help, hand it over to your IT team. Tell them the exact error text, your operating system, the client version and which networks you tested. They can see whether their VPN hostname or DNS records changed, which you cannot fix from your side.