Dictation Not Working on VPN? 10 Fixes for Work Networks

Short answer: Dictation usually fails on a VPN because the tunnel blocks, inspects, or slows the outbound connection your dictation app needs. Disconnect the VPN for thirty seconds and try again. If dictation works, ask IT to allowlist the app's domain or add it to your split tunneling rules.

You dictate all weekend without a hitch. Monday morning you connect to the work VPN, hold the same key, say the same sentence, and nothing arrives. No text, no useful error, just a cursor sitting exactly where you left it. Meanwhile your browser loads pages fine, your email syncs, and video calls run without complaint, so it does not feel like a network problem at all.

It usually is one. Dictation has a very different network profile from web browsing, and corporate tunnels are tuned for browsing. This guide works through the ten causes in the order they actually occur, from the thirty-second test that tells you where to look, to the specific request you can forward to your IT team when you need an exception.

Why a VPN Breaks Dictation When Everything Else Works

Loading a web page is a forgiving operation. The request is small, the response is cached in a dozen places, and if a packet goes missing the page still renders a second later. Cloud dictation is not forgiving in the same way. It opens an outbound connection to a specific host, uploads an audio payload, and waits for a response within a short window. Every part of that chain can be broken by a policy that leaves ordinary browsing untouched.

There are five distinct ways a tunnel interferes:

• Blocking. The firewall permits traffic to allowlisted domains and drops everything else, including a domain nobody has requested before.
• Redirecting. A proxy sits in the middle and expects every connection to be introduced properly. Apps that do not know about the proxy get refused.
• Inspecting. TLS inspection terminates the encrypted connection, examines it, and re-signs it with a corporate certificate. Anything strict about certificates fails.
• Resolving. Internal DNS servers answer for internal names and may not answer usefully for external ones, or may answer with a block page address.
• Slowing. The tunnel adds latency and drops packets. Nothing is blocked, but the upload does not finish before the request gives up.

Four of those five produce the same symptom on your screen: silence. That is why the triage order below matters more than any individual fix.

The Thirty-Second Test

Before changing a single setting, establish whether the VPN is genuinely responsible. Most people never do this, and half of them spend an afternoon reinstalling things over an unrelated problem.

1. Open any text field where dictation normally works. TextEdit, Notes, or a blank email is ideal.
2. With the VPN connected, dictate a short sentence. Note exactly what happens: nothing at all, an error, a long delay, or partial text.
3. Disconnect the VPN. Wait about ten seconds for the network interface to settle.
4. Dictate the same sentence again.
5. Reconnect the VPN and try once more, to make sure the result was not a coincidence.

If dictation works off the tunnel and fails on it, twice, the VPN is your culprit and the rest of this guide applies. If it fails in both states, the problem is somewhere else entirely, and our general Mac dictation troubleshooting guide is the better starting point. If it fails only in one particular app but works in TextEdit on the same connection, you are looking at an app-level issue rather than a network one, and dictation not working in third-party apps covers that pattern.

Fix 1: Check Whether the Domain Resolves Inside the Tunnel

DNS is the first thing a tunnel changes and the last thing anyone checks. When you connect, your Mac usually starts using the company's internal DNS servers so that internal hostnames work. Those servers may refuse external lookups, return a filtered result, or simply be slow.

Open Terminal with the VPN connected and run:

nslookup voicekeyboardpro.com

A healthy answer returns one or more IP addresses in a fraction of a second. Warning signs are a timeout, an NXDOMAIN response, or an address in a private range such as 10.x.x.x or 192.168.x.x, which usually means a filtering appliance is answering on the domain's behalf. To see which resolvers you are actually using at that moment:

scutil --dns | grep nameserver

If the domain does not resolve, no amount of microphone troubleshooting will help. This is the item to escalate, and it is usually a quick fix on the IT side because it is a category question rather than an individual exception.

Fix 2: Confirm the Connection Actually Completes

Resolution and reachability are different problems. A domain can resolve perfectly and still be unreachable because a firewall rule drops the traffic. Test the connection itself:

curl -I -m 10 https://voicekeyboardpro.com

You want an HTTP status line back within a second or two. The failure modes each tell you something specific:

• Connection timed out. A firewall is silently dropping the packets. This is Fix 4.
• Connection refused. Something is actively rejecting it, often a proxy that expects to be addressed directly. This is Fix 3.
• SSL certificate problem. TLS inspection is rewriting the connection. This is Fix 5.
• A 407 status. A proxy is demanding authentication. Also Fix 3.
• A response that takes eight seconds. Nothing is blocked, the link is just slow. Skip ahead to Fix 6.

Write down which one you get. It converts a vague "dictation is broken" ticket into a precise one, which is the difference between a same-day fix and a week of back and forth.

Fix 3: The Corporate Proxy Is Not Being Used

Many corporate networks route all external traffic through an explicit proxy, configured either in System Settings or by a PAC file pushed down by device management. Apps that read the system proxy settings work fine. Anything that opens a direct connection gets refused, because the firewall only trusts traffic that arrives from the proxy.

Check what your Mac has been told to use: System Settings → Network, select the active interface, click Details, then Proxies. If you see a PAC URL or a configured HTTP and HTTPS proxy, every external request on that machine is supposed to travel through it.

Two things go wrong here. The first is authentication. Proxies that require credentials will prompt a browser with a login page, but a background request has no way to display that prompt, so it simply fails. If your proxy re-prompts each morning, opening any external site in your browser first and completing the proxy login will often unblock everything else for the rest of the session. The second is scope: some PAC files send only browser-shaped traffic through the proxy and leave everything else to be dropped by the firewall. That one needs an IT change, not a local setting.

Fix 4: Ask for Split Tunneling or a Domain Allowlist

This is the fix that resolves the largest share of cases, and it is a two-minute change for whoever administers the VPN.

Split tunneling means the VPN carries traffic bound for internal systems and lets everything else go out over your normal internet connection. Most companies already run in split tunnel mode, with a list of destinations that either must or must not use the tunnel. Adding a domain to that list is routine.

The request has two possible forms, and it is worth offering both:

• Allowlist the domain so traffic through the tunnel is permitted rather than dropped. Preferred when policy requires everything to be inspected and logged.
• Bypass the domain so it never enters the tunnel at all. Preferred when the tunnel is congested or when inspection is the thing breaking the connection.

Either works. Which one your security team prefers depends on policy, so ask for the outcome rather than the mechanism: you need the application to reach its service from a managed machine.

Fix 5: TLS Inspection Is Rewriting the Connection

If curl gave you a certificate error, this is your answer. TLS inspection appliances decrypt outbound traffic, inspect it, then re-encrypt it with a certificate issued by an internal authority. Browsers accept this because the corporate root certificate is installed in the system trust store by device management. Applications that verify certificates strictly, or that pin to a known issuer, do not.

Verify the corporate root is actually present: open Keychain Access, choose the System keychain, select Certificates, and look for a root named after your employer or your security vendor. If it is missing on a machine that is meant to have it, the device management profile did not install correctly, which breaks far more than dictation and is worth reporting on its own.

Even with the root installed, some connections cannot survive interception. The practical resolution is an inspection bypass for the domain. Security teams maintain these lists already, typically for banking, healthcare, and productivity services, so adding one more entry follows an established process rather than creating a new exception.

Fix 6: The Tunnel Is Slow, Not Blocked

Sometimes nothing is blocked. The tunnel simply adds enough latency that the request does not complete in time. The signature is distinctive: dictation occasionally works, short phrases succeed while long ones fail, or text arrives after a delay long enough that you have already given up and started typing.

Measure it. With the VPN connected:

ping -c 10 voicekeyboardpro.com

Then disconnect and run it again. Compare the average round trip and, more importantly, the packet loss figure at the bottom. An extra 40 to 80 milliseconds is normal for a tunnel and harms nothing. Several hundred milliseconds, or any packet loss above roughly two percent, will make every network-dependent feature feel broken.

Common causes are a VPN concentrator in a distant region, an overloaded gateway at peak hours, or double-tunneling through a home VPN as well as the corporate one. Try a different VPN gateway if your client offers a choice, and disable any second tunnel. Our explainer on what actually determines speech-to-text latency covers which parts of the round trip you can influence and which you cannot.

Fix 7: Captive Portals and the Order of Operations

Hotel, airport, conference, and café networks intercept your first request and redirect it to a sign-in page. If your VPN connects before you complete that sign-in, you end up in a state where the tunnel reports connected but no real traffic passes.

The order matters. Join the Wi-Fi, open a browser, complete the portal sign-in, confirm an ordinary website loads, and only then connect the VPN. If your Mac is configured with always-on VPN you may need to temporarily disable it to reach the portal, which is Fix 8.

This is also the case people misdiagnose most often, because the failure follows them across networks and looks like the app is broken rather than the connection.

Fix 8: Always-On VPN and Managed Profiles

Managed Macs frequently carry a configuration profile that enforces an always-on tunnel, blocks traffic when the tunnel is down, or applies per-app rules that decide which applications may use the network at all. Under per-app VPN rules, an application that has not been explicitly included may find itself with no route out.

Look at System Settings → General → VPN & Device Management. Profiles installed by your employer are listed there, and you can inspect what each one contains. You will not be able to remove them on a managed machine, and you should not try. What you can do is name the specific profile in your ticket, which points IT directly at the policy that needs adjusting.

Fix 9: Rule Out the Things That Are Not the VPN

Before escalating, spend two minutes eliminating causes that merely coincide with your VPN use. Corporate laptops often receive several changes at once, and it is easy to blame the tunnel for a policy that arrived the same week.

• Microphone permission. System Settings → Privacy & Security → Microphone. A management policy can reset these.
• Accessibility permission. Same panel, Accessibility section. This is what allows text to be placed at your cursor system-wide, and it is a common casualty of a security agent update.
• Microphone contention. If a conferencing app is holding the microphone, dictation may capture nothing. Quit it fully rather than closing the window.
• Endpoint agents. Some security tools that ship alongside a VPN client inspect audio device access or block unrecognized applications outright. Worth naming in your ticket if one was installed recently.
• Shortcut conflicts. Remote desktop and virtualization tools capture keystrokes aggressively, so your dictation key may never reach the app.

Fix 10: iPhone on a Work VPN

The same causes apply on iOS with two additions specific to a third-party keyboard.

First, a keyboard needs Full Access enabled to use the network at all: Settings → General → Keyboard → Keyboards → Voice Keyboard Pro, then turn on Allow Full Access. Without it, no request leaves the device regardless of your VPN configuration, and the symptom is identical to a blocked connection.

Second, managed iPhones can enforce per-app VPN rules that route only approved apps through the tunnel and drop the rest. A keyboard extension is a distinct process from the app that hosts it, which occasionally means it is not covered by a rule written for the app itself. Mention that detail in your ticket. It is a small distinction that saves an IT team a lot of guessing.

What to Send Your IT Team

Vague tickets get slow answers. Specific ones get scheduled. Adapt this:

Subject: Allowlist request for dictation software on managed Macs. I use a dictation application that converts speech to text at the cursor. It works normally off the VPN and fails when connected. Testing shows [paste your curl result here]. Could you either allowlist voicekeyboardpro.com through the tunnel, or add it to the split tunnel bypass list, whichever fits policy? Happy to test whenever convenient. If you need an exact endpoint list for the request, the vendor can supply one at help@voicekeyboardpro.com.

Three things make this work. It reports a test rather than an impression, it offers two paths so the security team can pick the one that matches policy, and it does not ask anyone to disable a control. Fill in the bracket with the actual output from Fix 2 before sending.

If You Cannot Get an Exception

Some environments will not add exceptions, and that is a legitimate position rather than an obstacle to argue with. A few practical options remain.

Dictate on a personal device and move the text across. Clumsy, but it works for long-form writing where the time saved is real. Draft on your phone, where the connection is typically your carrier's rather than the corporate tunnel, and send the finished text to yourself.

Use the VPN selectively. If your client permits manual connect and disconnect, connect for the internal systems that need it and disconnect for stretches of writing. Check your acceptable use policy first, since some organizations require the tunnel to stay up.

Raise the privacy question directly, because it is often the real objection underneath the technical one. Voice Keyboard Pro stores only operational pings on the server. Transcript content is not retained, which is usually the specific assurance a security reviewer is looking for before approving anything that touches text people type at work. Point them at the privacy policy and let them evaluate it on the record rather than on assumption.

Working Through It in Order

Run the thirty-second test first. Then nslookup, then curl. Those three steps take under five minutes and they tell you which of the ten fixes applies, which beats trying all ten in sequence.

The encouraging part is that almost every case here ends in a configuration change rather than a dead end. Blocked domains get allowlisted, proxies get configured, inspection gets bypassed, slow gateways get swapped. The reason these tickets stall is that they usually arrive as "dictation doesn't work" with no evidence attached. Arrive with the test results and you turn an unfalsifiable complaint into a routine request.

Once the connection is clear, dictation on a work machine goes back to what it should be. Hold your key, say the sentence, release, and the words land in whatever you were already writing.