Urgh that guide was horrible- no good for anybody not in the network game and possibly even bad (DCHP for a forwarded device- not best practice unless you know you can get away with it as it is liable to change at various points*) and pointless for anybody who knows what goes as it buries most of the good info among junk (the multiple routers stuff- pointless for most people including those with multiple routers).
*some routers allow you to forward ports to/set rules for devices with given names or mac addresses so if you have that it is then a bit safer to use DCHP with them. If your device uses DCHP at best your remote security cam will not be accessible and worst case scenario is you allow the machine that takes the place of the cam to be internet facing. Unless you have a router able to set rules for a device name or mac address change the DVR to a static IP address (pick one higher up in the DCHP pool so as not to trouble your network) and forward ports appropriately to that static address.
This is getting somewhat off track through and by the looks of things the setup you wish to have goes something like this
Code:
Internet at large- your router- Your PC, consoles and whatever else which we are ignoring for now.
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ- The DVR device which hooks via coax into the security camera? (if it is network that might change things)
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ You want this DVR to face the internet so you can dial into it from outside and see goings on.
Anyhow it seems to be suggesting you do port forwarding rather than something else which I can sit behind I guess (hoping your DMZ is secure is about all you can do really).
Ports:
80 - standard web server.
9000 - Not sure what this is but I guess it is tied to it (looking around 9000 is used by a few streaming servers).
18004- apparently for mobile phones which leads me to think they have a cut down server on this port with more simplistic methods. An interesting design choice really but having dealt with mobile phones and web development I can not blame them (phones are possibly the new IE).
All appear to only want TCP connections. The security minded type would say if that is the case leave out UDP data as well but if you can only do TCP/UDP (some routers are not brilliant) it does not matter.
I will also mention some ISPs block port 80 (many US ISPs are fond of this and given most have something of a monopoly... I can not get a definitive answer as to whether they do but some have said they do so keep it in mind). A good router though will allow a soft redirect of sorts- you just get to add something like :8080 or whatever external port you decide to use to the URL/ip address (my advice is get yourself a dynamic IP address website thing-
http://www.dyndns.com/services/dns/dyndns/ as you probably do not have a reliably static IP address) and then use the router to forward it to the machine inside the network as appropriate*. The using :85 thing is another workaround for this.
*it will probably look something like
"port forwarding/translation options"
External port ????
internal port XXXXX
internal IP address/device ***.***.***.***
Again I am getting off topic so it is time to forward things. Find out which device is responsible for your network (chances are there is only one- the dual router stuff that guide was on about can be ignored for most non corporate setups) and get into the settings panel- here you need to find the port forwarding options (ignore all those programs the guide suggests).
http://portforward.com/english/routers/por...routerindex.htm is a good place to start. Specifically
http://portforward.com/english/routers/por...-07/default.htm
It looks like you have a device level filter but if you want to use the static IP I will not blame you.
Once you get to the port forwarding section you are going to have to do it two time (or three if you want mobile phone access)
TCP 80 80 80
TCP 9000 9000 9000
TCP 18004 18004 18004
Obviously you are going to want to test it. I usually abuse
http://hidemyass.com/ for such things as dialing up your external IP from inside the network tends to get it hooked and sent back into the internal network (where it will work but bad forwarding will not be detected until you are out in the field). It might not work properly but if you can access it as opposed to having it time out or refuse a connection then carry on to the next test (another network).