Authorization if you actually have public IP space

How is this handled, is there a little variable or hack to a conf I can give that says X.Y.Z.0/28 is actually also my IP space, instead of just RFC1918?

Also wondering how this would or will be handled with IPv6, I imagine most people using v6 also use public IP space, either natively or through something like tunnelbroker.

Is this something on the roadmap or considered not worth the effort?

Thanks!

Why not just set your routers DHCP server range to confirm to the standard that it should be in.
And not ask that others try to modify their software to be non-compliant.
In some places, it is illegal to operate using public IP space.

It alike to you asking for an exception to the law so that you can drive on the left in America.

1 Like

There is nothing to stop you from using a public ip space that you own for your servers. My fiber ISP gives me a /30 and then I have a public /28 routed to it. I run a voip server directly in that /28 range (secured behind a hardware firewall). Nothing illegal or crazy about it. @jbeez was just asking the question. If the answer from devs is "no" then that's the answer. To imply that there is something illegal about it is just pure hogwash.

3 Likes

Using public ip space that is licensed to a ISP will get you blacklisted. And is against the ISP TOS. There can be local laws that govern this. Know this for a fact, as the IT Consult company i used to work with for a few years, warned one client of this, they didn't believe us, and got internet service cutoff and fined. Sucks for them, cause Comcast Business was the only ISP in their business park.

Channels DVR is a product for Home users. It is not designed to be used in a business or corporate setting where the user has internal use public space IP addressing on servers for some reason.

I'm not advocating using a public IP space that does not belong to you. I am saying there is nothing wrong with using an IP space that you lease. Why would you automatically assume that his IP space that he is intending to use didn't belong to him?? If you refer to the OP title:
Authorization if you actually have public IP space
He's gong to have to deal with using channels as if it were remote all the time but there is absolutely nothing wrong with using your leased public IP space if you so choose.

3 Likes

The DVR requires auth when being accessed on a public network. This behavior is designed to be secure by default, so the internet cannot access your data. There is no way to change this at the moment and it is not considered high priority.

2 Likes

well there's always a hack ;p

I don't have a machine that uses a public ip address, but i'm pretty sure this'll work

just change the X.Y.Z.w to your server's public/real ip address, the X.Y.Z.0/28 to your real network -- and then copy-and-paste:

# the public/main ip address of the machine
P_ADDR=X.Y.Z.w
P_NET=X.Y.Z.0/28

# a private address that you dont need to remember
F_ADDR=172.16.12.14

modprobe dummy
ip link add eth1 type dummy
ip addr add $F_ADDR/32 dev eth1
ip link set eth1 up
echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -t nat -F
iptables -t nat -A PREROUTING  -p tcp -s $P_NET -d $P_ADDR --dport 8089 -j DNAT --to-destination $F_ADDR:8089
iptables -t nat -A INPUT       -p tcp -s $P_NET --dport 8089 -j SNAT --to-source $F_ADDR

needs to be ran on each boot.

2 Likes

I've been working in networking for over 25 years, I've ran a dialup ISP, installed T1 circuits, ds3 circuits, deployed vpn tunnels between branch offices to main locations, and I've certainly renumbered business networks who were wrongly using public IP space instead of RFC1918.

Not once did I say I was running in public IP space that I was unauthorized to use. Please stop making assumptions.

1 Like

Thanks, I actually have gotten it working with a nat, but the issue is that the channels DVR server client list just shows the firewall's IP as the client IP.

I've actually gotten this working several ways, I have it working right now using site2site wireguard tunnel. Not just channels but the native HDHomeRun app.

What I'm trying to do now is to figure out a way to do it without encryption and tunneling which isn't required IMO for streaming tv. Just tunneling may work too, the point of this exercise is for a remote site with a not very powerful networking device to still be functional for streaming.

When I say remote networks, I'm on fiber and so are the other sites, are close latency wise. I'm talking between 2ms and 8ms. One is not on fiber, its on xfinity and the latency is much higher, 20-30ms, still not high. Even this cable site can use HDHomeRun across a wireguard tunnel with socat redirecting the broadcast packets.

I tried to get the HDHomeRun tuner to work directly through public IP space with it on an rfc1918 range, but there is a single piece to that puzzle that I can't get working. When the HDHomeRun client sends a discovery packet, the payload of the returned packets include the rfc1918 address and the client never gets the lineup.json file.

I'm using PFSense firewall, which supports aliases,and hostnames in aliases. The sites are on dynamic IP space that doesn't change often, but stilll... they have dyndns hostnames, those are in the firewall aliases, and I reference them in the rules and the NAT statements so I can keep things pretty buttoned up, but like I said the one portion of the discovery process isn't working, and unless I can figure out a way to modify the payload of those 2 udp packets that return from the tuner on the fly I need to ditch that way. Also they don't support ipv6 on the tuner yet so thats out, as well as any method that nats or tunnels because it will always include its rf1918 in the payload directing the native client.

We are days away from 2023, latency is not as big of a thing, and with the advent of major ISPs pushing for v6 adoption NAT may not be strictly neccesary in many circumstances. All of the networks I'm dealing with right now have public IPv6 /56 or /64 blocks.

Thanks tmm1, I know we were discussing the auth portion on discord maybe a few months ago when I had some time to play with this. I got around this by natting incoming requests to WAN:8089 from specific external hosts to an IP on the firewall talking to channels server so it thought it was local.

How does this work with v6 address space though, my channels dvr server is assigned a publically routable v6 address, and the mechanism is still functioning. Is it for non-local v6 nets? Becuase my public space in the same /64 doesn't ask for authorization but in a different /64 it looks like it does.

With my solution, your DVR will always see the 172.16.12.14 ip address as the client ip. you'd just access it like normal, with the public ip address, not thinking at all about nat.

if you have another public ip address range that is separate from the /28 that the dvr is on, just add two more of those iptables lines with the different P_NET variables. or take the -s $P_NET out entirely to open it to the world and deal with it somewhere else like in a firewall.

1 Like

manage to get this to work with my 2 single public ips..
So the question i have is.. How can i get the 172.16.x.x reflect each device. Be nice if i can dhcp that so i can see who is connected and what devices they are.

not tested, but will probably work:

you can have a dedicated dummy ip address for each public ip address client.

so for each client, you'd do something like
ip link add 172.16.12.Y/32 dev eth1
(where Y is +1 of the last 172.16.12 that you used)

then use two iptables rules for each client:

iptables -t nat -A PREROUTING  -p tcp -s $P_NET -d *PUBLIC_ADDR_HERE* --dport 8089 -j DNAT --to-destination 172.16.12.*Y*:8089
iptables -t nat -A INPUT       -p tcp -s $P_NET -d *PUBLIC_ADDR_HERE* --dport 8089 -j SNAT --to-source 172.16.12.*Y*

that'll hook a one-to-one public ip address <-> private ip address association which'll let you see the individual clients instead of mapping it all through that single address like before.

this'll all be lost on reboot, so be sure to save them however your os likes it. ip addresses in /etc/network/interfaces, or /etc/sysconfig/network-scripts/ifcfg-eth1, and iptables in /etc/iptables/rules.v4 (after installing iptables-persistent from apt), or /etc/sysconfig/iptables. or just a script that runs after networking is finished.

I have not had luck here, but my plan B is in effect. I'm stringing an aerial fiber cable between the locations, that has no choice but to work since it'll be on the same lan :rofl:

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.