Remote Access trouble when using 1:1 NAT

Channels DVR Server
#1

I have a block of static public IP addresses with my AT&T Fiber service. I hand them out via 1:1 NAT on my pfsense firewall. For various reasons, I have one assigned to the desktop pc running Channels DVR. This has seemed to cause a decent amount of instability with remote access. Sometimes it works, other times it does not.

When I go to the troubleshooting page, remote access has a yellow triangle with an exclamation point and says:
Outgoing connections are coming from (The 1:1 NAT assigned public IP) but the external IP of the router is (Firewall's main external IP)

Every time I am away and the Channels DVR app says it cannot connect, I can browse to the 1:1 NAT IP address using port 8089

Any other application and website I've used only sees and cares about the assigned 1:1 NAT IP address and doesn't see or doesn't care about the firewall's external IP.

What can I do to get it so remote access is stable with this configuration?

#2

I know how to handle this with a proper statement in my pf.conf, but I'm not sure how much the pfSense folks have deviated from the true pf to know issues may manifest. What do you pf rules look like involving either your DVR server, or its port?

#3

I don't have any rules setup, other than the 1:1 NAT assignment.

Every single time I get the error that Channels cannot connect, I can go to the browser and browse to the IP with :8089 and get the web UI - This leads me to belive the traffic is freely flowing on that IP and port are open and passing traffic as they should.

#4

image
image1284×1845 89.3 KB

This is what I see, and as mentioned I can go right to the address bar and type in {IP Address}:8089 and get right into the WebUI every single time.

#5

I added a rule on the WAN to pass all traffic for the 1:1 NAT IP at port 8089

I still got the same message about the server could not be reached.

1 Like
#6

I can connect to both the admin page and remotely through the client apps with Remote Access disabled. Don't use my.channelsdvr.net. Just connect to the public IP at port 8089 (if you have the forwarded). As for the apps, I just connect away from home and authorize access.

But I have an internal network using regular NAT. Public IP is the modem assigned IP going to router. router does port forwarding and NAT.

So why do you need multiple public IP? You just need 1 public IP. And NAT that to the various addresses on your internal network.

#7

I'm sorry, but you keep stating things you are doing, without offering any details. Which version of pfSense are you using, and what explicitly is your pass rule? Without any details, no one can even begin to offer support.

1 Like
#8

image
image2392×827 155 KB

image
image2778×1284 261 KB

PFSense is on 2.6.0 which it reports is up to date and I have attached the rule I setup for inbound traffic on 8089 for this public IP

The scratched out destination is the static public ip.

1 Like
#10

I run multiple networks from home and also host a web server and exchange mail server all for domains I own. Certain ports are in use externally (443 & 80 especially) more than a few times on my network. I prefer to have different public ip addresses assigned for those purposes as well as for different network segments so devices like my robo-vacuum and light switches come from a completely different public IP address than my computers. I decided to assign one to the box that runs channels to easier identify the traffic going to/from that box and because it better fits the overall network topology.

My problem happens when I go to authorize access to the apps away from home. It tells me it can’t reach the server (even though I can reach the web ui)

#11

image
image1284×2597 146 KB

The 1:1 NAT entry, mapping the static public ip to the internal ip of the box.

#12

Yeah, the apps must be trying to connect to the wrong one of your public IPs, instead of the one where you are doing the 1:1 NAT. You either will need to change your setup, possibly by doing the NAT on the pub ip that channels is trying to use, or need to contact the devs and ask them to set up your remote to always use the specific public ip where you are doing the 1:1 NAT. I have seen @tmm do this for others before. But if your public IPs aren't static, it probably isn't worth it bc you will need to do it again when the pub IP changes.

#13

I'm sorry, but you have a redacted screenshot. What is the actual rule causing issues? Perhaps maybe some output frompfctl stating what its internal rules actually are might help, too.

#14

This was my thought. My public ip block is static (including the one I assigned to channels) so a static mapping would be excellent. I suspect channels is trying to use the firewall’s public ip which is not available for me to assign as it is where my ISP directs traffic for the static block.

#15

I only blocked out the public IP address. I suspect the issue is on the channels side since I can access port 8089 through a browser 100% of the time. I can definitely be wrong though so I can share anything that will help trace it down. I’ll have to take a look at this, I’m mostly familiar with the web GUI.

#16

Did you check the DVR logs maybe your certificate is bad.

#17

I had not but I just looked, the log goes back to 2pm today and I don’t see anything about the certificate.

#18

Can you bring up the web page then click on support then troubleshoot see if you have any errors ... It should look like this.

image
image447×517 29.4 KB

#19

image
image1284×2778 138 KB

#20

I suggest in that trouble shooting area you submit the logs and contact support like the instructions say.

#21

Your rules look a bit off. In pfsense you have to declare the 1:1 nat which you did. However you also need a fireall rule on the wan side that opens 8089TCP to the internal address NOT the wan address. Seems backwards and feels funny to declare a 10.x address on the wan side of a the firewall but thats how it works.

Ive got a /28 public range and I dont have channels on a 1:1 but i have other servers on them.

Then just make sure that your external acces is configured in channels for manual and not automatic.