Extremely slowed traffic flow/speed between peers

[Sameer484]

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.

[1nerdyguy]

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.

[Sameer484]

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

[1nerdyguy]

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.

[Sameer484]

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

@mlsmaycon

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

[1nerdyguy]

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.

[bcoutts]

I'm having similar issues with a client. speeds are all over the place, but mostly slow or SMB transfers will start out fast and slowly trickle down to 300 Kbps on a 300Mbps upload. No relays, all P2P. Very frustrating.

[kether888]

I was having similar problems until I switched my routing peers from win11 to ubuntu. SMB speeds went up 100x, from 355KB/s to 40MB/s.