Enabling port forwarding... but only for https?

Channels DVR Server
#1

I recently migrated my ChannelsDVR setup from a Windows machine to a RaspPi server (running in podman). I have almost everything setup that I can think of except for allowing remote streaming.

I did manually setup a port forwarding rule but then I quickly realized that connecting to that port from "outside" (my phone on LTE) would simply show me the admin homepage without requiring any logging in or anything.

It looks like the current setup is that both HTTP and HTTPS are served over a single port (I'm guessing the server sniffs the packet to see if it's supposed to be HTTPS). Is there any way to filter out HTTP from coming through my router and only doing authenticated queries? Otherwise... I REALLY don't feel comfortable with that forwarding rule.

#2

This simply is not true. You have to login to reach the server page, if you didn’t it just means your browser has it cookied.

If you don’t want to port forward then setup Tailscale for remote access.

1 Like
#3

(Screenshot removed by author)

#4

I tried to take a screenshot from private mode but... it came out all black (apparently a feature of all chrome browsers)

#5

Are you connecting to wifi inside.your network? If so you are likely being redirected via nat reflection.btw usually not a great idea to post your public ip in any forum. You have to authenticate before you are granted access to this page. But as others have said if this is bothering you, use tailscale.

#6

You're getting fooled somehow (likely as @slampman described). I'm in Portugal atm, and I tried to access my own static IP and Channels DVR port (while disconnected from Tailscale) in the way you describe and it was not possible.

In addition, since you posted your WAN IP (and in the interest of proving or disproving your concern), I tried your current IP:port combo from here and was greeted with same "This site can't be reached" message.

1 Like
#7

I am not connecting from wifi in my network. And as soon as I took that screenshot I turned off the port forwarding so I'm getting connection_refused as well now. If there's one thing infinitely worse than posting your IP address it's leaving an unencrypted unauthenticated open port of that nature...

I would prefer being able to use the Channels App if possible, from the look of Tailscale it was some kind of VPN system that likely wouldn't work without some additional software installation on the clients. I just need to know how to configure things properly, maybe manually setting the definition of "local network" inside of ChannelsDVR or something (there's a lot fewer "advanced settings" in here than I would have liked)

(apparently changing your public IP address is a bit more involved than power cycling your networking equipment... oh well)

#8

Yet your screenshot shows you were connected by WiFi. If you've uncovered a security hole in Channels DVR remote access, I salute you, as that would mean an emergency fix is required for everyone's benefit. However, I do not think that is the case here, as confirmed by me testing that my own remote access is not accessible in that manner -- as well as yours.

Much more likely in this case is that your router supports NAT reflection or hair-pinning, and that is resulting in your test being flawed. I've been in this situation myself, where it's my test that was to blame.

#9

Please go to Support -> Troubleshooting -> Submit Diagnostic Logs from the web interface of the DVR and let us know when it's been submitted so we can have a better idea of what was going on.

It's possible your router is not preserving the source IP when forwarding the port to your DVR.

#10

I got this error trying to upload:

There was an error submitting the diagnostic logs:

Put "https://s3.us-west-2.amazonaws.com/diagnostics.channelsdvr.cloud/53979b77-6580-484a-956c-aff35649f7a1/dvr.files?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA5BWMCXPFMBVC3OPV%2F20231222%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Date=20231222T191555Z&X-Amz-Expires=900&X-Amz-SignedHeaders=content-encoding%3Bcontent-type%3Bhost&X-Amz-Signature=40a6dbcb7d1baaa951e2a130027be9c4db9738800a9c400357c7e3c47ecb34d9": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Please check the local logs for more details and send an email to [email protected] to help resolve the issue.

#11

That normally happens when you are having network issues. Can you click the "Re-Run with Resource Intensive Tests" and try uploading again?

#12

should i just copy-paste the local logs into an email?

#13

local logs (or whatever that link gave me) have been emailed

#14

From the DVR system, if you try to ping s3.us-west-2.amazonaws.com do you see any packet loss or variable latency? It's confusing why you would have trouble contacting AWS systems.

#15

ah, think i can guess. I had expected that unplugging my internet had stopped a cloud backup system that was running for the last few days but... apparently it hadn't. And the destination is in us-west-2 as well.

#16

killed the backup. Logs uploaded as 1ab8e4e1-da7c-46b1-b6cf-be225d720353

#18

Your diagnostics show that you do not have remote access functioning right now. If you are able to connect remotely to your DVR from your phone while not on your home network, something else is being used that isn't the standard port forwarding that we enable.

1 Like
#19

I didn't really want to keep port forwarding on while my port was full-open so... no it's not open right now. Not until I can figure out what's going on here.

#20

I do see that the source IP for all of your requests is coming from 10.0.2.100. Are you running some sort of a proxy in front of your DVR?

If you run the DVR with host networking it should resolve the issue you were seeing.

#21

2023/12/22 09:17:49.378687 [HTTP] | 200 | 1.184596ms | 10.0.2.100 | GET "/dvr"

Requests at 9:17am appeared to be coming from a local IP and not the internet.

Are you using a reverse proxy?

What router do you have and how did you enable port forward?