Port forwarding

GotYour6

Dest is actually set to WAN not LAN

chpalmer

You might need UDP instead of TCP on one or two of those rules.. Depends on the camera.

GotYour6

I got lazy and use an old screenshot, here is what it looks like right now.

chpalmer

So what do your actual firewall rules look like?

Your NAT rules there actually overlap on the LAN side.. I don't believe Ive ever had the opportunity to try that..

GotYour6

WAN

LAN

chpalmer

Flip your two WAN rules around so the last one is above the other.. See if that makes a difference..

GotYour6

I worked directly with the server software (UniSight) company and the guys that wrote the mobile app for the better part of a day, we couldn't figure it out.

GotYour6

@chpalmer Well, that got me closer. I can actually get to the server from the app. But when I try to open one of the cameras to view it, I get an error that says channel unregistered, but now that is on the server software company.
I can't believe just fliping the rule was all it was. Thanks a million!!!!!

chpalmer

Rules are always parsed first from top down. I only use 1:1 NAT in my use cases around here so don't get to play with single/multiple port forwarding to often. But my belief is that having the first rule with your multiple ports on top was causing the box to somehow take control of port 8554 for its use and blocking the redirect rule.

Another way would be to make three port forwards and corresponding rules. 8000-8553 554/8554 8555-9000.

Im betting you actually do not need all those ports forwarded but until you get everything working you probably wont be able to trim them down to what is needed. Unless you can see it in the various cameras.. if more than one. My guess is one port per camera?

Grimeton

Are you testing from INSIDE the same network where the cameras are running?

If so, enable the NAT-reflection option that does NAT + PROXY.

I explained NAT-reflection in a different context here:

https://forum.netgate.com/topic/139457/transparently-intercept-and-redirect-dns-traffic-to-an-internal-dns/14

Cu