We help IT Professionals succeed at work.

Cannot configure Port Forwarding - help please...

Saxitalis
Saxitalis used Ask the Experts™
on
Hello Experts,

I am trying to access an IP Video camera on my private network from the Internet.

1. I have verified the camera can be accessed via a web page from the private LAN.
2. My IP camera is currently using port 80
3. I set up port forwarding in my DSL modem to access the IP Camera IP via Port 80.
4. I can verify the port is open using canyouseeme.org (If I remove the port forward in my modem, the route from canyouseeme.org fails)

When I try to access the IP camera from the internet by typing http//"MyPublicIP:80" the the browser times out.

So I believe I have port 80 open but I cannot access the IP camera on my local LAN from the Internet.

Does anyone know what may be going on here?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
nociSoftware Engineer
Distinguished Expert 2018

Commented:
Does the IP camera has it's default gateway pointing to your router?

Author

Commented:
Yes
nociSoftware Engineer
Distinguished Expert 2018

Commented:
Maybe you can test using a tool called curl. ( https://curl.haxx.se/ )

curl -h http://yourip/....
(with port forwarding enabled).

And may you can compare it to a  local access  attempt?...

Please not not a lot of routers can cope with accessing a  port forward port  from the inside of the modem.
"by typing http//"MyPublicIP:80""
Is this a typo?  It should be http://MyPublicIP:80
(replace MyPublicIP with your public IP address)

Author

Commented:
Yes typo - Have tried http://MyPublicIP:80 several times.
Top Expert 2016

Commented:
in your port forwarding did you set the local ip address the ip address of your camera?

Author

Commented:
Yes
Top Expert 2016

Commented:
you can access it via http://the local ip/ ?

Author

Commented:
yes from a pc on the LAN.
Pete LongTechnical Consultant

Commented:
Does you router have public management enabled on TCP port 80?

</P>

Author

Commented:
Hmm Don't know - I don't see this setting. The Router in my test environment is an Actiontec C3000A DSL Modem.

Would this setting be in security area you think?
A couple of other thoughts:

1)  Enable UDP as well as TCP in the port forwarding
2)  Change the port setting on the camera (port 8080, for example), change the port forwarding, and change the port you specify (http://PublicIpAddress:8080).  There may be some odd thing where your modem/router doesn't like to forward port 80.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
hence my request for curl -v http://localipaddress/ -L from the network, it will show redirects etc etc.
mbkitmgrOwener

Commented:
Some routers will have an issue with port forwarding port 80.

To get around this:
  1. Log into your CCTV systems and see if you can change the port to something other than 80 - eg 8080 or 8180
  2. Test internally by browsing to http://ipaddress_of_CCTV:8080
  3. if ok use port forwarding to forward that port to the CCTV system

P.S.  Change the default password to something complex, so that we dont see your site live streamed for all to see :(
I rather agree with mbkitmgr.  You likely don't want the incoming packets to be addressed to http://PublicIpAddress:80 but that may actually be OK if you have only one camera.  What if there were more?  

If it's possible, I'd approach it like this:
Outside in traffic addresses to http://PublicIpAddress:[portn] where portn might be 8080, 8081, etc.
Then, in the router, you do port forwarding like this:
http://PublicIpAddress:8081 forwarded to http://ipaddress_of_CCTV1:80
http://PublicIpAddress:8082 forwarded to http://ipaddress_of_CCTV2:80
http://PublicIpAddress:8083 forwarded to http://ipaddress_of_CCTV3:80
see?  All of the cameras can still use port 80 as long as the right packets are sent to them.  The right packets are determined by the router by virtue of the port number coming IN from the outside.
I guess you have, right now, but one camera but I hope this illustrates a key point.  
The incoming port numbers can be any likely port number (it is just an address extension after all).
Then the router needs to know:
"If I get traffic for port 8082 then I send it to ipaddress_of_CCTV2:80"

Then, just for completeness of understanding:
When a browser on a computer asks for a web page, the request goes to the gateway router with a port number to be responded to.  An extension to its LAN IP address if you will.
The router translates the IP address and port number to a new port number on the outgoing traffic to be responded to.  
The responder sends traffic back to the router public IP address with the port number it was given.
The router sees the port number (it's own public IP address is no longer important) and translates that into an internal IP address and a corresponding port number for that data stream.
The internal computer gets the packets and, seeing the port number, sends the packets to the browser, the camera, etc.

There are a lot of different cameras out there with different kinks in how they do things re the camera, web support, etc.
You didn't mention the make and model did you?  That could cause better suggestions.
David FavorFractional CTO
Distinguished Expert 2018

Commented:
Keep in mind many ISPs don't allow what you're trying to do.

In other words, they don't allow port forwarding... well... doing port forwarding the simple way...

Many ISPs block normal TCP/UDP connections initiated from an external IP to your ISP assigned IP.

Another way to say this is listeners are blocked.

The easy way around this is to run an ssh tunnel. You must run ssh, to block your ISP seeing what you're doing, as some ISPs are now checking packets to block plain text reverse tunnel connections.

What you'll do is run ssh from your local machine, connecting your local IP:port to your remote IP:port on your https://canyouseeme.org domain to allow access to your local camera.

Tip: If you have one camera, this will be fairly easy to setup running Windows.

If you have many cameras, coming online + going offline, trying to do this Windows will likely leave you sobbing in a fetal position in a dark corner somewhere.

If you're running a complex multi-camera setup, use Linux on your local site + remote side, to reduce your setup + maintenance time.
David FavorFractional CTO
Distinguished Expert 2018

Commented:
https://www.howtoforge.com/reverse-ssh-tunneling provides a good overview of how to setup a reverse ssh tunnel, to externalize a local IP:port onto any remote IP:port to avoid ISP blocking.
nociSoftware Engineer
Distinguished Expert 2018

Commented:
It isn't exactly ISP's do / don't allow it. It's more about ISP's moving to CGNAT where the NAT isn't on your modem, but rather in the DC of the ISP. Thus creating higher densities of user / address.   NAT is bad, CGNAT is the Superlative of BAD. (NAT without portforward).

Author

Commented:
Hello Guys - sorry for the late reply (Business trip got in the way)…

Fred Marshal - thanks for advice - I will try using different ports to forward as you suggest. Camera is a 3x Zoom, Rugged HD IP Camera MZ-HD34-2 https://ivcco.com/video-cameras/#stainless

David Favor/All - If I set up an SSL VPN... Will this get around an ISP "not allowing" port forwarding?

Also - Do you still need to specify a Public IP if a VPN is used?

Thanks!
nociSoftware Engineer
Distinguished Expert 2018

Commented:
Depends where the VPN terminates. If the VPN terminates on your network then no you won't need portforward.
Port forward is to compensate for NAT lying about addresses from internal networks.
Fractional CTO
Distinguished Expert 2018
Commented:
ISP example that comes to mind.

Recently, working with Spectrum (use to be Time Warner Cable) many oddball problems were occurring.

Reading the fine print of their TOS, they say clearly the block all listening processes.

So in this case, setting up listening local ports could easily be exported to public IP... till the next time a Spectrum listening port scan was done + all listening ports blocked.

So the behavior was... All code working, till all code just stopped working.

The solution for ISPs with this type of tech is to use a reverse proxy, where you export the listener by connecting your local port first to some public machine.

All this depends on your ISP TOS. Also keep in mind, even if your ISP TOS today allows this, if your ISP changes their TOS or you switch ISPs, then you can hit the same problem.

This being the case, I use reverse proxies (ssh tunnels) for all this type of work now, as using an ssh tunnel works 100% of the time, independent of ISP nonsense.

Author

Commented:
Thanks all !