Access IP cameras from WAN

S

Schmark

Getting the hang of it
Apr 15, 2016
106
8
USA - California
NVR: Hikvision DS-7608NI-E2/8P NVR (FW V3.4.92 build 170518). All attached cameras are also Hikvision.

After recently upgrading the NVR FW to V3.4.92, I can no longer login to the cameras via WAN (I can via LAN), even though virtual host is enabled. Typing <NVR_WAN_IP_address>:6500X no longer works. Note that it used to work prior to the FW upgrade so I suspect the upgrade reset some key parameters. No changes to the router.

Does anyone have any idea what to do next? Or did Hikvision remove the login to individual cameras from the WAN with this release?

-S
 
Yes definitely do this - I use an Asus OpenVPN search those terms for the forum thread. Its not so bad, bring up OpenVPN connect to the router via VPN, and then start iVMS or Android TinyCam. Kind of 2 step but not too much of a pain.
 
So, I did get an ASUS RT-AC68U modem and setup the OpenVPN server. I then copied the client and certification files on a remote computer and executed the OpenVPN client. The client status showed:
- [RT-AC68U] Peer Connection Initiated with [AF_INET] 97.90.x.x:1194
- Initialization Sequence Completed

Hovering over the tray icon on the remote shows:
- Connected to: client
- Assigned IP: 10.8.x.x

Logs on the server also show evidence of a connection with my remote computer with several lines including the following:
- vpnserver1[10912]: x.x.x.x:64317 TLS: Username/Password authentication succeeded for username "abcde"
- vpnserver1[10912]: x.x.x.x:64317 [client] Peer Connection Initiated with [AF_INET]x.x.x.x:64317 (via [AF_INET]97.90.x.x%eth0)
Where x.x.x.x is the IPv4 of my remote computer and "abcde" the login username

My layout is on the graphics below as I am trying to get to the NVR from the remote computer. I also show a screen shot of the router advanced settings.
However, from the remote computer I get "timeout" when pinging the WAN address 97.90.x.x. Yet, unexpectedly, I can connect to the NVR via NVMS7000 on a cell phone, without even performing any VPN client connection !!!

Questions:
1. Why can't I ping the WAN address after the client successfully connects to the server?
2. Why can my cell phone access the NVR without any (apparent) VPN client connection?
3. What is the use of the assigned IP address provided by OpenVPN (10.8.x.x)? I noticed the OpenVPN client creates a new adapter on the PC with that IPv4 address.

Thanks for any help.

S.
= = = = = =
upload_2019-1-22_11-52-16.png
upload_2019-1-22_12-22-10.jpeg
 
Last edited:
Im a bit confused by your statements.

Yes the 10.x.x.x network is what you terminate to when you VPN into the WAN side of your modem.

You should not be able to connect to your camera NVR without firstly invoking openvpn client to vpn to the ASUS modem.

Your network looks complicated can you use the ASUS to terminate your ISP fibre/ vdsl?

Simplify.

The only time your mobile should be able to terminate connect to your camera nvr is when its wifi connected at the location where you kit is.

Also when you generate the openvpn cert I recall having to input the dynamicDNS service you use to query the current WAN IP address.

If your mobile is connecting without vpn then do you still have port forward enabled on the modem/ asus?

Is UPnP turned off?

Run a portscan on the WAN IP address using something like FING or similar to see whats open. No ports should be as thats the idea of VPN server.
 
Thanks tradertim. In response to your feedback:
>>You should not be able to connect to your camera NVR without firstly invoking openvpn client to vpn to the ASUS modem.
My post describes a situation that occurs AFTER executing the OpenVPN client. What I don't understand is why I can't ping 97.90.x.x after getting "Peer Connection Initiated with [AF_INET] 97.90.x.x:1194" on the remote computer.

>> Your network looks complicated can you use the ASUS to terminate your ISP fibre/ vdsl?
I believe my network is a bare as it gets. I have to have a modem as it also handles telephony and that modem connects to Spectrum via cable (coax). The ASUS router can't handle that connection

>> The only time your mobile should be able to terminate connect to your camera nvr is when its wifi connected at the location where you kit is.
My mobile connects to the NVR even when I'm not at home AND did NOT forward any port on the router.

>> Also when you generate the openvpn cert I recall having to input the dynamicDNS service you use to query the current WAN IP address.
>> Is UPnP turned off?
>> Run a portscan on the WAN IP address using something like FING or similar to see whats open
I'll check on that tonight. NOTE: I would expect ASUS to include the dynamicDNS statement when it generates its cert

The VPN tunnel appears to work because from the remote, I can successfully ping the other end of the tunnel at 10.8.0.1 and “tracert 10.8.0.1” expectedly shows only one hop. But "Tracert 97.90.x.x" gets interrupted after several hops within the Spectrum/Charter realm . . .

-S
 
I wouldnt worry too much on not being able to ping the WAN.

Your Asus is on a different network and would pass it 97. .x.x to the default gateway which is your modem. Some devices for security have ICMP PING on the WAN disabled.

The ping might be going bck into the Cable network or PInG is disabled on the cable modem.

If you can ping your NVR and.cameras then youve acheived what you wanted.

My ASUS terminates my VDSL and so thats a shame you cant simplify. As sometimes you get issues with double NAT passing through multiple devices but VPN to the ASUS should mitigate that.

See if the ASUS will terminate cable and look to get rid of the ISP modem.

But then I just read you have voice as well. Canf remember if ASUS has an ATA for VoIP it would need to be populated with the parameters from the cable company.

The service I use is DynDNS for dynamic DNS.

Your service could be working because your WAN ip address hasnt change yet.
If your modem is restarted your IP address on the WAN might change and without DynDNS service the OpenVPN client wont know what IP addres your modem is at

Something to ponder.

Seems to me you are 90% where you desired to be?

The mobile phone connecting to your NVR is worrying this should not be possible without first setting the VPN.

What app in your phone?
What credentials, IP address does the app have on it?

You must have some open ports on your WAN modem, and a static Modem/ WAN ip address?

More info required.
 
Tradertim: SUCCESS. Your suggestion to running a port scan with Fing was a brilliant idea. Why? Because it gave me the IPv4 of the NVR and when I pinged it remotely, it responded (though not sure why the router's WAN address did not respond to ping)

I now have OpenVPN fully running and NO ports forwarded on the router (which I had before, a complete security flaw). To answer your recent questions:
- UPnP is enabled. Should it be turned OFF?
- DDNS is disabled. ASUS provides a good list of DDNS servers including DynDNS and its own. I'll leave it as is for now as my WAN IPv4 address is fixed as long as I don't reboot the router.
- The app I use on the smartphone is NVMS7000 and is setup with IP/Domain mode and the router's WAN address. Perhaps because I do not have a VPN client on the phone, I can't get it to work with the NVR LAN address. How does one run a VPN client on a smartphone with the ASUS certs?

Thanks so much

-S
 
Last edited:
Unless you have a true static IP I suggest 100% to set up DDNS.

Sure, ISP IPs tend to stay the same for quite a while but that sort of thing ends up being a problem at the worst time. Set up the DDNS. AFAIK, there is no downside to doing so but there is downside to not.
 
Yeah I agree like whoaru says.

If your ISP does some maintainance and your IP address changes your whole system breaks. You wont be able to access it. you wont know the IP address.

Turn UPnP OFF for both the NVR and Modem .

Any further changes i'd make one at a time and test/ validate system still works. Dont change too much all at once.

I dont know why you are getting the NVR IP address at the WAN.

Turn ICMP off at the WAN of the modem.

Dynamic DNS you will have to enable but since your static I would leave that to the very last.

You will need to have a user password i recall to input into the OpenVPN cert when you generate it. I think this is correct it was a while ago I did it.

Theres an OpenVPN client for phones mines android , see google play store.
Generate the cert from the ASUS , send it via email, save it into your phone, import it.

Then its a 2 step process open Vpn,connect and then use TinyCam or IVMS.

Turn off UPnp on both NVR and Modem.
Turn off ICMP on modem.
Can leave it on your NVR.

The last thing I do is i cycle my modem everyday at midnight. This changes the ip address for me on the WAN.

Else you have every black masked hacker from <insert country reference here> camping out on your WAN for days on end looking and running scans for a way into your network.

This happens hundreds of times a day on your modem WAN ip address and every single persons modem on the internet.

You would be shocked.

Turn logging on or look at logging on your
modem and take a look at all the hackers port scanning your modem.

hope all that helps
 
for the asus modem DDNS is available from asus. It is part of setting up the openVPN
C10.JPG
 
young grasshopper......

so the basic idea with DDNS is you define a domain name say "younggrasshoppershouse.dyndns.com"

give it a username and password, enabling dynamic dns on the modem or Asus will updlate Dynamic DNS younggrasshopper domain name with the IP address when it changes.

Dynamic DNS or similar company stores the current IP address.

Then you data fill the dynamic dns domain user and password into the openvpn cert and it knows the IP address of the Asus for the VPN.

For me Dynamic DNS is free and just have to renew it once a month via email click a couple of cars/ buses non robot bot pictures and it renews.

So from then onwards your ASUS VPN is known as younggrasshoppershouse.dyndns.com and that resolves to the actual IP address.

Im a bit worried about your modem in front of everything but somehow it knows to forward your VPN request to the ASUS.
Theres features called VPN passthrough and so maybe that is what is happening.

If you use ASUS to enable Dynamic dns just a bit worried how it realises the WAN ip address has changed ..its one step down from the WAN modem .... might be a lag or not .guess try it and see.

Else use the Modem to enable dyn DNS.

Id look to change service providers and get your ASUS to terminate adsl vddl or fibre. Maybe it does cable?

Not surr if it has an ATA for voice... its a pretty good router and so maybe.

Simplify if you can.
 
For the Asus you just give it a user name is xyzabc1234. The asuscomm.com is the address of the Asus ddns server.
The way I understand it.
The router communicates to the Asus server with the IP address when it change. Openvpn contacts the Asus server to get the address.
In the screen shot you see the wan address.
 
Schmark said:
NVR: Hikvision DS-7608NI-E2/8P NVR (FW V3.4.92 build 170518). All attached cameras are also Hikvision.

After recently upgrading the NVR FW to V3.4.92, I can no longer login to the cameras via WAN (I can via LAN), even though virtual host is enabled. Typing <NVR_WAN_IP_address>:6500X no longer works. Note that it used to work prior to the FW upgrade so I suspect the upgrade reset some key parameters. No changes to the router.

Does anyone have any idea what to do next? Or did Hikvision remove the login to individual cameras from the WAN with this release?

-S
Click to expand...
I have an NVR that doesn't support virtual host.

There is a simple workaround with an extra bit of kit

Hitting cameras web pages with a laptop in an NVR with POE

CmdrBond said:
I just wanted to add my thanks into this thread, as I can now access my cameras web UIs remotely.

My configuration is as follows (not my IP addresses):
Code: 
+--------+                                         +---------+
| Router |                                         |  NVR    |
|        |                 1.0.0.2                 |         |
|    LAN +-----------------------------------------+ NIC     |
|        |                                         |         |
|        |             +-------------+             |         |
|        |             | Mini Router |             |         |
|        |   1.0.0.3   |             |   2.0.0.8   |         |
|    LAN +-------------+ LAN     WAN +-------------+ POE 8   |
|        |             |             |             |         |
|        |             +-------------+             |         |
|        | 1.0.0.x                                 |         |
|   WiFi +--)))        +-------------+             |         |
|        |             |             |  2.0.0.1-4  |         |
+--------+             | Cameras 1-4 +-------------+ POE 1-4 |
                       |             |             |         |
                       +-------------+             +---------+
With a static route pointing at 2.0.0.0 through 1.0.0.3

The mini router I am using is a Vonets VAR11N that I've had kicking around for some time.

Typing any 2.0.0.x address from a browser on a 1.0.0.x address connects flawlessly.

If anyone is struggling with this, hopefully, this will help understand the setup for this to work.
Click to expand...
 
So, per the many recommendations, I setup a DDNS with asuscomm.com. Works great. I may also want to experiment with changing the server port to numbers other than 1194 to become less visible to port scanners. I get scanned regularly by a UK web site (185.200.118.69:XXXXX -the port varies-) every ~12 hours and the router log shows the following lines:
Feb 9 02:03:45 vpnserver1[597]: 185.200.118.69:44950 TLS: Initial packet from [AF_INET]185.200.118.69:44950 (via [AF_INET]97.90.xx.xx%eth0), sid=12121212 12121212
Feb 9 02:04:45 vpnserver1[597]: 185.200.118.69:44950 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Feb 9 02:04:45 vpnserver1[597]: 185.200.118.69:44950 TLS Error: TLS handshake failed
Feb 9 02:04:45 vpnserver1[597]: 185.200.118.69:44950 SIGUSR1[soft,tls-error] received, client-instance restarting

Do these cryptic lines show that the scanner did not pass the ASUS firewall?

Thank you all.
 
Schmark said:
I may also want to experiment with changing the server port
Click to expand...

Many years ago I ran an RDP server on default RDP port 3389 and it was hammered from the WAN side with login attempts; day after day, night after night, month after month...it never stopped. I changed the port to 33890 and those login attempts stopped. Port forwarding isn't the answer...VPN is the answer. But if there's no convincing one of that fact then changing the port number to a ephemeral port may help reduce exposure

VPN good!

Port forwarding bad!

1h12.jpg
 
Schmark said:
So, per the many recommendations, I setup a DDNS with asuscomm.com. Works great. I may also want to experiment with changing the server port to numbers other than 1194 to become less visible to port scanners. I get scanned regularly by a UK web site (185.200.118.69:XXXXX -the port varies-) every ~12 hours and the router log shows the following lines:
Feb 9 02:03:45 vpnserver1[597]: 185.200.118.69:44950 TLS: Initial packet from [AF_INET]185.200.118.69:44950 (via [AF_INET]97.90.xx.xx%eth0), sid=12121212 12121212
Feb 9 02:04:45 vpnserver1[597]: 185.200.118.69:44950 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Feb 9 02:04:45 vpnserver1[597]: 185.200.118.69:44950 TLS Error: TLS handshake failed
Feb 9 02:04:45 vpnserver1[597]: 185.200.118.69:44950 SIGUSR1[soft,tls-error] received, client-instance restarting

Do these cryptic lines show that the scanner did not pass the ASUS firewall?

Thank you all.
Click to expand...
yeah that didnt get in re TLS error handshake failed.

The theory is unless a device has the certificate that you generated from the ASUS server imported into your clients (phone laptop etc) they should not be able to connect through your network.

As long as you run a WAN port scan and all ports are closed, icmp disabled, upnp disabled and so on.
 
scans are normal in today's internet. If your router has a hole in its security , the scans will find it. I get scans all the time, multiple IP addresses from around the world.
 
Q™ said:
Many years ago I ran an RDP server on default RDP port 3389 and it was hammered from the WAN side with login attempts; day after day, night after night, month after month...it never stopped. I changed the port to 33890 and those login attempts stopped. Port forwarding isn't the answer...VPN is the answer. But if there's no convincing one of that fact then changing the port number to a ephemeral port may help reduce exposure

VPN good!

Port forwarding bad!

View attachment 39085
Click to expand...
Had the same thing happen to me. VPN is indeed the solution to it all

I dont expose any hikvision equipment to the net. Just too many exploits constantly found. Cant trust it
 
You must log in or register to reply here.
Top Bottom