Skip to main content

Remote Access

ClaudeAuthored by Claude · Last updated AI generated documentation written by reading the source code
cloud services

Remote Access connects your Cardinal apps to your self-hosted Cardinal Media Server from anywhere, without manual port forwarding or reverse-proxy setup. It is rolling out as a closed beta; enabling it on your Media Server files a request that must be approved before the feature activates.

When Remote Access is enabled, your apps receive a list of connection candidates and try them in order: a direct connection on your local network first, then a direct connection over the internet, then a relayed connection through Cardinal's servers as the fallback. All candidates use hostnames under connect.cardinalapps.host so that the connection is always encrypted with a valid TLS certificate — including connections that never leave your home network.

Troubleshooting​

Troubleshoot issues with DNS rebinding protection​

The local (LAN) candidates are public DNS names that intentionally resolve to private IP addresses. For example, if your Media Server's LAN address is 192.168.1.40, apps on the same network connect to a hostname like:

192-168-1-40.abc123.connect.cardinalapps.host  →  192.168.1.40

Some routers and DNS resolvers ship with DNS rebinding protection, a security feature that blocks public DNS names from resolving to private addresses. Rebinding protection cannot tell this legitimate answer apart from an attack, so it silently discards it.

Symptoms​

  • Apps on the same network as the Media Server fall back to relayed or internet connections instead of connecting locally (slower streams, unnecessary internet traffic).
  • Local playback fails entirely while Remote Access works fine when you are away from home.
  • nslookup 192-168-1-40.abc123.connect.cardinalapps.host (using your own hostname) returns no answer on your network, but returns the private address on another network or against a public resolver such as 1.1.1.1.

Allow connect.cardinalapps.host in your resolver​

The fix is to whitelist connect.cardinalapps.host in whichever device answers DNS on your network — usually your router, or a local DNS server such as Pi-hole. This creates a narrow exception: only names under connect.cardinalapps.host may resolve to private addresses, and rebinding protection stays active for everything else.

dnsmasq (OpenWrt, Pi-hole, many routers)​

Add to the dnsmasq configuration:

rebind-domain-ok=/connect.cardinalapps.host/

On OpenWrt this can be set in /etc/config/dhcp:

config dnsmasq
    list rebind_domain 'connect.cardinalapps.host'

Unbound (pfSense, OPNsense)​

Add to the custom Unbound options (pfSense: Services → DNS Resolver → Custom options; OPNsense: Services → Unbound DNS → Custom options):

server:
    private-domain: "connect.cardinalapps.host"

AVM FRITZ!Box​

Under Home Network → Network → Network Settings → DNS Rebind Protection, add connect.cardinalapps.host to the host name exceptions.

Other routers​

Look for a setting named "DNS rebind protection", "rebind domain exceptions", or similar, and add connect.cardinalapps.host as an exception. If the setting cannot be scoped to a domain, an alternative is to use a local DNS server (such as Pi-hole or AdGuard Home) that supports per-domain exceptions, or to configure your devices to use a public resolver.

Was this article helpful?