It would be useful if the VPN server could work behind a NAT device. Of course, ideally this would be the edge device, but it’s not always the case. There are multiple use cases. Mine at the moment is that I partially set up just the basics for a site, just enough to get everything online and updated, but I won’t be back onsite for a little while and there are other local devices I need to access to continue getting the entire system setup. I wasn’t going to dare throwing the Comcast modem into bridge mode until I knew everything was functional within the Alta network, which means the Route10 has the private 10.x.x.x WAN IP.
I tried to connect via VPN, but as I suspected, the Alta VPN is pretty basic, needs it’s WAN exposed. I know it’s possible to do, some others do it.
Another use case could be that only a particular VLAN needs VPN access and there’s a more robust edge device in place. This would allow sticking a Route10 on the applicable VLAN and presto.
We actually do not currently restrict the listen interface for the VPN servers, they work perfectly fine behind double-NAT. However, I think I know where the confusion lies, and this isn’t in our documentation yet (it will be, creating a card for it after this post).
The id.ddns.manage.alta.inc hostname format will resolve to a physical WAN interface. Do note that this is the literal IP on the interface itself, hence why you’re seeing the rfc1918 address. There are some variations to this hostname that I would like to make you aware of, one of which will help here assuming the upstream gateway is properly configured to forward to the Route10.
So main hostname again is: id.ddns.manage.alta.inc
- To return the
wan IP (WAN 1): 1.id.ddns.manage.alta.inc
- To return the
wan2 IP (WAN 2): 2.id.ddns.manage.alta.inc
- ^… etc, for WANs following their logical number, not metrics/weighting.
- To return the current external IP, not the literal interface IP, you would use:
public.id.ddns.manage.alta.inc
It’s that last one which you want to leverage in your case. Try adding public. to the hostname. You could also use the external IP if you knew it.
1 Like
Thanks, that’s helpful and good to know. It’s not exactly what I was shooting for here. I’m talking about the Route10 creating a pathway through the edge device to be reachable from a remote VPN client, that is, without touching the edge device and setting up port forwarding. I know Meraki has this option and I don’t recall if Ubiquiti does.
Ah, well I may have good news. We have plans to add support for Tailscale which is a mesh based WireGuard service where an external relay is used to communicate through. I imagine that would at least achieve a similar end result, if it wasn’t a similar architecture. Unfortunately I have not heard timelines, other than it is planned.
Would that better align here?
2 Likes