VPN : T35-R to T35-R with Starlink at BOTH ends
I'd like to setup a point to point VPN using a T35-R and a Starlink at each end.
(trying to create a secure network between two very remote locations, no fixed lines and very poor 3G/4G coverage)
Starlinks are currently both in "bypass" mode so the WAN ports on both the T35-R see the Starlink CGNAT IP of 100.x.x.x
Is this possible as both ends are sitting behind Starlink CGNAT?
Sign In to comment.
Yes. Fireware supports NAT-T, so the IPSec VPN will use TCP & UDP ports, which will work to devices behind a NAT router.
Also, from a post on Reddit I found on the Internet, there are sites which have IPSec tunnels using Starlink.
It may be best to set up DYNDNS and connect using domain names instead of IP addrs.
If you're able to pass the UDP/500 or 4500 traffic from one firewall directly to the other, this should in theory work -- however, if both firewalls are getting addresses via DHCP, we won't necessarily get DNS resolution for those endpoints by the time the firewall tries to bring the tunnel up. VPNs where both sides are dynamic are generally not a great idea because of this.
A more reliable option would be to have both starlink'ed firewalls connect to another firewall and get traffic from one to the other using tunnel switching.
WatchGuard Customer Support
Thanks for the pointers.
We have made a little progress during a support call with WatchGuard.
He got one Starlink & T35-R to establish a tunnel to a separate device.
So the required VPN info is allowed to pass through the Starlink system.
But trying to link two "Starlink & T35-R" setups together still will not establish the tunnel.
The support engineer has a theory that the trying to connect two Starlink systems that both exist behind the Starlink CGNAT might be the issue.
We tried to replace one of the ends with a 4G cellular modem ( on Vodafone UK) and establish the VPN via that.
Same result so far...not establishing the tunnel. Maybe suffering the same fate as I understand that many cellular systems also use CGNAT.
In our application it's going to be very difficult to get one end to be static IP as there is no fixed infrastructure in place at either end.
It may be that we need to use the solution that James suggests with a 3rd device and use tunnel switching.
Any thoughts on what effect that might have on latency?
For info, I setup Dynamic DNS (afraid.org) on the T35-Rs for both ends which refer back to the 100.x.x.x Starlink CGNAT IPs.
I think they are overcomplicating it. If either of your WG devices has a static IP (or DDNS) you can simply create the tunnel with domain settings (even with out a domain controller). I have even had that work with the remote side (dynamic) on a double NAT.
Try selecting the "Allow the dynamic DNS provider to determine the IP address" option on your Dynamic DNS settings on each end.
See if that helps.
From the docs:
For the dynamic DNS provider to use the IP address from your router or NAT device, select the Allow the dynamic DNS provider to determine the IP address check box.
The Tip says:
Select this option if you do not want the dynamic DNS provider to use the IP address of the external interface on your Firebox.
Already ticked on both fireboxes
Think that's the issue ... we don't
"WhatsMyIP" reports that the "real" public IP is 145.x.x.x
but this public IP is shared my many Starlink subscribers by the Starlink CGNAT.
Fireboxes think the "public IP" is 100.x.x.x , allocated by the Starlink CGNAT.
This is what gets updated to the DDNS service.
We have already tested with one end on an alternative device with a reliable public IP (via DDNS). The fireboxes connected to the Starlinks (via CGNAT) could establish a tunnel to this "reliable" device.
The problem is we don't have that "reliable IP" luxury on either of our two remote sites. Which leads to the discussion of the third box acting as the bridge.
I have never seen an instance where DDNS has not worked...this may be the one.
Have you tried setting up using the real public IP addrs?
If this works, then there are various Windows etc. based clients which can update a specific Dynamic DNS provider's info - so you would not use the firewall Dynamic DNS settings.
We did try that as part of the diagnostic tests.
I believe the problem there was that the "real" public IP is shared by Starlinks CGNAT between many subscribers so the when external traffic hits the IP it cannot determine the intended CGNAT destination.
In the test we performed we manually typed the IP addr in the appropriate boxes.
Just for the sake of completeness I'll repeat via DDNS.
The fact is if either side would work with DNS the tunnel should come to life. I would toss up an image of the one that I have with the double NAT....but, I cant get into the box from the outside ;-)