Many users of Mullvad VPN, a privacy-focused virtual private network, have reported difficulties with local network services—most notably with Apple’s AirPlay functionality. In particular, the encryption and strict routing provided by Mullvad VPN, while excellent for anonymity, tends to obstruct crucial mechanisms used for local device discovery. However, with a little networking knowledge and clever configuration involving Split-DNS and local DNS overrides, users have restored functionality and visibility to their local services without sacrificing online privacy.
TL;DR (Too Long, Didn’t Read)
When using Mullvad VPN, local network devices become hidden, breaking services like AirPlay and network printing. This happens because all traffic routes through the encrypted VPN tunnel, bypassing the local discovery protocols. By implementing a Split-DNS configuration and setting up a local DNS override, users can selectively resolve local device names while keeping the rest of their traffic private. This balances privacy with home network usability perfectly.
The Problem: Mullvad VPN and Local Network Isolation
Mullvad VPN is known for its strong stance on privacy and simplicity. However, in its effort to maximize anonymity, it applies tight controls over all network traffic, routing everything through a tunnel that excludes local subnet communication. This security-focused approach inadvertently isolates the device from other local devices like printers, smart TVs, speakers, or in this case—Apple’s AirPlay-enabled gadgets.
AirPlay, Apple’s media sharing technology, relies heavily on multicast DNS (mDNS, implemented as Bonjour) to discover and communicate with other Apple devices on the same LAN. When all communication is routed through Mullvad’s encrypted tunnel, this crucial discovery traffic either can’t be sent or isn’t received in a way that devices on the VPN can interpret.
As a result, users suddenly find their AirPlay speakers “missing,” printers “offline,” or HomeKit devices “unreachable.” For Apple-centric households, that’s a major downgrade in smart home functionality.
Understanding Why It Happens
To understand the problem thoroughly, it’s important to consider how VPNs normally function:
- VPNs encrypt all outgoing traffic from the device.
- This traffic is sent through a secure tunnel to the VPN server.
- Local network routes (e.g., 192.168.x.x or 10.0.x.x) are not used unless specifically allowed.
In the case of Mullvad, the VPN client takes a “privacy-first” approach by disabling LAN access unless explicitly configured otherwise. So, any UDP broadcast traffic, including mDNS used for AirPlay, never reaches other local devices. Similarly, responses from those devices never make it back, since the encrypted tunnel filters them out.
Fixing the Issue with Split-DNS and Local DNS Override
Once the core problem is identified—traffic meant for the LAN is being improperly routed or blocked—the fix involves a smart reinterpretation of DNS and routing. The two key techniques are:
- Split-DNS: Allows certain domain queries (usually local ones) to resolve through a local DNS server or a manually assigned IP.
- Local DNS Override: Overrides DNS entries where needed, ensuring the operating system looks locally instead of querying external servers through the VPN.
This essentially tells your system, “For everything else, use the VPN. But if I’m trying to find kitchen-speaker.local, look at this address on the LAN.”
Step-by-Step Implementation
Here’s how many users have made it work on platforms like macOS or Linux:
- Retain LAN Access: Configure the Mullvad VPN client to allow access to LAN interfaces. Mullvad has a “Allow LAN” setting that must be enabled. This ensures traffic to local IPs is not blocked.
- Install a local resolver: Use software like dnsmasq or configure systemd-resolved to provide responses for your local network domain queries.
- Update the resolver configuration: Point specific domains like .local or hostnames like apple-tv-1 to a specific LAN IP range or DNS server—one that has visibility into your home network’s devices.
- Configure Split-DNS: On macOS, use tools like scutil or NetworkPreferences.plist to force queries for .local and select internal suffixes to be handled outside the VPN.
- Test Visibility: Use the ping or dns-sd -B _airplay._tcp command to verify local devices appear again with proper names and IPs.
Once configured, local devices become discoverable again, and AirPlay returns to normal operation.
AirPlay and mDNS Nuances
AirPlay, like many Apple services, piggybacks on Bonjour for local visibility. mDNS operates over UDP port 5353 and uses multicast to announce and discover services. Since multicast doesn’t work well across VPN interfaces unless explicitly bridged, it must stay on the LAN segment.
That’s why allowing LAN communication and ensuring local DNS lookups function correctly is critical. These changes restore Apple services without compromising privacy for external traffic.
Potential Side Effects and Considerations
Although this fix is efficient, users should consider a few potential side effects:
- Configuring Split-DNS may expose local traffic if not done correctly, so avoid exposing local service information via external interfaces.
- The fix requires intermediate knowledge of how DNS and VPN routing works; improper setups can lead to DNS leaks or inconsistent behavior.
- System updates to VPN apps or operating systems may override custom DNS settings, so periodic checks are advised.
Still, for power users who want both robust privacy and full home network functionality, this approach offers a manageable and flexible option.
Conclusion
Mullvad VPN’s unflinching commitment to privacy comes at a cost: the breaking of local network discovery. For Apple users who rely on AirPlay and Bonjour, this creates real-world inconveniences. However, by leveraging Split-DNS and carefully overriding local DNS behavior, users can restore full local functionality while continuing to benefit from encrypted VPN protection.
It’s another example of how modern internet usage often involves a balance between security, convenience, and control—but for those who value all three, smart configuration once again comes to the rescue.
FAQ: Mullvad VPN and Local Network Discovery
-
Q: Why does Mullvad VPN break AirPlay and similar services?
A: Mullvad VPN, by default, routes all traffic through its encrypted tunnel and blocks LAN access. Since AirPlay relies on local multicast discovery protocols (like mDNS), these get blocked or rerouted incorrectly. -
Q: What is Split-DNS, and how does it help?
A: Split-DNS lets different queries resolve through different DNS servers or rules. You can use it to ensure local devices are looked up on your home network, while everything else is routed through the VPN. -
Q: Can I enable LAN access without compromising security?
A: Yes. As long as you only allow specific local IP ranges and monitor DNS leaks, enabling LAN access is relatively safe and often necessary for AirPlay and smart home devices. -
Q: Does this setup also work on Windows?
A: Yes, but configuration steps are different. Windows users can apply routing exceptions and use tools like Acrylic DNS Proxy to simulate some aspects of this behavior. -
Q: Will this break if Mullvad updates its app?
A: Possibly. VPN apps sometimes reset configurations. If that happens, you’ll need to reapply your custom DNS or routing rules.