Selective routing for Remote DVR dynamic IP update when using TVE tuners

ryanroosa · August 17, 2019, 6:27pm

Howdy!

This isn't so much a query as it is an 'FYI' for anyone in a specific ISP situation as myself. Hopefully it will help someone:

I am on a cellular ISP behind CGNAT so in order to make Remote DVR functionality work, I have to route all Remote DVR traffic through a VPN in order to get a public IP where port 8089 can be forwarded. This wasn't too complex to get working but I did have to force the gateway for the local LAN IP of the Channels DVR server to use the VPN public IP and not my CGNAT'ed cellular public IP. The only trouble with this is that for low latency access I have rolled my own OpenVPN server using a local VPS provider which has transfer bandwidth caps. When selecting my VPN gateway for Channels DVR to use when updating it's Remote DVR IP (essentially a DDNS service run via the FancyBits 'my.channelsdvr.net' subdomain) it also had the undesirable side effect of making it use the VPN connection for initiating TV Everywhere (TVE) stream downloads when serving my local LAN FireSticks or for re-upload when transcoding to remote, mobile devices. This heavily cut into the VPS transfer caps which was undesirable.

In order to remedy this I setup some packet captures and found out that the Remote DVR DDNS IP update function essentially talks to one of two CloudFlare IPs used by FancyBits, presently 104.24.112.77 and 104.24.113.77. With this information I was able to create an alias for those IPs and a policy based route on my router's firewall (I use PFSense) which forces any IP updates from the Remote DVR out of the VPN while letting all other TVE stream targets download using my local cellular gateway (and thus not eating into my VPS transfer limits). The rule looks like this for anyone who cares:

Rule Action: Pass/Allow
Source Protocol: IPv4
Source Network: LAN
Source Host: [Channels DVR IP]
Destination: [104.24.11x.77 IPs Alias]
Gateway: [VPN Interface GW]

Obviously if you use IPv6 in your setup you would need to add aliases/rules for those addresses too but I only use IPv4 on my LAN at the moment so I didn't mess with that.

This is probably useless info to most but I figured it might help someone out

As an aside, it might be nice to have an 'Advanced' feature to the Remote DVR setting so that when 'Manual' port forward option is selected, it allows for a manual IP address entry too. This would remove the need for any DDNS and policy based routing hacks when using this kind of setup. But I realize this is an edge case so I understand why the developers would not want to add this feature and risk confusing most folks who play with the Remote DVR setup options.

tmm1 · August 17, 2019, 9:42pm

Thanks for sharing.

The DDNS host is community.getchannels.com which is hosted at Cloudflare so if you can do host based routing that might be more robust in the face of IP changes at Cloudflare.

ryanroosa · August 17, 2019, 9:43pm

Thank you! This is helpful

resjus30 · August 3, 2020, 7:59am

This post is super helpful. I think I've figured out that my issue with setting up remote access has to do with my AT&T Cellular LTE Strict NAT; the IP on my hotspot does not match my public IP. That said, how do you “force the gateway for the local LAN IP of the Channels DVR server to use the VPN public IP and not my CGNAT'ed cellular public IP”? Also, do you think a VPN solution will work for me? Can you recommend a paid VPN solution as I don’t wish to set up a VPS? Thanks so much!

resjus30 · August 4, 2020, 8:25am

Updating on my progress and hoping for some help in forcing my Channels DVR Server gateway to use the VPN public IP instead of the CGNAT cellular IP.

2012 Mac mini runs macOS Mojave 10.14.6 and Channels DVR Server 2020.07.30.2221. It is connected via Ethernet to the WAN port of my access point (Gl.iNet Cirrus model GL-AP1300LTE). I've gotten around the lack of a GPS to authenticate Locast region by using an AT Command that forces the access point's built-in Quectel EC25 4G LTE modem to connect to an AT&T cellular tower that registers my local area (in my case, Band 12, but your case may differ so use Cellmapper MCC 310 to find the best towers for your area).

I purchased a 12+3 month promotional subscription to ExpressVPN and issued an OpenVPN manual configuration file to the access point. The Gl.iNet software (versions 3.022 and later) feature VPN Policies. I configured a "Domain/IP" policy and "Do not use VPN for the following" rule for community.getchannels.com. I believe this will address latency issues by split tunneling that domain.

I still am having trouble with:

IP ENDPOINT FIX. Forcing my access point to use the VPN public IP and not the CGNAT cellular public IP. I gave Dynu IP Update Client free DDNS a shot with ExpressVPN enabled on my router / gateway, but the my real AT&T dynamic IP is shown, not the ExpressVPN public IP. Is there a a command that I can add to the OpenVPN config file, or do I need to mess around with IP tables? I'm not sure how to get this working.
PORT FORWARDING. I assume that 8089 port forwarding that is specified on my router rules for my Mac mini client IP will work once I get the VPN public IP endpoint specified on my access point.

I appreciate any ideas or guidance. Thank you, Channels Community.

ryanroosa · September 17, 2020, 4:24pm

I've very sorry for the month and a half delay in reply, I honestly just have not had a lot of time to spend on the Channels forums lately. I hope you made some progress. As you have probably found out by now, band locking does not really help with obtaining a geographically appropriate IP since this is handled by the APN proxy AT&T decides to route you out of and in many cases this appears to be done in round-robin fashion based on their server load so, while an attach to specific band on a tower one time may get you a localized IP for your region after a reboot you may find you're routed out of another region.

For consistency you would need to get a locally hosted VPS or buddy with spare bandwidth willing to host a Raspberry Pi to run a VPN server (WireGuard or OpenVPN). Be aware that the former VPS suggestion may give you an IP address in a data center block that Netflix/Hulu etc. block as part of their VPN detection. Your existing provider (ExpressVPN) may offer 'streaming' IPs or residential IPs to get around this but they may not be local to your region so may not give you what you need for Locast which is why I have made the suggestion of a locally hosted VPS or RPi.

For your "IP ENDPOINT FIX" query, basically the setup boils down to split tunnel routing on the router side so that the appropriate gateway is used on egress. I use pfSense and accomplish this with policy based routes in the firewall but this can be done in OpenWRT firewall (iptables) as well. You are in luck that there are trailblazers ahead of you that have created OpenWRT packages to help with this, see here:

github.com

stangri/openwrt_packages/blob/master/vpn-policy-routing/files/README.md

# VPN Policy-Based Routing

[![HitCount](http://hits.dwyl.com/stangri/openwrt/vpn-policy-routing.svg)](http://hits.dwyl.com/stangri/openwrt/vpn-policy-routing)

## Description

This service allows you to define rules (policies) for routing traffic via WAN or your L2TP, Openconnect, OpenVPN, PPTP or Wireguard tunnels. Policies can be set based on any combination of local/remote ports, local/remote IPv4 or IPv6 addresses/subnets or domains. This service supersedes the ```VPN Bypass``` available on [GitHub](https://github.com/openwrt/packages/blob/master/net/vpnbypass/files/README.md)/[jsDelivr](https://cdn.jsdelivr.net/gh/openwrt/packages@master/net/vpnbypass/files/README.md) service, by supporting IPv6 and by allowing you to set explicit rules not just for WAN interface (bypassing OpenVPN tunnel), but for L2TP, Openconnect, OpenVPN, PPTP and Wireguard tunnels as well.

## Features

### Gateways/Tunnels

- Any policy can target either WAN or a VPN tunnel interface.
- L2TP tunnels supported (with protocol names l2tp\*).
- Openconnect tunnels supported (with protocol names openconnect\*).
- OpenVPN tunnels supported (with device names tun\* or tap\*).<sup>[1](#footnote1)</sup> <sup>[2](#footnote2)</sup>
- PPTP tunnels supported (with protocol names pptp\*).
- Wireguard tunnels supported (with protocol names wireguard\*).

### IPv4/IPv6/Port-Based Policies

This file has been truncated. show original

At a high level you would create rules yourself, or with the help of the packages above, which would direct devices in your AP's subnet (or specific device IPs if you wanted to be more granular) to use the VPN connection as their gateway instead of your AT&T connection. In pfSense my firewall rule looks like this, but will obviously look different in OpenWRT (I use aliases for easier reading of my firewall rules which is also defined below):

For your "PORT FORWARDING" query, yes you would forward 8089 coming in from your VPN to your Channels server local IP. In pfSense my forwarding rule looks like this, but will obviously look different in OpenWRT:

As was already mentioned rightfully by @tmm1 in his earlier reply, using the hostname instead of specific CloudFlare IPs will be more robust in case more IPs are added/changed in CloudFlare for 'community.getchannels.com' (I'm simply lazy and haven't gone back to update my rules to route by hostname).

I hope this was helpful for you or anyone else coming across this thread.

resjus30 · January 14, 2024, 4:51am

Following up on this thread as I just noticed a Tailscale setting is now offered in the Channels DVR Settings > General page. I haven’t tried this, but I’m curious if any other CGNAT folks have given Tailscale integration a shot! NEW: DVR Server + Tailscale integration, for easier Away from Home access (Experimental)