(PeteCresswell) said:
Is there any way to do this without buying some sort of utility
to be called from the .BAT or .CMD file?
While the default setup for routers is to have their internal DHCP
server assigned dynamic IP address to the hosts, that doesn't mean you
need to use dynamic IP address on your intranet hosts. Look at the
range of dynamic IP address your router's DHCP server will assign. Say
it's 192.168.1.x where x = 100 to 200 (often it's smaller because the
router's processor can only handle so many concurrent hosts in its
switching, or if you go more than 50 hosts the typical home-use router
will get overly slow). You then assign STATIC addresses to each of your
hosts that is outside that range, like 192.168.1.20, 192.168.1.50,
192.168.1.215 and so on (but still with the range of x = 1 to 254 but
with the router's DHCP range omitted). You don't need to use dynamic IP
addresses on your intranet hosts.
The WAN-side (Internet side) of your router will get a dynamic IP
address from your ISP (unless you pay them extra for a static IP
address). That's the IP address every site sees when you connect to
them. That's your Internet IP address for all hosts on the LAN side of
your router - and that's probably the actual IP address you want to find
out in your e-mails. For some reason, you're using e-mails to discover
what is the current dynamic IP address assigned to the WAN-side of your
router by your ISP's DHCP server. It could change and you want to know
what it is now (or, at least, the last time you sent an e-mail with your
router's dynamic WAN-side IP address).
Presumably you are trying to connect to your host from somewhere via
Internet, like from another computer. Well, using an IP address is one
way but that means you need to know what is the currently assigned IP
address to the remote host. Since most end users don't pay for a static
IP address (usually only available in the more expensive business
accounts), it's dynamic and can change even for broadband users (DSL and
cable). If using wifi on that host, it changes everytime you move into
a different wifi hotspot. Rather than find out and use an IP address,
why not use a static DNS hostname?
There are several DNS redirection services available, some for free (but
with limitations). You get a hostname that is always the same, like
pcresswell12.no-ip.org. All you have to remember or configure in some
remote access software is that hostname. It won't change no matter what
is the current dynamic IP address assigned to that host (well, actually
to your router). When you connect to pcresswell12.no-ip.org, you use
their DNS server. Your remote host updates your no-ip account to
reflect what is its current IP address. So their DNS server returns
whatever is the current IP address for your remote host.
I use DynDNS (now called Dyn) with a free account for DNS redirection.
No matter what my ISP assigns to my router's WAN-side IP address, the
hostname I defined in DynDNS is always the same but my account there
gets updated with my current IP address. When I browse to
<myhostname>.dyndns.org in my web browser, and because hostnames require
conversion to IP addresses (humans like names, computers require
numbers), my web browser will issue a DNS request for a lookup on that
hostname to get an IP address. The DNS server at DynDNS responds by
giving my web browser whatever is currently recorded in my DynDNS
account as my IP address.
The DNS redirection service only equates a hostname to an IP address
(without having to run your own DNS server to do the same). That will
get you to the network device with that IP address. That is the
WAN-side of your router. That's not a host in your intranet. You will
need to define a port forwarding rule in your router so all incoming
connects to that port get forwarded to the appropriate host in your
intranet. For example, if operating a publicly accessible web server
(something which most ISP's ban in their TOS) on host #1 in your
intranet (LAN-side of your router) listening on port 8080, you will need
to punch a hole in the router's firewall by having all port 80 connects
(the default HTTP port used by web browsers) to your router (that got
there after doing the DNS lookup at the DNS redirection service to get a
dynamically assigned IP address from a static hostname that you can
remember and don't have to change in any software config). The port
forward rule in the router takes all port 80 connects on its WAN side
and forwards those packets to the specified port (8080) on host #1 in
your intranet. The port forwarding rule will forward inbound connects
from one port on the router's IP address and send them to the specified
port on the specified intranet host. Because you are punching a hole
through your router for unsolicited inbound connects that go to a host
inside your network, you need to secure that host by locking down the
server program on it, running security software, and perhaps using a DMZ
you can define in the router (so that host can get unsolicited inbound
connects but that host cannot make outbound connects to your other
intranet hosts; i.e., you isolate your web server on your other intranet
hosts).
For a DNS redirection service to work means having to update your
account there with whatever is your current dynamic IP address. Some
routers have a DDNS (dynamic DNS) function but only for a few select DNS
redirection providers (e.g., Dyn, TZO). Also, some routers only perform
an update of your account when they see a change in your IP address.
Since broadband (DSL and cable) users get IP addresses that may last
months, this is far longer than the idle expiration for free accounts at
DNS redirection providers. The result is that your IP address hasn't
change for a long time, your router doesn't send an update, there's been
no update in, say, 30 days, and the DNS redirection provider figures
you've abandoned the free account so they delete it. If the router has
a DDNS function, check if it has a means to set the update interval (so
it is shorter than the idle expiration for a free account). Remember
that it is the WAN-side IP address of the router that you need when
making an external connection via Internet to your remote host on the
other side of the router and then you need to define your router what to
do with that external inbound connection. Rather than having the router
do an account update, you can run a DNS updater client provided by the
DNS redirection service. What that does is connect to your account.
Every host knows the IP address of whatever host connects to it, so the
update will have your IP address. Since it's your router that's doing
the connecting to an external host when you run web software on your
intranet host, they'll see the IP address for your router.
You can use a DNS redirection service (so you use a static hostname
instead of having to discover the current dynamic IP address) along with
port forwarding rules in your router to grant external access to your
intranet host. For example, you can use some variant of VNC (TightVNC,
UltraVNC) to get remote access to an intranet host. You find the
dynamic IP address of your router (assigned by your ISP's DHCP server)
using a static hostname that you can remember or code into some
program's configuration and don't have to change. Once you get the IP
address, you connect to the router. The router uses a port forwarding
rule to direct your connection to a specific intranet host listening on
the specified port (something has to be listening for inbound connects
on your intranet host; i.e., you need a server process there). The VNC
server running on that intranet host accepts the inbound connection and
now you're remotely connected to that host. It's a lot of setup but
once done stays the same: create an account at DNS redirection service,
install their DNS updater client on your intranet host, define a port
forwarding rule in the router to accept inbound connects and redirect
them to your server intranet host, and install some server on your
intranet host that listens on a port for those inbound connects.
Rather than use a DNS redirection service (to equate a static hostname
to a dynamically assigned IP address), and if remote access is your
goal, there are easier methods and which don't require punching holes in
your router's firewall, like TeamViewer, LogMeIn, and Mikogo. They do
the same DNS lookup that DynDNS and No-IP do for you; however, you don't
need to punch a hole through your router's firewall. Their client will
poll your account to see if someone requesting a connection. The
external connection pends until the client on your remote host queries
your account to see the pending connection. If it sees a pending
connection at the server, it accepts the connection and the other host
gets the IP address for your remote host and then the two hosts connect
to each other using the IP address that the DNS server gave the other
host. Since the client is making outbound HTTP connections to poll your
account (to both update the IP address in your account and check for
inbound connect requests), and since software firewalls and the one in
your router permit outbound HTTP connects (like for your web browser),
and because you don't usually need to throttle outbound connects (you
prevent unsolicited inbound connects with the firewall), the client gets
out unfettered to the DNS redirection provider's server to update your
account and check for connect requests. Other than having to install a
small client on your remote host to make it always available for
external access, the whole setup is rather automatic when using
TeamViewer, LogMeIn, or Mikogo.
You don't necessarily have to setup your remote host to always be
checking for connect requests to it. That's only when you leave one
computer and want to have it always available to you when away from it
using a different host. If your intent is to protect remote help to
someone else, you can use those same remote access services for a single
session. The user wanting help will have to connect to the service by
visiting a web page (perhaps by clicking on a URL in an e-mail you send
them), they permit the remote connection, and you get remotely connected
to their host. This is one-time handshaking process. This still does
require a client (as an AX plug-in or extension to the web browser) get
"installed" so it can handle that inbound connect request; however,
after the session is over, you don't need that AX control or extension
(it may uninstall itself, you may uninstall it, or just leave it around
for the next time).
