Activating lighthouse drops all networking about nebula HOT 8 CLOSED

This does not happen when utilizing lighthouse settings on a node with a local ip behind a router

from nebula.

Can you share the command you are using to generate your certificates for each node?

from nebula.

static_host_map: "publicIP": ["publicIP:4242"]

It looks like you're using the publicIP in both spots.
Format should be "192.168.100.1": ["192.30.253.113:4242"]

from nebula.

@zfwjs yeah, I need to check but this might be a bug in that handling. I assume "publicIp" fails to parse and we might just move forward with a 0.0.0.0 route.

from nebula.

Update ---

All networking is not lost. It seemed like it and I could have tested further to see that all networking was not lost, but as I was not at the location of the server at that time I did not think of it.

All inbound connection seems to be lost at the lighthouse node. ONLY on this machine that ONLY has a public ip, there is no router, so I cannot utilize an ip like 192.168.100.1, the machine is directly connected only to a public ip.

The odd part is that the ping command works properly. Makes me feel like I have no idea what I'm doing.

I use port 477 for ssh, so I added tcp and udp rules for 477, the config I pasted up above was before I added tcp 477.

After I activate nebula on this lighthouse I am unable to connect to the lighthouse via ssh, but only on this node.

I tested with a small google compute instance which of course gets the internal ip as well as the public ip. I set up the lighthouse with the exact same settings and it worked perfectly right out of the gate. Activating nebula on this lighthouse did not break ssh connection, and did not break any internal connections.

I believe the command I'm using to issue certs is not useful, as I have 2 lighthouses with the exact same settings in which one works and one does not once nebula has been activated with the only difference being the ip. Although the commands I'm using to issue certs are
./nebula-cert sign -name "pcname" -ip "xxx.xxx.xxx.xxx/xx"

from nebula.

@GettingTechnicl the two comments above yours are the ones to keep in mind. the 192.168.100.x subnet is something you define to your individual nebula deployment. If you need to use a different ip range, you can make that anything you want, as long as it doesn't conflict with your local network ip range anywhere.

The key here is that the static host map can not have a non-nebula IP as its first argument, as the folks above have stated. It needs to be the IP you assigned to a static node via its certificate.

from nebula.

@rawdigits

Thank you, I believe that will resolve my issue then. I was under the impression that this needed to be what the machines local routable ip would be on that machines internal network.

I will update when this is working.

from nebula.

This did resolve the issue completely. Thanks for your assistance.

from nebula.