[GH-ISSUE #5978] Windows Firewall blocks P2P-Connection #11423

Open
opened 2026-08-05 01:29:39 -04:00 by saavagebueno · 2 comments
Owner

Originally created by @aj-bi on GitHub (Apr 24, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5978

Describe the problem

On Windows systems, NetBird fails to establish a P2P connection even when the NAT/Gateway has been correctly configured with port forwarding (UDP 51820). The Windows Defender Firewall blocks incoming Wireguard Handshake packets on the physical interface because no explicit inbound rule exists for the Wireguard listen port. This forces the client to fall back to a Relay (TURN) connection.

To Reproduce

Set up a NetBird client on Windows behind a router with Port Forwarding for UDP 51820 to the Windows machine.

Ensure Windows Defender Firewall is active with default settings.

Check connection status: netbird status -d.

Observe that the connection remains "Relay" despite the router passing the traffic.

Disable Windows Firewall temporarily or add a manual UDP 51820 inbound rule -> Connection immediately switches to "P2P".

Expected behavior

The NetBird installer or the client service should automatically create a Windows Firewall inbound rule for the configured Wireguard UDP port (default 51820) to allow P2P hole punching and direct communication on all network profiles (Private/Public).

Are you using NetBird Cloud?

self-hosted

NetBird version

0.69

Is any other VPN software installed?

no

Have you tried these troubleshooting steps?

  • [ X ] Reviewed client troubleshooting (if applicable)
  • [ X ] Checked for newer NetBird versions
  • [ X ] Searched for similar issues on GitHub (including closed ones)
  • [ X ] Restarted the NetBird client
  • [ X ] Disabled other VPN software
  • [ X ] Checked firewall settings
Originally created by @aj-bi on GitHub (Apr 24, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5978 **Describe the problem** On Windows systems, NetBird fails to establish a P2P connection even when the NAT/Gateway has been correctly configured with port forwarding (UDP 51820). The Windows Defender Firewall blocks incoming Wireguard Handshake packets on the physical interface because no explicit inbound rule exists for the Wireguard listen port. This forces the client to fall back to a Relay (TURN) connection. **To Reproduce** Set up a NetBird client on Windows behind a router with Port Forwarding for UDP 51820 to the Windows machine. Ensure Windows Defender Firewall is active with default settings. Check connection status: netbird status -d. Observe that the connection remains "Relay" despite the router passing the traffic. Disable Windows Firewall temporarily or add a manual UDP 51820 inbound rule -> Connection immediately switches to "P2P". **Expected behavior** The NetBird installer or the client service should automatically create a Windows Firewall inbound rule for the configured Wireguard UDP port (default 51820) to allow P2P hole punching and direct communication on all network profiles (Private/Public). **Are you using NetBird Cloud?** self-hosted **NetBird version** 0.69 **Is any other VPN software installed?** no **Have you tried these troubleshooting steps?** - [ X ] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) - [ X ] Checked for newer NetBird versions - [ X ] Searched for similar issues on GitHub (including closed ones) - [ X ] Restarted the NetBird client - [ X ] Disabled other VPN software - [ X ] Checked firewall settings
saavagebueno added the triage-needed label 2026-08-05 01:29:39 -04:00
Author
Owner

@aj-bi commented on GitHub (Apr 24, 2026):

I've used the following Powershell for my Firewall rule:
New-NetFirewallRule -DisplayName "NetBird P2P" -Direction Inbound -Protocol UDP -LocalPort 51820 -Action Allow

<!-- gh-comment-id:4311488384 --> @aj-bi commented on GitHub (Apr 24, 2026): I've used the following Powershell for my Firewall rule: New-NetFirewallRule -DisplayName "NetBird P2P" -Direction Inbound -Protocol UDP -LocalPort 51820 -Action Allow
Author
Owner

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

Hi, same issue here, I do have a particularity with my setup, the peers that I use as exit-nodes do connect P2P, but other peers to access databases or internal services change the connection to Relay, even when doing testing in the same origin network.

<!-- gh-comment-id:4444459861 --> @Poi9912 commented on GitHub (May 13, 2026): Hi, same issue here, I do have a particularity with my setup, the peers that I use as exit-nodes do connect P2P, but other peers to access databases or internal services change the connection to Relay, even when doing testing in the same origin network.
Sign in to join this conversation.
No Label triage-needed
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11423