Problem with clients behind the "residential NAT"

[cdspacedos]

Hello Everyone,

I'm new to Nebula, so apologies upfront for the asking/repeating questions. I have a user behind the "residential NAT", and upon connecting to the overlay network, that user can only ping the Lighthouse host (and vice versa), but not other peers in the network. Is there any configuration tip to overcome this problem?

I would eventually use Nebula to connect with a few hundred users worldwide, and I cannot ask them to change their network configuration.

[bouillon]

The same here. Nebula not working behind NAT Router -> NAT -> PC ---- MobileRouter -> NAT PC is my current setup. I also can only connect to Lighthouse. Light house can connect to each host. This makes nebula useless in my case. I used tailscale before and it works with this setup but i don't like closed server required login.

[joshaspinall]

I use Nebula in the same manner, and while I occasionally see a hiccup it has been very reliable. I have devices at different houses behind residential NAT, and mobile as well.

Are you using the example config tweaked to suit? Any specific options set?

[cdspacedos]

I'm using the example configuration with minimal changes to reflect the public IP address of the lighthouse, the private subnet (in my case 192.156.255.0/24). At the client side I've been configuring options in the "punchy" section hoping that this might help with the CGNAT.

I've attached the sample client + lighthouse configuration file.

config-short.txt lighthouse-short.txt

[joshaspinall]

Double check the syntax of the punchy entry, see mine below. Also, try adding the punch_back option, which may be the setting that will help your clients connect.

punchy: true punch_back: true

[cdspacedos]

Properly configuring the "punchy" section did the trick. Now the clients behind the CGNAT can reach each other. Thank you very much for your help @joshaspinall !

I still have to figure out the systemd start/stop scripts for Nebula as I'm using Ubuntu 20.04, but that's going to be easy.

If nobody has any comments/questions, I will close this issue.

[joshaspinall]

Happy to help! Glad that you're up and running successfully. Please close down when you're ready.

There's an example systemd/init service file in the repo here.

[IceWreck]

Double check the syntax of the punchy entry, see mine below. Also, try adding the punch_back option, which may be the setting that will help your clients connect.

punchy: true punch_back: true

I don't see a reference to punch_back: true and the punch syntax is different in the example config. Is one of these new ?

[bouillon]

Ok, for me is still not woks. I have the near the same configs like cdspacedos from examples and with punch_back: true

punchy:
  punch: true
  punch_back: true
  respond: true
  delay: 1s

On lighthouse and hosts.

lighthouse.txt hosts.txt

Can connect only from lighthouse. Ok may be my network is little bit more complex as i wrote before hier

like

Fritzbox (router) -> Router (for Wifi) -> Clients the other side Mobile Huawei router -> Router (for Wifi) -> Clients

So i have two router on both sides.

Lighthouse logs have some timeouts log.txt

[joshaspinall]

@bouillon as with cdspacedos, your syntax is not 'correct' (despite being different to the example file).

Change: punchy: punch: true punch_back: true respond: true delay: 1s

to: punchy: true punch_back: true respond: true delay: 1s

Please report back how you get on!

[chirayu-patel]

I guess there is no issue in syntax, punchy.respond and punchy.punch have been kept backward compatible along with the new config. You can refer to punchy.go for the same.

I have faced similar issues with the NAT layer existing on both the sides. It just doesn't work.

Zerotier in the same setup is somehow able to make it work. :(

Anyways, cant do much. As of now, I am planning to implement my own relay in such cases using additional routing hop through the lighthouse.

[chirayu-patel]

Also, wanted to know , has any one of you used windows client on v1.5.2 ? I get the message : "Failed to get a tun/tap device". The exact same way if I run v1.5.0, it works.

I have raised a separate issue for the same since sometime but no one is responding on that.

Can someone please let me know. Thanks

[bouillon]

@chirayu-patel i not use windows, only linux clients @joshaspinall reporting back. Not working. Same issue. Changing to punchy: true punch_back: true respond: true delay: 1s

here they have the same issue #663

[DePingus]

If you're using OPNsense or PFsense have a look here: https://blog.ktz.me/punching-through-nat-with-nebula-mesh/

The reason ZeroTier works is because when ZT fails to punch through UDP, it will fall back to using the moon as a relay. Nebula doesn't have a relay mode.

[bouillon]

i'm not using OPNSENSE or PFsense. I just try to understand. It's a bug or not? If not nebula is not what i need. I just needs a solution with works also behind nat. Normal SSH tunnel with a global available host do it. But i'm looking for more cool solution.

[brad-defined]

% go install github.com/pion/stun/cmd/[email protected]
% stun-nat-behaviour 2>&1 | grep "NAT mapping"

NAT's come in many flavors, and Nebula works great even with both peers behind many types of NAT's, but not all. If you run these commands on a Nebula instance that is having trouble connecting to other Nebula peers and get NAT mapping behavior: address dependent or address and port dependent, then I think punchy will not be able to get UDP packets to flow to each other in all cases.

In the dependent cases, Nebula will still work if:

• both peers have IPv6 addresses (and you're using the Nebula version that supports IPv6)
• OR if the other peer isn't behind a NAT - meaning it has a public internet IP & firewall that permits unsolicited inbound traffic to the Nebula port (like the lighthouse.)

If you run that command and get NAT mapping behavior: endpoint-independent on both peers behind NATs, then Nebula's punchy should work great, and you're likely encountering some other networking issue preventing the Nebula UDP packets from getting where they need to go.

[jasikpark]

If you're using OPNsense or PFsense have a look here: blog.ktz.me/punching-through-nat-with-nebula-mesh

The reason ZeroTier works is because when ZT fails to punch through UDP, it will fall back to using the moon as a relay. Nebula doesn't have a relay mode.

#678 is working on adding experimental support at some point; hopefully, that'll improve things?

[brad-defined]

Nebula 1.6.0 is released with a Relay feature, to cover cases like a Symmetric NAT. https://github.com/slackhq/nebula/pull/678

Check out the example config to see how to configure a Nebula node to act as a relay, and how to configure other nodes to identify which Relay can be used by peers for access. Take a look at https://github.com/slackhq/nebula/issues/33#issuecomment-1180569297 for more info on how to configure it.

[DePingus]

Excellent news! Will the mobile apps still work with 1.6.0? Or should we wait for those apps to be updated before upgrading the rest of the lighthouse?

[brad-defined]

You can update the rest of your nodes to 1.6 without waiting for the mobile update, which will take a couple weeks to push out. But, you may have access issues from mobile in the meantime.

[johnmaguire]

FWIW, the mobile apps have been updated to support relays!

At this time, I'm closing this out for inactivity. If you continue to have issues after trying the relay feature, please feel free to open up a new issue or join us on Slack. Thanks!