ARC connectivity issues on holiday let WiFi with Tailscale (ref#WEODRP)

Support
1

Network Setup

· I use a single personal router not provided by my ISP

ARC Status

· ARC is *Ready*

Describe the issue

I can connect to ARC via mobile data but not the WiFi of a holiday let. I have Tailscale running on the Roon server and the iPhone. No problems with mobile data, only connects to the cloud with through WiFi. Tailscale works for other applications through the WiFi, I can connect to other devices on the home network.

Describe your network setup

ISP Community Fibre (CGNAT), Ubiquity Dream Machine, Ubiquity 8 port router, hardwired Ethernet, ROCK OS running on NUC. Tailscale activated on Roon Server and tailscale endpoint on Synology server.

2

This may be caused because your home network and the local network share the same subnet range. This means iOS can’t always route correctly.

There’s little you can do about this until home, but choosing a less common subnet, e.g. 192.168.nnn.0 instead of 192.168.0.0, will help limit the likelihood.

3

Can confirm that home and local network share the same subnet range.

Just to be clear, you think that ARC via tailscale can’t distinguish between 192.168.1.13 on my home network and the same address on the local network?

4

I’m checking my software versions and I’ve just had my ROCK update to 2.67 (production) but my phone is running a later non production version

5

No, the phone can’t, and routes to the wrong destination.

6

Hi @Andy_Jones,

Just to confirm, your ARC instance and your server instance are mixed between the Early Access and the Production branch?

If you’ve still been able to connect at all in this circumstance, then the cross-branching likely isn’t the source of the issue.

I’d first check whether iOS has a “Fixed” Private WiFi Address assigned in your WiFi Details in the iOS settings for the holiday location WiFi. The phone might generate a new Mac every time it reconnects to the WiFi.

Is this holiday location an enterprise (managed) WiFi network, or do you have granular control over the router settings?

We’ll watch for your response and go from there. Thanks!

7

Yes, ARC is early Access, although maybe not latest and ROCK is latest production.

I do have a “Fixed” Private WiFi address on the network.

I can possibly access the router and WiFi but it’s not very practical to be fiddling in the settings of someone else’s WiFi.

I thought Tailscale used IPV6 to tunnel between pinholes.

8

OK, I have Tailscale running on the phone so it should be able to find my network.

9

Hello @Andy_Jones,

To add a bit more technical detail to what mjw explained: Tailscale creates a tunnel between your phone (100.x.x.x Tailscale address) and your ROCK, but ARC still needs to reach your server’s local IP (192.168.1.x). The problem is that when your phone is connected to a holiday WiFi that also uses 192.168.1.x, iOS sees that subnet as directly reachable locally and assigns it a lower routing metric than the Tailscale tunnel. So when ARC tries to connect to your ROCK at e.g. 192.168.1.13, iOS routes those packets to the holiday WiFi gateway instead of through the Tailscale tunnel - and naturally finds nothing there.

Mobile data works because your phone has no local 192.168.1.x network when on cellular, so all traffic for that range correctly goes through the Tailscale tunnel.

The only reliable long-term fix is to change your home subnet to something uncommon enough that it is unlikely to clash - 192.168.88.x, 172.16.x.x, or 10.x.x.x ranges work well. This can be done in your UniFi Dream Machine settings when you are back home.

10

Thank you for the detailed explanation. Is there any reason why Roon wouldn’t use the iPV6 option which would be unique. As far as I know tailscale implements iPV6 addresses.

11

ARC does support IPv6, but your holiday home router may not. Indeed, some ISP routers do not support IPv6 (dual stack) in the default configuration.

12

Hello @Andy_Jones,

To clarify: the issue here is not about whether Tailscale or the holiday router supports IPv6. The problem is purely about IPv4 subnet overlap between your home network and the holiday WiFi - both using 192.168.1.x.

Tailscale is just a tunnel - it does not change how iOS routes packets to destination IPs. When your phone sees 192.168.1.x is reachable locally via the holiday WiFi, it sends packets there directly instead of through the tunnel, regardless of what Tailscale or IPv6 support exists.

If your ISP provides a native IPv6 address to your home router and ARC can reach it over IPv6, then you would not need Tailscale at all - ARC would connect directly. But if you already need Tailscale (e.g. because you are behind CGNAT), IPv6 does not help with the subnet overlap problem since that is an IPv4 routing issue.

The simplest reliable fix remains changing your home subnet to something uncommon like 192.168.88.x when you get back.

13

Thanks, I get it. I will change it when I get back. It does seem like a pretty big problem with the way ARC is working though.

14

It has nothing to do with ARC. If you had, for example, a web server at home, it too would be unreachable because local and remote networks share the same subnet.

15

Hello @Andy_Jones,

Let me take a step back and walk through what is happening here in full detail, because this is a genuinely confusing situation - and, importantly, explain why it is not something ARC can influence.

The setup: your home network uses the 192.168.1.x range, and your Roon Server lives at an address in that range (192.168.1.13 in your example). Your Tailscale setup makes that home range reachable through the tunnel, so that when you’re away, packets addressed to 192.168.1.x are supposed to be carried home via Tailscale.

The collision: the holiday let’s WiFi also uses 192.168.1.x - it’s one of the most common default ranges in consumer routers, which is exactly what mjw flagged. So when your iPhone joins that WiFi, from the phone’s point of view there are now two different networks claiming to be 192.168.1.x: the WiFi it is physically connected to, and your home network behind the tunnel.

Why the phone picks the wrong one: which path a packet takes is decided by the operating system’s routing table, not by the app that sent it. When ARC asks to reach 192.168.1.13, iOS consults its routes, sees that the directly connected WiFi network matches that range, and hands the packet to the local WiFi - it never enters the Tailscale tunnel at all. Whatever sits at .13 on the holiday let’s network (if anything), it is not your Roon Server, so the connection fails. On mobile data there is no local 192.168.1.x network competing for that route - the tunnel is the only match, and everything works. That is precisely the split behavior you are seeing.

Why ARC can’t fix this: ARC, like any iOS app, hands its traffic to the operating system and has no say in which interface the OS routes it through. The routing decision happens below the application layer, in the network stack itself. This is also why it isn’t specific to ARC - any application trying to reach a home 192.168.1.x address from inside a colliding network fails in exactly the same way. The apps that do “work through Tailscale” for you work because they address your devices by their Tailscale IPs (the 100.x.y.z range) or MagicDNS names - a range deliberately chosen so it can never collide with any local network. With ARC’s current implementation, we cannot bypass this at the app level.

If you’d like to read further: Tailscale’s own documentation on subnet routing discusses this exact overlap problem (Subnet routers · Tailscale Docs), how routing decisions are made is covered here (Longest prefix match - Wikipedia), and this article explains why 192.168.0.x / 192.168.1.x collisions are so common (Private network - Wikipedia).

What you can actually do: as mjw suggested, once you’re home, change your home LAN to an uncommon range - for example 192.168.73.x. Collisions then become very unlikely, and this problem disappears at hotels, holiday lets and cafes alike. Until then, mobile data remains the reliable path.

I realize it’s an unsatisfying answer, but this is plain IP routing - and it bites every VPN product in the same way.

Thanks!

16

This is the answer I was looking for. I wish I had known about this limitation when I first set up ARC so perhaps I overlooked it or it could be included in instructions pertaining to ARC for future use.

17

Hi @Andy_Jones,

Thank you for your understanding. If you are able to change the subnet, please let us know whether everything works properly after that change.