Can't access Hikvsion DS-7108N-SN/P from the Internet (WAN)

[tmazid]

Hi to All you experts on this forum,
I've solved a bricked Hikvision camera on this forum and I think its great, so keep up the good work. I've almost got my CCTV System up and running ecept for the fact that I can't access it remotely, so need some help please.

I have a Hikvision DS-7108N-SN/P Chinese version (using firmware v3.0.10 build 141201) connected to 4 Hikvision cameras.

Everything on my LAN appears to be working fine, which is great and I am now trying to access this remotely while I'm out and about.

I have a Virgin SuperHub and the port forwardig features are not great to be honest, so I've setup forwarding to the NVR Server Port only on Port 8000 (the default - so that I can test)

I can telnet to the internal Server port of the NVR on the LAN without any problems but unable to telnet from the WAN. If I try and access it via iVMS-4500 app it simply reports "Connection failed" but I can use the same app internally and works fine.

So what is the problem?:sad:

Within Network Settings on the NVR, should UPnp be enabled or disabled?

Also Port Mapping Mode, should it be on Auto or Manual, if its on Auto do I have to have Port forwarding rules on the router for these external ports?

Should the External IP Address within the Port Mapping, have my External IP Address, becuase at the moment it just reports 0.0.0.0.

Do I need to configure the individual cameras in any way, to get this to work or is that not relevant.

Can anyone help please?

Thanks

 

[alastairstevenson]

First of all go back to basics and check if you have correctly poked a pinhole in your router firewall by checking what ports are open from the big bad internet.
Lots of services to check this out for you - but have a go with https://www.grc.com/x/ne.dll?bh0bkyd2

 

[fenderman]

Disable upnp and port mapping..http://oversea-download.hikvision.com/uploadfile/doc/20140512/UPnP vs PortForwarding.pdf

 

[tmazid]

Thanks alastairstevenson, I just tried the link you sent me, so thanks for that. This is the result, is appears that the port maybe blocked, but its definitely set to forward on my router. I also tested forwarding port 8081 to a small webcam I have and I can access it from the WAN, which is why I'm thinking its the NVR and not the router but I could be wrong?

[FONT=Verdana,Arial,Helvetica,Sans-Serif,MS Sans Serif][SIZE=-1]----------------------------------------------------------------------

GRC Port Authority Report created on UTC: 2015-06-22 at 23:09:57

Results from probe of port: 8000

0 Ports Open
0 Ports Closed
1 Ports Stealth
---------------------
1 Ports Tested

THE PORT tested was found to be: STEALTH.

TruStealth: PASSED - ALL tested ports were STEALTH,
- NO unsolicited packets were received,
- NO Ping reply (ICMP Echo) was received.

[FONT=Verdana,Arial,Helvetica,Sans-Serif,MS Sans Serif]Thanks, maybe I should contact Virgin Media...?
[/FONT][/SIZE][/FONT]

 

[tmazid]

Thanks fenderman for the link, I'll give it a go (disabling UPnP on the NVR and Cameras) and get back to you with the outcome. Thanks.

 

[tmazid]

Hi fenderman, I've disabled UPnP and Port Mapping but I'm still unable to access the NVR Server Port remotely, I've been on the phone to VirginMedia and they say that it should work if I've configured the SuperHub to forward Port 8000 to the internal address, which I have, also the port checker URL seems to indicate its blocked. Also, I'm not sure if this is related, but my cameras are connected directly to the Ports on the back of the NVR (IP: 192.168.0.10) using the PoE ports and get assigned an IP address (192.168.254.x), which I'm unable to access directly from the LAN. Should I be able to access the camera's from the LAN? I'm unable to select DHCP on the NVR(as its greyed out) and I'm not sure if this is causing routing problems to my cameras.

Any advice would be gratefully apprecaited.

Thanks

 

[alastairstevenson]

Unless you have the 'virtual host' feature available and enabled (Advanced Network settings I think) you will have to resort to one of a couple of tricks to access the cameras on their separate network segment from the LAN. Certainly possible. But let's not complicate things just yet, as it's the NVR you're trying to access from the internet.

If you have confirmed that from a PC on your LAN, you can establish a connection to the NVR with 'telnet <NVR IP address> 8000' then there is a listening service on the NVR that you've confirmed is accessible.
The NVR needs to be able to communicate to the internet, so the default gateway must be set correctly with your router/gateway IP address.
If you also have the DNS set as your router/gateway, you could confirm full name resolution and connectivity by pinging an external site by name, or by IP address eg:

dvrdvs login: root
Password:

BusyBox v1.16.1 (2014-05-19 09:41:10 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
can not change to guest!
[root@dvrdvs /] # ping bbc.co.uk
PING bbc.co.uk (212.58.246.104): 56 data bytes
64 bytes from 212.58.246.104: seq=0 ttl=54 time=30.454 ms
64 bytes from 212.58.246.104: seq=1 ttl=54 time=30.814 ms
64 bytes from 212.58.246.104: seq=2 ttl=54 time=30.668 ms
64 bytes from 212.58.246.104: seq=3 ttl=54 time=30.428 ms
^C
--- bbc.co.uk ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 30.428/30.591/30.814 ms
[root@dvrdvs /] # ping 212.58.246.104
PING 212.58.246.104 (212.58.246.104): 56 data bytes
64 bytes from 212.58.246.104: seq=0 ttl=54 time=41.034 ms
64 bytes from 212.58.246.104: seq=1 ttl=54 time=30.177 ms
64 bytes from 212.58.246.104: seq=2 ttl=54 time=30.513 ms
^C
--- 212.58.246.104 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 30.177/33.908/41.034 ms
[root@dvrdvs /] #

It looks like what you need to focus on is the 'port forwarding'. Your check shows that it is not working - to 8000, if that's all you tried.
But presumably you have mapped the port 8000 to something else to add a bit of obscurity to what is actually a somewhat risky thing to do with your LAN - but that's another subject ...
Check out the full range of ports using the Shields Up! service. It doesn't take long.

 

[tmazid]

Hi Alastair, thanks for your comment.

I think you've hit the nail on the head. I did exactly what you suggested and realised that I couldn't access an external address (www.bbc.co.uk) from the NVR, which is a problem. So I checked the DNS Settings on the NVR and it was blank but I couldn't add anything as it was greyed out or disabled, should it be? The default gateway is my router IP address. could I add the DNS entry via telnet? Why is it greyed out?

Thanks

 

[alastairstevenson]

You don't actually need the DNS - but you do need the gateway / connectivity.
So if you can ping an external site by IP address that should be OK.
Did Shields Up! spot your webcam port?

 

[tmazid]

Nope, I tried pinging the bbc.co.uk IP address 212.58.244.69 which failed with Network unreachable, although I can ping the router and other devices on the LAN without a problem. I also noticed that I wasn't able to select enable DHCP on the NVR, just to see if that would work, but when I click on Save, I get Parameter Error.

I also did try Shields Up and it couldn't find the NVR on Port 8000 (status - Stealth), but did find another webcam on another Port which I also tested and I can access from the web, so it appears that port forwarding is working but since the NVR can't get out to the internet (i.e. can't ping externally) that's probably why I can reach port 8000 from WAN either.

Is there a problem with the firmware on the NVR (which is chinese), should I try another firmware version which is English? What should I try next please?

Thanks, I really appreciate your help.

 

[alastairstevenson]

Nope, I tried pinging the bbc.co.uk IP address 212.58.244.69 which failed with Network unreachable

OK, that will stop any external access, even if your port forwarding is correct, which it likely is.

Does your network configuration definitely have the 'IPv4 default gateway' set to the IP address of your router/gateway?

At the NVR command line, check the output of these 2 commands is similar to below:

dvrdvs login: root
Password:

BusyBox v1.16.1 (2014-05-19 09:41:10 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
can not change to guest!
[root@dvrdvs /] # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
192.168.254.0 * 255.255.255.0 U 0 0 0 eth0
224.0.0.0 * 240.0.0.0 U 0 0 0 eth1
[root@dvrdvs /] # cat /etc/resolv.conf
nameserver 192.168.1.1
[root@dvrdvs /] #

 

[tmazid]

Yep, I definitely have the default gateway set to the router, I've attached the output of the telnet session and also the network config image.

What do you think is wrong?

 

[tmazid]

could I create the resolv.conf file with the correct info? Also, could I add a new route?

 

[alastairstevenson]

Well that's an odd inconsistency. Default GW shows in web admin, but not with the route command. Sounds like the NVR config has got a bit tangled.
Have you customised the PoE IP address range? And is 172.16.0.5 definitely the LAN port of the NVR?

Here is something that may be worth trying - before suggesting a reset back to defaults, which could do all sorts of unwanted things.

At the telnet prompt, first list the routing table, then add YOUR LAN default gateway, then check it got added.
Then see if connectivity is how it should be - ping an external site by IP address.
Then - in the web admin Network configuration screen, refresh the browser page and click the Save button without changing what's on the screen.
Type 'reboot' on the command line.
After the restart, check connectivity again at the command line.

dvrdvs login: root
Password:

BusyBox v1.16.1 (2015-02-10 11:41:13 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
psh: applet not found
can not change to guest!
[root@dvrdvs /] #
[root@dvrdvs /] #
[root@dvrdvs /] # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
[root@dvrdvs /] # ping 212.58.244.20
PING 212.58.244.20 (212.58.244.20): 56 data bytes
ping: sendto: Network is unreachable
[root@dvrdvs /] # route add default gw 192.168.1.1
[root@dvrdvs /] # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
[root@dvrdvs /] # ping 212.58.244.20
PING 212.58.244.20 (212.58.244.20): 56 data bytes
64 bytes from 212.58.244.20: seq=0 ttl=53 time=31.597 ms
64 bytes from 212.58.244.20: seq=1 ttl=53 time=31.737 ms
64 bytes from 212.58.244.20: seq=2 ttl=53 time=31.161 ms
64 bytes from 212.58.244.20: seq=3 ttl=53 time=31.767 ms
^C
--- 212.58.244.20 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 31.161/31.565/31.767 ms
[root@dvrdvs /] #

 

[tmazid]

Yes, definitely weird!

Yes, the NVR LAN port is 172.16.0.5 and the PoE IP range is 172.16.1.x and the router is 172.16.0.1.



I've added the default gateway as you suggested via telnet and it has appeared in the routing table and I can now ping an external IP address, yippee. I got so excited that I tested external access to the NVR by opening the port on the router and that works as well. Yippee!!



Alastair you’re a genius, need to buy you a drink.



Now, I also tested your theory about the web admin page Network Configuration screen and pressed the Save button and performed a reboot from the telnet command line.



When the NVR came back up after a reboot, it unfortunately lost the default gateway settings, so it was back to square one.



Should I try restoring the NVR back to default settings?


Thanks for all your help

 

[alastairstevenson]

Well that's a shame the config didn't stick - but with the DNS being greyed out as well it may suggest the config is a bit screwy.
I tried that with mine and the trick worked - the web page 'read' the current settings and saved them to configuration, otherwise it's just a volatile change to the running environment.
At least now you know the root cause of the inability to access from the internet.

It's possible that resetting to defaults may then allow settings to be made normally - but it may also mess some other things up, though in theory it should not.
If you do decide to do that - save a copy of the existing device configuration on the assumption that it should be possible to re-apply it later. But if it's corrupt, that may not be guaranteed.

Before you do that - and you may already have done this a few times - in the Network configuration, blank the IPv4 gateway, click Save, put the correct value back, click Save again just to see if the value can be saved.
easily checked using the 'route' command.

 

[tmazid]

I thought I'd take the plunge and restore the settings on the NVR back to default settings, I mean what's the worse that could happen.

When it did finally return DHCP worked, which previously I couldn't tick. DNS Settings were filled in with the google DNS Servers and the default route was in the routing table, so it looks like everything is working fine now. Even port forwarding is working fine.

I'd just to like to thank you for all your help and patience in finally getting to the bottom of the issue,I have learnt a great deal from you for which I am very grateful. This is a great forum and don't know what I would have done without it.

Thanks again.

 

[alastairstevenson]

Brilliant!
It's always nice to get to a satisfactory endpoint. And interesting to visit the diversions on the way. Always a learning process.
Don't forget to save your device configuration after you have finished setting it back up again - may be useful in the future!

 

[tmazid]

Just couple of thing if you don't mind..., I may have spoken to soon...

I changed the NVR Server port from 8000 and the IP address of the NVR from DHCP, which required a reboot and after which, I lost the default gateway settings and the /etc/resolv.conf file, so obviously something is wrong with the box. I know how to fix this, thanks to you, so left it as DHCP with a reservation on the router for now, which works even after a reboot.

Question
1. How could I transfer the resolv.conf file to the NVR from my local PC, I know its not neccessary, I would just have to use IP addresses in the EMail and NTP Settings?
2. Moving forward and trying to fix this for good, what would you recommend? Are you aware of a newer English firmware for the NVR which is Chinese (currently 3.0.10 Build 141201) that I could use?

For your information, after saving the config file from the NVR of a working setup, i.e. default gateway and resolv.conf file present, I tried to reload the config file when the settings were not correct but it still did not fix the issue after the import.

Thanks and consider this issue resolved.

 

[alastairstevenson]

I'm surprised that restoring the device configuration file does not put all the settings back the way they were, that's always worked OK for me.

The file /etc/resolv.conf is actually located on the ramdisk, so is re-created at each bootup, from the stored values in the system configuration.
And if you are using DHCP to set the IP address and default gateway, the DNS server should also be automatically configured from this source, so name resolution should work OK. But it sounds like it doesn't.
On a volatile basis - ie until the next reboot, at a telnet command prompt
echo "nameserver 192.168.1.1" >> /etc/resolv.conf
Will create a one-line file. The '>>' appends to the file for adding more lines, and creates if it does not exist.