Community discussions

MikroTik App
 
schwartzie
just joined
Topic Author
Posts: 2
Joined: Thu Aug 10, 2023 6:38 am

CGNAT IP range conflict between Starlink and Tailscale site-to-site VPN

Wed Mar 20, 2024 11:14 pm

Hello,

We have a mobile manufacturing plant built in a trailer that we tow to clients' sites. The trailer has a Starlink (gen 2) in bypass mode for WAN connectivity and an RB5009 serving its LAN. We have an application hosted on the LAN that folks at our office or working from their homes need to access, so we've deployed Tailscale's VPN service to enable remote access.

We're trying to deploy Tailscale with a site-to-site configuration with our office. We have a machine on the trailer that acts as the Tailscale endpoint/subnet router and we're able to connect to it remotely. Unfortunately, we're running into a conflict in the CGNAT IP range for fully implementing site-to-site as that requires a static route for 100.64.0.0/10 (e.g. the full CGNAT IP range) with the Tailscale endpoint as the gateway, and our Starlink DHCP lease is 100.88.x.x/10 which also claims the full CGNAT IP range.

When we try to activate site-to-site, there's already a dynamic route created directing 100.64.0.0/10 traffic to the router's WAN port, so remote connections can come into the trailer's LAN, but are misrouted to the WAN port instead of to the Tailscale endpoint.

We can tighten up the IP range that Tailscale uses for our machines, but it'll still be in the CGNAT block. From what I've seen on this forum and elsewhere, there's minimal/no configurability of Starlink's DHCP server, but this post has me wondering if we can potentially pick a static IP in the CGNAT range instead of using a DHCP client, which hopefully could let us manually manage/avoid the conflict.

How would you all approach this? Is there anything else we can do to isolate the WAN connection in a VLAN/SDN so the conflicting routing table entries can be separated?

Thank you!
 
User avatar
Larsa
Forum Guru
Forum Guru
Posts: 1106
Joined: Sat Aug 29, 2015 7:40 pm
Location: The North Pole, Santa's Workshop

Re: CGNAT IP range conflict between Starlink and Tailscale site-to-site VPN  [SOLVED]

Thu Mar 21, 2024 1:27 pm

Some suggestions: Set up your own TailScale address pool, use IPv6, or switch to ZeroTier.

RB5009 has built-in support for ZeroTier which allows you to pick any or multiple private subnets and also set individual static addresses on any device. There is no problem running ZeroTier and Tailscale in parallel if you prefer during testing.
 
schwartzie
just joined
Topic Author
Posts: 2
Joined: Thu Aug 10, 2023 6:38 am

Re: CGNAT IP range conflict between Starlink and Tailscale site-to-site VPN

Tue Apr 30, 2024 12:22 am

Belated thanks Larsa for your suggestions -- I ultimately ended up using ZeroTier and it was a quick and painless switch. I looked far and wide for other options, but couldn't find anything beyond the list you suggested.

Documenting some of the details here for future forum visitors:
  • We're using a HAP ax3 at the office, so I was able to move the site-to-site component of the VPN to ZeroTier and manage it directly through the routers -- the package for Mikrotiks made this really easy
  • Because we have some tech-averse users, I decided to keep Tailscale in place as a remote solution on the nodes serving applications, but I did disable subnet routing and some of the more advanced capabilities -- we're just using `tailscale up` with no options on those.
  • With subnet routing disabled on Tailscale, I could no longer point to the routers as the authoritative sources for the DNS records that folks are using to access apps via VPN. I put the necessary records on a non-authoritative cloud DNS server, and configured Tailscale to look there -- works just fine.
  • We're not doing anything with IPv6, so I wanted to try other approaches first
  • While Tailscale address pools let you tighten up the range of IPs that your Tailnet will use, they're all still in the CGNAT subnet, so while we might have been able to pull something kludgy together there with route priorities, we'd still fundamentally have the conflict with the Starlink routes to contend with.

Who is online

Users browsing this forum: Bing [Bot] and 16 guests