SVI/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-04-22 09:22:19 -04:00
Code Issues 3.0k Packages Projects Releases 10 Wiki Activity

Connectivity Issues with Active Mullvad VPN on a Netbird Peer #985

New Issue
Open
opened 2025-11-20 05:21:02 -05:00 by saavagebueno · 2 comments
saavagebueno commented 2025-11-20 05:21:02 -05:00
Owner
Copy Link

Originally created by @RoguePwner on GitHub (Jun 17, 2024).

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). ### 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 2025-11-20 05:21:02 -05:00
saavagebueno commented 2025-11-20 05:21:02 -05:00
Author
Owner
Copy Link

@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!

@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!
saavagebueno commented 2025-11-20 05:21:02 -05:00
Author
Owner
Copy Link

@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.

@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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
2021 Q4
2022 Q1
2022 Q1
accessibility
acl
agent
agent
Android
Android
api
authentik
automation
azure
battery-usage
bug
cache
client
client-ui
cloud
cloud-only
cloudflare
community
compatibility
config-idp
config-issue
connection
contribution
coturn
cross-vpn
dashboard
data-usage
distribution
dns
docker
documentation
duplicate
enhancement
enhancement
event-stream
feature-request
freebsd
getting-started
go
good first issue
gui
help wanted
home-assistant
idp
inconsistency
integration
integrations
ios
ipv6
jwt
k8s
keycloak
linux
login
macos
management-service
missing-docs
mobile
moved-internal
needs-review
netbird-ui
networking
new-platform
nginx
notification
okta
openwrt
packaging
peer-management
peer-management
peer-management
performance
postgres
posture-checks
psk
pull-request
Mirrored from GitHub Pull Request
 question
refactor
relay
release
rfc
routes
security
security-related
self-hosting
server
signal
sleep-issue
ssh
ssl
status
store
synology
system-compatibility-issue
test-suite
third-party-integration
triage
triage-needed
troubleshooting
UX
waiting-feedback
windows
wontfix
zitadel
No Label client compatibility
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#985
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?