No live stream from "subnetted" camera when connected through VPN from outside

[MichlW]

Hi, I hope I can find a hint to solve a strange behavior:

My dockerized scrypted setup connects a RTSP camera located in an separate IoT Subnet (172.16.3.x) to HomeKit. That looks like the following:

Internet -> Router (with IPsec VPN) for local LAN (172.16.2.x) -> IoT gateway (OpenWRT) with subnet 172.16.3.x -> RTSP Camera

The Router has a route added to reach clients within the IoT subnet 172.16.3.x. When I am connected locally through WiFi everything works in my network and everything works in HomeKit, live stream, snapshots, etc...
Also when I am connected remotely from mobile net (LTE) and from other WiFi networks everything works as expected through iCloud because I use several Apple HomePods and an AppleTV.

The strange problem I have:

When I connect my iPhone through VPN to my local network, camera snapshots are working normally BUT the live stream of the camera in the Home app does not start anymore.

The router (a mainly in germany used AVM FRITZ!Box 7590) connects VPN client to the same network 172.16.2.x as any other network devices. I can reach the camera's admin panel also when connected through VPN and therefore I thought that the route added for the IoT subnet is enough for HomeKit to reach the camera as well.

Does anyone have an idea why the live stream cannot be started when connected through VPN?

[Unlearned6688]

did you ever solve this? having the same (seemingly) issue as you. I need to have a "VPN" on (it's just a proxy, not the full VPN usually) to proxy certain websites that are blocked (or censored), etc. in my country.

Funnily enough, the homekit camera feed loads while using a the wireguard client (just the completely normal, unmodded, unchanged one off the app store) with full VPN tunneling on -> except private/local IPs. But if I add these IPs to the proxy app on iOS, Shadowsocks is the one although others have given the same result, the feed does not load.

I have tried locally hosting a shadowsocks and just a http proxy (using the same wireguard VPN which, again, does load correctly via the app- but iOS (Apple, stupidly) doesn't allow per-app (as they like to call it) or per-domain, which I actually require, VPNing. For unknown reason. Google DOES allow it on Android and it works quite well), I have tried a remotely-hosted (paid, premium, otherwise working) http(s)/SOCK5 proxy, none of it works. I'm thinking this is something uniquely bad with Apple's software, specifically their networking side of things. There's absolutely no reason that if I have my phone proxying SOME domains/IPs (AND ZERO PRIVATE ONES) that it should effect non-selected IPs, especially private ones, and especially especially ones which I've forwarded via my router.

Apple is doing something somewhere in either iOS or their camera video networking that is overriding settings and thus causing things to be proxied or filtered in some way which should not be. Incredibly annoying.

I'm gonna keep playing with proxy settings and router settings today in hopes of a solution, but I'm losing hope quickly. If Google made better operating system without the Apple gimps I'd just switch to Android, but, alas.

[ciddi89]

Hmm no solution for this problem? I used Homebridge before and there it is not a problem. With scrypted it does not work. When I'm not logging into my local network I'm connected 24/7 via VPN, so it would be great if there was a solution for this. I've also tried different settings on my UDM Pro firewall, but it doesn't work.

[Unlearned6688]

My "solution" was to effectively not use a VPN at all on my home assistant (scrypted) IP.

i also have a UDM Pro.

best I can suggest is either use the fairly-recent VPN client support ubiquiti added (their wireguard support is buggy. The OVPN seems mostly ok) and put the scrypted/home assistant, etc. stuff on a VLAN which is not sent to the VPN at all. Route the rest of the traffic through the VPN.

You can also achieve other, more in depth and additional settings using the unifios utilities open source software that you can find by googling those words. The author is peacey. It hasn't been worked on in a while, but I can confirm split-vpn DOES work. I just finished setting it (back) up today actually. You can use the software to run at boot scripts to start wireguard tunnels and then add certain domains to tables to route through the VPN or not or even multiple VPNs. It's annoying to setup, but until Ubiquity finishes ironing bugs with their built in GUI Wireguard implementation... it's what we got.

it's annoying, but also one of those "set it and forget it for a long time" things, I guess

[ciddi89]

Hmm okay this is no solution for me. Some weeks ago I was trying different things with firewall rules etc. But it wasn't good enough. Stream needs to long and most time there was an timeout. But...

But for few days I changed on proxmox for my docker vm the processor to host mode and there was a new update of scrypted and since few days it works like a charm. No idea what exactly was the trigger now but the stream is fast and works every time on all of my iOS devices connected per VPN. Now I'm happy with it. :)

[gldn]

I think I have this issue as well. Using Tailscale I cannot reliably view live feed while away from home network. With Tailscale off, live feed loads within 5-10 seconds. On home WiFi, live feed loads within one second.

I was tearing my hair out and meticulously going through substream camera settings to see if it was the issue. Seems to be Tailscale.

[koush]

using Tailscale makes scrypted think its on the local network. unless you have adaptive bitrate feature via the NVR plugin, it won't automatically downgrade the connection when it fails to stream at local resolution.

[gldn]

Thank you for the confirmation. I suspected this was the issue so I’ll stop trying to fix it via settings adjustments.

[koush]

I'd consider putting Tailscale on a different subnet, and not listening to HomeKit mdns on that subnet.

[fongd]

I’m having a similar problem—while tunneling into my LAN from remote via Tailscale, I cannot get live streams of my UniFi cameras at all in the Home app. Turning off Tailscale and accessing those same feeds works instantly.

Here’s a Scrypted log capture from start to finish, from when my iPhone on LTE (connected to my LAN via Tailscale) tries to stream live video from my G4 Pro Doorbell (192.168.8.15 is my Scrypted server; 192.168.8.30 is my Apple TV serving as Home hub):

[G4 Doorbell Pro] addresses {
  sourceAddress: '192.168.8.15',
  sourceVideoPort: 47758,
  sourceAudioPort: 47462,
  targetAddress: '192.168.8.30',
  targetVidioPort: 60643,
  targetAudioPort: 64853
}

[G4 Doorbell Pro] handleStreamRequest {
  sessionID: '5e530a20-8f55-48d7-b13c-f0a3604de0ba',
  type: 'start',
  video: {
    codec: 0,
    profile: 1,
    level: 2,
    packetizationMode: 0,
    cvoId: undefined,
    width: 1280,
    height: 720,
    fps: 30,
    pt: 99,
    ssrc: 3113079081,
    max_bit_rate: 299,
    rtcp_interval: 0.5,
    mtu: 1378
  },
  audio: {
    codec: 'OPUS',
    channel: 1,
    bit_rate: 0,
    sample_rate: 24,
    packet_time: 60,
    pt: 110,
    ssrc: 3430443584,
    max_bit_rate: 24,
    rtcp_interval: 5,
    comfort_pt: 13,
    comfortNoiseEnabled: false
  }
}

[G4 Doorbell Pro] Will wait for initial RTCP packet. { isHomeHub: false, isLowBandwidth: true, hasHomeHub: true }

[G4 Doorbell Pro] { isLowBandwidth: true, isWatch: false, destination: 'remote' }

[G4 Doorbell Pro] Selected stream Medium

[G4 Doorbell Pro] sending prebuffer 2000

[G4 Doorbell Pro] { tool: 'scrypted', rtpSender: 'Scrypted' }

[G4 Doorbell Pro] Waiting for video RTCP packet before sending video.

[G4 Doorbell Pro] packet loss 1

[G4 Doorbell Pro] Received first video RTCP packet.

[G4 Doorbell Pro] rtsp/tcp h264

[G4 Doorbell Pro] a/v h264 opus found h264 opus

[G4 Doorbell Pro] rtsp/tcp opus

[G4 Doorbell Pro] Medium active rebroadcast clients: 1

[G4 Doorbell Pro] bypassing ffmpeg, perfect codecs

[G4 Doorbell Pro] received first video packet

[G4 Doorbell Pro] scanning for idr start found: 1

[G4 Doorbell Pro] received first audio packet

[G4 Doorbell Pro] packet loss 22

[G4 Doorbell Pro] scanning for idr start found: 1 28 24 7 8

[G4 Doorbell Pro] idr start found: 28 5

[G4 Doorbell Pro] packet loss 51

[G4 Doorbell Pro] packet loss 82

[G4 Doorbell Pro] packet loss 121

[G4 Doorbell Pro] packet loss 117

[G4 Doorbell Pro] packet loss 141

[G4 Doorbell Pro] packet loss 186

[G4 Doorbell Pro] packet loss 187

[G4 Doorbell Pro] packet loss 195

[G4 Doorbell Pro] packet loss 204

[G4 Doorbell Pro] packet loss 206

[G4 Doorbell Pro] packet loss 207

[G4 Doorbell Pro] packet loss 206

[G4 Doorbell Pro] packet loss 207

[G4 Doorbell Pro] packet loss 208

[G4 Doorbell Pro] packet loss 210

[G4 Doorbell Pro] packet loss 211

[G4 Doorbell Pro] packet loss 212

[G4 Doorbell Pro] packet loss 211

[G4 Doorbell Pro] packet loss 212

[G4 Doorbell Pro] packet loss 246

[G4 Doorbell Pro] packet loss 247

[G4 Doorbell Pro] packet loss 281

[G4 Doorbell Pro] packet loss 312

[G4 Doorbell Pro] packet loss 318

[G4 Doorbell Pro] packet loss 322

[G4 Doorbell Pro] packet loss 334

[G4 Doorbell Pro] packet loss 374

[G4 Doorbell Pro] packet loss 414

[G4 Doorbell Pro] packet loss 446

[G4 Doorbell Pro] packet loss 445

[G4 Doorbell Pro] packet loss 495

[G4 Doorbell Pro] handleStreamRequest { sessionID: '5e530a20-8f55-48d7-b13c-f0a3604de0ba', type: 'stop' }

[G4 Doorbell Pro] streaming session killed, duration: 61s

[G4 Doorbell Pro] Medium active rebroadcast clients: 0

Eventually the stream times out which is where the “session killed” message appears in the log.

Note that the stream is indeed recognized as “remote”. I wish I knew what IP is trying to connect where and to which ports that is causing a timeout error. I don’t have this problem if I just use plain old Wireguard or OpenVPN.