[GH-ISSUE #2143] Connectivity Issues with Active Mullvad VPN on a Netbird Peer #4407

Open
opened 2026-08-05 00:57:34 -04:00 by saavagebueno · 7 comments
Owner

Originally created by @RoguePwner on GitHub (Jun 17, 2024).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/2143

Issue Description:

Overview:

I am facing connectivity issues in my self-hosted Netbird setup when Mullvad VPN is active on a peer. This setup, inspired by Tailscale + Mullvad VPN integrations for enhanced privacy, fails to maintain peer accessibility and network functionality with the VPN activated.

Detailed Description:

Setup:

  • Self-hosted Netbird on a VPS running Ubuntu 22.04.
  • Domain secure.connect.domain.com set with an A record pointing to the VPS IP.
  • Installation followed the Quickstart guide, with necessary ports opened on UFW (noting Docker's UFW bypass).
  • Netbird clients on:
    • Ubuntu VPS
    • Docker on the same Ubuntu VPS
    • MacOS host running Sonoma 14.3.1
  • All clients appear connected and healthy in the dashboard.

Observations:

  • The Ubuntu VPS client can communicate with the Docker client.
  • The MacOS client, when connected to Mullvad VPN (both Wireguard and OpenVPN protocols tried), loses connectivity to other clients.
  • Disabling Mullvad VPN restores connectivity.
  • Adjusting DNS to use Quad9 did not solve connectivity issues under VPN use.

DNS Monitoring and Fixes:

  • Originally, DNS resolution failed on MacOS with Mullvad VPN active, showing Nameserver I/O timeout errors.
  • By monitoring DNS settings in MacOS system preferences, I noted default ISP DNS settings switch to Mullvad's DNS when the VPN is active.
  • Forcing Mullvad VPN to use custom DNS servers (Quad9) corrected the I/O timeout errors and showed correct DNS in system settings.
  • Despite these adjustments, hostname resolution and peer connectivity were not restored while Mullvad VPN was active.

Current Issue:
Even after addressing DNS I/O errors and ensuring DNS settings are correctly pointed to Quad9, the MacOS client cannot resolve hostnames or connect to peers when Mullvad VPN is turned on.

Expected Behavior:

Activating Mullvad VPN should not disrupt the Netbird network. Peers should remain accessible, and DNS resolution should work as configured, without needing to deactivate the VPN.

Actual Behavior:

With Mullvad VPN active, the affected peer becomes isolated; unable to communicate with other peers or resolve hostnames, despite DNS configurations appearing correct.

Steps to Reproduce:

  1. Setup a Netbird instance on a VPS with Ubuntu 22.04.
  2. Configure Netbird clients on Ubuntu, Docker, and MacOS.
  3. Activate Mullvad VPN on the MacOS client.
  4. Attempt to access or resolve hostnames from other peers.

Additional Information:

Addressing this issue is crucial for ensuring that privacy-focused setups using Mullvad VPN can operate seamlessly with Netbird, allowing for secure and private network configurations without compromising connectivity.

Originally created by @RoguePwner on GitHub (Jun 17, 2024). Original GitHub issue: https://github.com/netbirdio/netbird/issues/2143 ### Issue Description: #### Overview: I am facing connectivity issues in my self-hosted Netbird setup when Mullvad VPN is active on a peer. This setup, inspired by Tailscale + Mullvad VPN integrations for enhanced privacy, fails to maintain peer accessibility and network functionality with the VPN activated. #### Detailed Description: **Setup:** - Self-hosted Netbird on a VPS running Ubuntu 22.04. - Domain `secure.connect.domain.com` set with an A record pointing to the VPS IP. - Installation followed the Quickstart guide, with necessary ports opened on UFW (noting Docker's UFW bypass). - Netbird clients on: - Ubuntu VPS - Docker on the same Ubuntu VPS - MacOS host running Sonoma 14.3.1 - All clients appear connected and healthy in the dashboard. **Observations:** - The Ubuntu VPS client can communicate with the Docker client. - The MacOS client, when connected to Mullvad VPN (both Wireguard and OpenVPN protocols tried), loses connectivity to other clients. - Disabling Mullvad VPN restores connectivity. - Adjusting DNS to use Quad9 did not solve connectivity issues under VPN use. **DNS Monitoring and Fixes:** - Originally, DNS resolution failed on MacOS with Mullvad VPN active, showing Nameserver I/O timeout errors. - By monitoring DNS settings in MacOS system preferences, I noted default ISP DNS settings switch to Mullvad's DNS when the VPN is active. - Forcing Mullvad VPN to use custom DNS servers (Quad9) corrected the I/O timeout errors and showed correct DNS in system settings. - Despite these adjustments, hostname resolution and peer connectivity were not restored while Mullvad VPN was active. **Current Issue:** Even after addressing DNS I/O errors and ensuring DNS settings are correctly pointed to Quad9, the MacOS client cannot resolve hostnames or connect to peers when Mullvad VPN is turned on. ### Expected Behavior: Activating Mullvad VPN should not disrupt the Netbird network. Peers should remain accessible, and DNS resolution should work as configured, without needing to deactivate the VPN. ### Actual Behavior: With Mullvad VPN active, the affected peer becomes isolated; unable to communicate with other peers or resolve hostnames, despite DNS configurations appearing correct. ### Steps to Reproduce: 1. Setup a Netbird instance on a VPS with Ubuntu 22.04. 2. Configure Netbird clients on Ubuntu, Docker, and MacOS. 3. Activate Mullvad VPN on the MacOS client. 4. Attempt to access or resolve hostnames from other peers. ### Additional Information: Addressing this issue is crucial for ensuring that privacy-focused setups using Mullvad VPN can operate seamlessly with Netbird, allowing for secure and private network configurations without compromising connectivity.
saavagebueno added the clientcompatibility labels 2026-08-05 00:57:34 -04:00
Author
Owner

@RoguePwner commented on GitHub (Jun 18, 2024):

I wanted to update that this issue isn't only occurring on the MacOS client when running Mullvad VPN, but also affects Docker setups. I tested this using the Gluetun VPN Client container, specifically configured for Mullvad with Wireguard on port 60000. Here's a quick rundown of the setup I used:

  1. Gluetun Container Setup:

    sudo docker run --rm -it --cap-add=NET_ADMIN --name gluetun \
    -e VPN_SERVICE_PROVIDER=mullvad \
    -e VPN_TYPE=wireguard \
    -e WIREGUARD_PRIVATE_KEY=wOEI9rqqbDwnN8/Bpp22sVz48T71vJ4fYmFWujulwUU= \
    -e WIREGUARD_ADDRESSES="10.64.222.21/32" \
    -e SERVER_HOSTNAMES="nl-ams-wg-002" \
    -e OWNED_ONLY=yes \
    -e VPN_ENDPOINT_PORT=60000 \
    -e DOT_PROVIDERS=quad9 \
    -e BLOCK_MALICIOUS=off \
    qmcgaw/gluetun
    
  2. Netbird Client Container Setup Using Gluetun Network:

    sudo docker run --rm -d --cap-add=NET_ADMIN --name netbird-client \
    --network="container:gluetun" \
    -v netbird-client:/etc/netbird \
    -e NB_SETUP_KEY=SETUP_KEY \
    -e NB_MANAGEMENT_URL=MANAGEMENT_URL \
    netbirdio/netbird:latest
    

The peer connects successfully to the dashboard, but no communication is possible unless Mullvad VPN is deactivated. This seems to confirm that the problem isn’t isolated to a specific client setup but might be inherent to how VPN networking interferes with Netbird’s operation.

Hopefully, this additional detail can help in diagnosing and resolving the issue.

Thank you!

<!-- gh-comment-id:2176669430 --> @RoguePwner commented on GitHub (Jun 18, 2024): I wanted to update that this issue isn't only occurring on the MacOS client when running Mullvad VPN, but also affects Docker setups. I tested this using the [Gluetun VPN Client](https://github.com/qdm12/gluetun) container, specifically configured for Mullvad with Wireguard on port 60000. Here's a quick rundown of the setup I used: 1. **Gluetun Container Setup:** ```bash sudo docker run --rm -it --cap-add=NET_ADMIN --name gluetun \ -e VPN_SERVICE_PROVIDER=mullvad \ -e VPN_TYPE=wireguard \ -e WIREGUARD_PRIVATE_KEY=wOEI9rqqbDwnN8/Bpp22sVz48T71vJ4fYmFWujulwUU= \ -e WIREGUARD_ADDRESSES="10.64.222.21/32" \ -e SERVER_HOSTNAMES="nl-ams-wg-002" \ -e OWNED_ONLY=yes \ -e VPN_ENDPOINT_PORT=60000 \ -e DOT_PROVIDERS=quad9 \ -e BLOCK_MALICIOUS=off \ qmcgaw/gluetun ``` 2. **Netbird Client Container Setup Using Gluetun Network:** ```bash sudo docker run --rm -d --cap-add=NET_ADMIN --name netbird-client \ --network="container:gluetun" \ -v netbird-client:/etc/netbird \ -e NB_SETUP_KEY=SETUP_KEY \ -e NB_MANAGEMENT_URL=MANAGEMENT_URL \ netbirdio/netbird:latest ``` The peer connects successfully to the dashboard, but no communication is possible unless Mullvad VPN is deactivated. This seems to confirm that the problem isn’t isolated to a specific client setup but might be inherent to how VPN networking interferes with Netbird’s operation. Hopefully, this additional detail can help in diagnosing and resolving the issue. Thank you!
Author
Owner

@nazarewk commented on GitHub (Apr 23, 2025):

@WiredBytes were you able to figure out the issue or is it still a problem?

Generally, compatibility with other VPN solutions (especially commercial services acting as Exit Nodes in the primary mode of operation) is out of scope for NetBird or most other VPN solutions.

<!-- gh-comment-id:2824754291 --> @nazarewk commented on GitHub (Apr 23, 2025): @WiredBytes were you able to figure out the issue or is it still a problem? Generally, compatibility with other VPN solutions (especially commercial services acting as Exit Nodes in the primary mode of operation) is out of scope for NetBird or most other VPN solutions.
Author
Owner

@unleashit commented on GitHub (Apr 29, 2026):

Having the same issue and this has been a show stopper for me in making regular use of any mesh network. It would be really nice if a project could pick a few of the top privacy solutions (maybe Mullvad, Proton VPN and Windscribe) and modify the right iptables/firewall changes to make it work. For the user to try to manage it on each client is hard to impossible. I've tried the solution of manually adding a wireguard interface to a router exit node. While it works, it's not a modern solution (no Daita, multi-hop, obfuscation, no ability to switch slow/offline endpoints, etc). But there's another part of the problem on at least Android 16 (not sure about iOS or earlier Android versions). It's not possible to run two VPNs at the same time as "always on". In fact, you can't run more than one at the same time if any are always on, so you end up having to constantly monitor it.

<!-- gh-comment-id:4347055235 --> @unleashit commented on GitHub (Apr 29, 2026): Having the same issue and this has been a show stopper for me in making regular use of any mesh network. It would be really nice if a project could pick a few of the top privacy solutions (maybe Mullvad, Proton VPN and Windscribe) and modify the right iptables/firewall changes to make it work. For the user to try to manage it on each client is hard to impossible. I've tried the solution of manually adding a wireguard interface to a router exit node. While it works, it's not a modern solution (no Daita, multi-hop, obfuscation, no ability to switch slow/offline endpoints, etc). But there's another part of the problem on at least Android 16 (not sure about iOS or earlier Android versions). It's not possible to run two VPNs at the same time as "always on". In fact, you can't run more than one at the same time if any are always on, so you end up having to constantly monitor it.
Author
Owner

@d10n commented on GitHub (May 13, 2026):

For Linux only, my repo cleanly enables NetBird and Mullvad to work together: https://github.com/d10n/netbird-mullvad-bypass
It's packaged for Arch, Fedora, and Debian, but you can just manually install the config files if you prefer.

<!-- gh-comment-id:4446237847 --> @d10n commented on GitHub (May 13, 2026): For Linux only, my repo cleanly enables NetBird and Mullvad to work together: https://github.com/d10n/netbird-mullvad-bypass It's packaged for Arch, Fedora, and Debian, but you can just manually install the config files if you prefer.
Author
Owner

@unleashit commented on GitHub (May 13, 2026):

For Linux only, my repo cleanly enables NetBird and Mullvad to work together: https://github.com/d10n/netbird-mullvad-bypass It's packaged for Arch, Fedora, and Debian, but you can just manually install the config files if you prefer.

Nice work putting that together and also spelling out all the moving parts. Unfortunately in my case, there's a mixture of a lot of different devices so it's only a partial solution. Would be great to see a PR that could add the routing rules as an option directly in the Netbird clients. Wish my Networking skills were good enough to contribute.

<!-- gh-comment-id:4446678391 --> @unleashit commented on GitHub (May 13, 2026): > For Linux only, my repo cleanly enables NetBird and Mullvad to work together: https://github.com/d10n/netbird-mullvad-bypass It's packaged for Arch, Fedora, and Debian, but you can just manually install the config files if you prefer. Nice work putting that together and also spelling out all the moving parts. Unfortunately in my case, there's a mixture of a lot of different devices so it's only a partial solution. Would be great to see a PR that could add the routing rules as an option directly in the Netbird clients. Wish my Networking skills were good enough to contribute.
Author
Owner

@d10n commented on GitHub (May 13, 2026):

Unfortunately in my case, there's a mixture of a lot of different devices so it's only a partial solution.

If you have various devices on your LAN, only one of them needs to have NetBird for you to be able to access all of them if you put them on a NetBird Network. Supposing you have a desktop PC with Linux, NetBird, and Mullvad installed:

  • Create a NetBird Network Home LAN
  • Add a Resource named Desktop PC with address 192.168.1.0/24 (for example, if your router gives your devices with an IP from 192.168.1.2 to 192.168.1.255)
  • Add an Access Control Policy where the Source is the group or peer you will access the LAN from, and the Destination should automatically be filled to Home LAN
  • Add a Routing Peer to Home LAN and select your Desktop PC (leave "Enable Routing Peer" and "Masquerade" enabled in the Advanced Settings, which should be default)
  • Configure Mullvad's VPN settings on the Desktop PC to enable "Local network sharing"
  • Install the configuration from netbird-mullvad-bypass on the Desktop PC and ensure that the systemd service is started and enabled (sudo systemctl enable --now netbird-mullvad-bypass.service)

Then, from any other device with NetBird, you will be able to access the other IPs on your Home LAN via your Desktop PC, as long as the VPN clients are configured to allow LAN traffic, and the firewall port of the destination device is open.

Would be great to see a PR that could add the routing rules as an option directly in the Netbird clients

The issue is that other VPN clients install rules that take precedence over NetBird's routing table, which drop packets before NetBird receives them, so the ideal place for an integration fix is the VPN clients themselves. That's probably never going to happen, because VPN clients won't want customers to accidentally send traffic outside of the VPN, so a lightweight community maintained configuration service like netbird-mullvad-bypass is the next best place.

Good luck!

(edit: forgot to mention adding a Routing Peer)

<!-- gh-comment-id:4447040980 --> @d10n commented on GitHub (May 13, 2026): > Unfortunately in my case, there's a mixture of a lot of different devices so it's only a partial solution. If you have various devices on your LAN, only one of them needs to have NetBird for you to be able to access all of them if you put them on a NetBird Network. Supposing you have a desktop PC with Linux, NetBird, and Mullvad installed: * Create a NetBird Network `Home LAN` * Add a Resource named `Desktop PC` with address `192.168.1.0/24` (for example, if your router gives your devices with an IP from 192.168.1.2 to 192.168.1.255) * Add an Access Control Policy where the Source is the group or peer you will access the LAN from, and the Destination should automatically be filled to `Home LAN` * Add a Routing Peer to Home LAN and select your Desktop PC (leave "Enable Routing Peer" and "Masquerade" enabled in the Advanced Settings, which should be default) * Configure Mullvad's VPN settings on the Desktop PC to enable "Local network sharing" * Install the configuration from netbird-mullvad-bypass on the Desktop PC and ensure that the systemd service is started and enabled (`sudo systemctl enable --now netbird-mullvad-bypass.service`) Then, from any other device with NetBird, you will be able to access the other IPs on your Home LAN via your Desktop PC, as long as the VPN clients are configured to allow LAN traffic, and the firewall port of the destination device is open. > Would be great to see a PR that could add the routing rules as an option directly in the Netbird clients The issue is that other VPN clients install rules that take precedence over NetBird's routing table, which drop packets before NetBird receives them, so the ideal place for an integration fix is the VPN clients themselves. That's probably never going to happen, because VPN clients won't want customers to accidentally send traffic outside of the VPN, so a lightweight community maintained configuration service like netbird-mullvad-bypass is the next best place. Good luck! (edit: forgot to mention adding a Routing Peer)
Author
Owner

@unleashit commented on GitHub (May 14, 2026):

Actually have a bunch of devices including several phones that don't publish any resources themselves but need to access a couple of servers on the LAN. So all those devices need would need the client as far as I know, and especially the phones when roaming. The idea of sharing an exit node is something I've tried and it just doesn't work well, not to mention is confusing to the non-nerds of my users! What I'd really need to make it work is to allow each internet accessing device the freedom to use Mullvad as their own exit node as normal. So for me at least, the situation isn't yet mature enough to really get on the mesh network bandwagon. Maybe if it's as difficult as you say to achieve compatibility (in a secure way) between products, then it still seems like a great opportunity for someone to create a product combines both a mesh network and a secure anonymous exit. Weather we trust that company is another story!

<!-- gh-comment-id:4456245280 --> @unleashit commented on GitHub (May 14, 2026): Actually have a bunch of devices including several phones that don't publish any resources themselves but need to access a couple of servers on the LAN. So all those devices need would need the client as far as I know, and especially the phones when roaming. The idea of sharing an exit node is something I've tried and it just doesn't work well, not to mention is confusing to the non-nerds of my users! What I'd really need to make it work is to allow each internet accessing device the freedom to use Mullvad as their own exit node as normal. So for me at least, the situation isn't yet mature enough to really get on the mesh network bandwagon. Maybe if it's as difficult as you say to achieve compatibility (in a secure way) between products, then it still seems like a great opportunity for someone to create a product combines both a mesh network and a secure anonymous exit. Weather we trust that company is another story!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#4407