Extremely slowed traffic flow/speed between peers #2308

Open
opened 2025-11-20 07:07:31 -05:00 by saavagebueno · 6 comments
Owner

Originally created by @Sameer484 on GitHub (Sep 24, 2025).

Describe the problem
I have extremely slow downloading speed when the local machines try to fetch the remote (internal) resource using Routing Peer. Here is the scenario:

  • I have a Routing Peer on one EC2 instance, inside private subnet which obviously has NAT gateway.
  • The Netbird Server is hosted in another EC2 instance in public subnet
  • The AWS internal resources are in their own subnets
  • My local devices or laptops are in their different corporate or home networks which tries to access AWS internal resources
  • I have configured DNS resolution and network route which goes through Routing Peer. So that the internal resources can be accessed via Routing Peer.

And in this scenario, my users are getting extremely slow connectivity issues when trying to download high size files like around 20-30MB. For your information, my internet connection is not slow. When i use another VPN like OpenVPN, the connection is fast but using Netbird, the speed is frustrating.

I am trying to use Netbird in Corporate level but this issue makes me concerning. Are there any solutions around this architecture?

Are you using NetBird Cloud?

No, it's self hosted on AWS EC2 instance

NetBird version

Latest.

Debug output
One thing to note is when I do netbird status --detail, I see that Netbird Routing Peer is connected via Relay to my users devices. So, I think this is the problem but there should be an option to fix this issue right? Can i enable or force P2P connection? And for that, do i need to expose my Routing Peer to internet (host routing peer in public subnet)? And will it solve the problem?

Please suggest the solution considering security. I cannot compromise on Security Side and expose everything to internet. But if it is Okay from security perspective, I am happy to hear your responses.

Originally created by @Sameer484 on GitHub (Sep 24, 2025). **Describe the problem** I have extremely slow downloading speed when the local machines try to fetch the remote (internal) resource using Routing Peer. Here is the scenario: - I have a Routing Peer on one EC2 instance, inside private subnet which obviously has NAT gateway. - The Netbird Server is hosted in another EC2 instance in public subnet - The AWS internal resources are in their own subnets - My local devices or laptops are in their different corporate or home networks which tries to access AWS internal resources - I have configured DNS resolution and network route which goes through Routing Peer. So that the internal resources can be accessed via Routing Peer. And in this scenario, my users are getting extremely slow connectivity issues when trying to download high size files like around 20-30MB. For your information, my internet connection is not slow. When i use another VPN like OpenVPN, the connection is fast but using Netbird, the speed is frustrating. I am trying to use Netbird in Corporate level but this issue makes me concerning. Are there any solutions around this architecture? **Are you using NetBird Cloud?** No, it's self hosted on AWS EC2 instance **NetBird version** Latest. **Debug output** One thing to note is when I do netbird status --detail, I see that Netbird Routing Peer is connected via Relay to my users devices. So, I think this is the problem but there should be an option to fix this issue right? Can i enable or force P2P connection? And for that, do i need to expose my Routing Peer to internet (host routing peer in public subnet)? And will it solve the problem? Please suggest the solution considering security. I cannot compromise on Security Side and expose everything to internet. But if it is Okay from security perspective, I am happy to hear your responses.
saavagebueno added the triage-needed label 2025-11-20 07:07:31 -05:00
Author
Owner

@1nerdyguy commented on GitHub (Sep 24, 2025):

If you're relaying, you're not able to negotiate p2p, and it's usually due to NAT issues.

If you can do a static NAT to your routing peer for port 51820 (or whatever you're using for wireguard), this may take care of it.

@1nerdyguy commented on GitHub (Sep 24, 2025): If you're relaying, you're not able to negotiate p2p, and it's usually due to NAT issues. If you can do a static NAT to your routing peer for port 51820 (or whatever you're using for wireguard), this may take care of it.
Author
Owner

@Sameer484 commented on GitHub (Sep 25, 2025):

@1nerdyguy

So, how is it possible to do this while using AWS private subnet and NAT? The private subnet already has NAT but this doesn't help. The Routing Peer behind private subnet is still making relayed connection to my user's devices.

@Sameer484 commented on GitHub (Sep 25, 2025): @1nerdyguy So, how is it possible to do this while using AWS private subnet and NAT? The private subnet already has NAT but this doesn't help. The Routing Peer behind private subnet is still making relayed connection to my user's devices.
Author
Owner

@1nerdyguy commented on GitHub (Sep 25, 2025):

AWS isn't my forte, so really couldn't say. But this isn't really a netbird issue, it's a NAT issue.

With a quick google
If you are using a self-managed NAT instance (instead of the recommended NAT Gateway) and are having problems with it forwarding traffic, you must disable the source/destination check. This is necessary because the instance is sending and receiving traffic on behalf of other instances.
What it does: This setting is enabled by default for EC2 instances. Disabling it allows the NAT instance to send traffic with a source IP that doesn't match its own, and to receive traffic destined for other IP addresses.
How to implement:
Go to the Amazon EC2 console.
Select your NAT instance.
Choose Actions, then Networking, then Change source/destination check.

@1nerdyguy commented on GitHub (Sep 25, 2025): AWS isn't my forte, so really couldn't say. But this isn't really a netbird issue, it's a NAT issue. With a quick google If you are using a self-managed NAT instance (instead of the recommended NAT Gateway) and are having problems with it forwarding traffic, you must disable the source/destination check. This is necessary because the instance is sending and receiving traffic on behalf of other instances. What it does: This setting is enabled by default for EC2 instances. Disabling it allows the NAT instance to send traffic with a source IP that doesn't match its own, and to receive traffic destined for other IP addresses. How to implement: Go to the Amazon EC2 console. Select your NAT instance. Choose Actions, then Networking, then Change source/destination check.
Author
Owner

@Sameer484 commented on GitHub (Oct 6, 2025):

@1nerdyguy

Thanks for the response.

I have created Routing Peer on public subnet with public IP address. It was able to make P2P connection earlier, but now it is not been able to make the P2P.

My question is, will the connection be P2P if only one peer have direct public IP address? Because my home devices are behind ISP network and my routing peer have direct public IP address.

@Sameer484 commented on GitHub (Oct 6, 2025): @1nerdyguy Thanks for the response. I have created Routing Peer on public subnet with public IP address. It was able to make P2P connection earlier, but now it is not been able to make the P2P. My question is, will the connection be P2P if only one peer have direct public IP address? Because my home devices are behind ISP network and my routing peer have direct public IP address.
Author
Owner

@Sameer484 commented on GitHub (Oct 6, 2025):

@mlsmaycon

Can you help with some suggestions here? I am really struggling to create P2P connection.

@Sameer484 commented on GitHub (Oct 6, 2025): @mlsmaycon Can you help with some suggestions here? I am really struggling to create P2P connection.
Author
Owner

@1nerdyguy commented on GitHub (Oct 6, 2025):

Check your nat on both sides.

What happens (to my knowledge) is when a Client tries to make a connection to another client/routing peer, it uses the ICE/TURN to notify "Hey, I'm available at PublicIP:Port" The Ice/turn/relay/whatever informs the other client of this info, and they attempt to make a connection using that.

The problem that I keep running into is when you have a strict NAT environment, which is more and more common. This means when the client reaches out to the Ice/turn/whatever on port xyz, it will only allow incoming traffic/response from that IP. So when the other client tries, coming from a different IP, it gets dropped.

@1nerdyguy commented on GitHub (Oct 6, 2025): Check your nat on both sides. What happens (to my knowledge) is when a Client tries to make a connection to another client/routing peer, it uses the ICE/TURN to notify "Hey, I'm available at PublicIP:Port" The Ice/turn/relay/whatever informs the other client of this info, and they attempt to make a connection using that. The problem that I keep running into is when you have a strict NAT environment, which is more and more common. This means when the client reaches out to the Ice/turn/whatever on port xyz, it will only allow incoming traffic/response from that IP. So when the other client tries, coming from a different IP, it gets dropped.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#2308