You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a local network with IP range 192.168.1.0/24. This network has an Android phone, a linux laptop, and a Proxmox server, all running nebula. There is a lighthouse outside of the local network, which has a public IP. The Proxmox server has an internal bridge, which several virtual machines are connected to. Proxmox NATs traffic from the VM bridge to the internal network (so the VMs are doubled-NATted when talking to the internet). All devices have punchy.punch = true, punchy.respond = true (except the phone, where the app forces punchy.respond = false). There are no relays configured.
The Android phone can connect to the lighthouse, laptop, and Proxmox server, but it can't connect to any of the VMs. By inspecting the output of list-lighthouse-addrmap from the nebula ssh shell on the laptop, I think I understand why this is: the reported addresses for the phone include only the public IP of the local router, and not the phone's local IP address. This appears to be different behavior from the other devices, which do report local addresses.
Specifically, the phone's entry (nebula IP 100.100.0.5) in list-lighthouse-addrmap looks like this:
100.100.0.5: {"100.100.0.1":{"reported":["<LOCAL ROUTER PUBLIC IP>:35748"],"relay":[]}}
Whereas, for example, the proxmox server (nebula IP 100.100.0.3) looks like this. Note it includes an address in the local range, 192.168.1.136.
100.100.0.3: {"100.100.0.1":{"reported":["<LOCAL ROUTER PUBLIC IP>:4242","192.168.1.136:4242","<VM BRIDGE IP>:4242"],"relay":[]},"100.100.0.3":{"learned":["192.168.1.136:4242"],"relay":[]}}
My hypothesis is that since the VM IP addresses are not routable from the local network, connections from the phone or the laptop are reliant on the VMs punching back from their side of the connection to the phone/laptop local IP address. But since the phone doesn't appear to report this address, the connection can't be established.
The text was updated successfully, but these errors were encountered:
I have a local network with IP range
192.168.1.0/24
. This network has an Android phone, a linux laptop, and a Proxmox server, all running nebula. There is a lighthouse outside of the local network, which has a public IP. The Proxmox server has an internal bridge, which several virtual machines are connected to. Proxmox NATs traffic from the VM bridge to the internal network (so the VMs are doubled-NATted when talking to the internet). All devices havepunchy.punch = true
,punchy.respond = true
(except the phone, where the app forcespunchy.respond = false
). There are no relays configured.The Android phone can connect to the lighthouse, laptop, and Proxmox server, but it can't connect to any of the VMs. By inspecting the output of
list-lighthouse-addrmap
from the nebula ssh shell on the laptop, I think I understand why this is: the reported addresses for the phone include only the public IP of the local router, and not the phone's local IP address. This appears to be different behavior from the other devices, which do report local addresses.Specifically, the phone's entry (nebula IP
100.100.0.5
) inlist-lighthouse-addrmap
looks like this:Whereas, for example, the proxmox server (nebula IP
100.100.0.3
) looks like this. Note it includes an address in the local range,192.168.1.136
.My hypothesis is that since the VM IP addresses are not routable from the local network, connections from the phone or the laptop are reliant on the VMs punching back from their side of the connection to the phone/laptop local IP address. But since the phone doesn't appear to report this address, the connection can't be established.
The text was updated successfully, but these errors were encountered: