SSH'ing between machines with private IPs - SSH

This is a discussion on SSH'ing between machines with private IPs - SSH ; Hi, I have a workstation with a private IP address getting its signal from a wireless AP that is behind a cable modem. I would like to SSH into another workstation with a private IP address getting its signal from ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: SSH'ing between machines with private IPs

  1. SSH'ing between machines with private IPs

    Hi,

    I have a workstation with a private IP address getting its signal from
    a wireless AP that is behind a cable modem. I would like to SSH into
    another workstation with a private IP address getting its signal from a
    wireless AP that is behind a cable modem. Can I do this? If so, how?

    Thanx,
    John


  2. Re: SSH'ing between machines with private IPs

    fcache@gmail.com hath wroth:

    >I have a workstation with a private IP address getting its signal from
    >a wireless AP that is behind a cable modem. I would like to SSH into
    >another workstation with a private IP address getting its signal from a
    >wireless AP that is behind a cable modem. Can I do this? If so, how?


    Yeah, it's easy with dynamic DNS. Your routers or an application
    running on the computahs updates the WAN IP address to a dynamic DNS
    service provider. You don't need to know the IP address of the other
    side of the link, just the FQDN (fully qualified domain name).

    List of dynamic DNS service providers:

    http://dmoz.org/Computers/Software/I..._DNS_Services/
    I use dyndns.com and no-ip.com using clients on the client machines.
    I've had very bad luck with routers that have built in DDNS clients.
    The hardware client problem is bad enough that some vendors are
    certifying DDNS clients:
    http://www.dyndns.com/support/clients/hardware/

    As for the SSH server and clients, kindly disclose your operating
    system and version. If Windoze, see:
    http://www.openssh.com/windows.html


    --
    Jeff Liebermann jeffl@comix.santa-cruz.ca.us
    150 Felker St #D http://www.LearnByDestroying.com
    Santa Cruz CA 95060 http://802.11junk.com
    Skype: JeffLiebermann AE6KS 831-336-2558

  3. Re: SSH'ing between machines with private IPs


    You will need to configure the router on the receiving side -- the only
    box there with a real Internet IP address -- to forward connections to
    a chosen port to the internal SSH server you want to reach.

    You can then use the naming schemes suggested (e.g. "dyndns.com" etc.) to
    ease reaching the router by having a name for it, and in case its address
    changes.

    --
    Richard Silverman
    res@qoxp.net


  4. Re: SSH'ing between machines with private IPs

    Jeff Liebermann writes:

    >fcache@gmail.com hath wroth:


    >>I have a workstation with a private IP address getting its signal from
    >>a wireless AP that is behind a cable modem. I would like to SSH into
    >>another workstation with a private IP address getting its signal from a
    >>wireless AP that is behind a cable modem. Can I do this? If so, how?


    The short answer is no. The longer answer is maybe.
    private ips are better called unroutable IPs.
    Now, the cable provider may give your cable modem a public IP address. On
    the other hand they may not. If they do, and your cable modem also acts as
    a router, and that router allows port forwarding then you could ask the
    routers to forward port 22 to your internal machine.


    >Yeah, it's easy with dynamic DNS. Your routers or an application
    >running on the computahs updates the WAN IP address to a dynamic DNS
    >service provider. You don't need to know the IP address of the other
    >side of the link, just the FQDN (fully qualified domain name).


    Unfortunately the updates to the public routing tables are usually very
    slow. A week is not uncommon. And in a week your IP on your modem/router
    may have changed 7 times. Ie, it will depend not only on the dynamic dns
    but also on how often your local dns server updates its cache.



    >List of dynamic DNS service providers:


    >http://dmoz.org/Computers/Software/I..._DNS_Services/
    >I use dyndns.com and no-ip.com using clients on the client machines.
    >I've had very bad luck with routers that have built in DDNS clients.
    >The hardware client problem is bad enough that some vendors are
    >certifying DDNS clients:
    > http://www.dyndns.com/support/clients/hardware/


    >As for the SSH server and clients, kindly disclose your operating
    >system and version. If Windoze, see:
    > http://www.openssh.com/windows.html



  5. Re: SSH'ing between machines with private IPs

    Unruh hath wroth:

    >Now, the cable provider may give your cable modem a public IP address. On
    >the other hand they may not.


    True. Most broadband providers supply routeable IP's to their
    customers. I know of some that do not. However, these also have the
    option of redirecting a routeable IP address to the non-routeable
    private IP delivered to the customer. It's kinda like the misnamed
    DMZ feature in most small routers. Many wireless ISP's do this to
    avoid having to beg or pay for a large block of routeable IP
    addresses. Most home users don't require a routeable IP. Of course
    the ISP's charge for this feature.

    >If they do, and your cable modem also acts as
    >a router, and that router allows port forwarding then you could ask the
    >routers to forward port 22 to your internal machine.


    A cable modem is a bridge, which knows nothing about routeing.
    There are cable routers, which combine a cable modem and an ethernet
    router in one package.

    >>Yeah, it's easy with dynamic DNS. Your routers or an application
    >>running on the computahs updates the WAN IP address to a dynamic DNS
    >>service provider. You don't need to know the IP address of the other
    >>side of the link, just the FQDN (fully qualified domain name).

    >
    >Unfortunately the updates to the public routing tables are usually very
    >slow. A week is not uncommon.


    Not exactly. I just added a new sub-domain to my dyndns.com account.
    About 3 minutes to get recognized by my ISP's nameserver. My DNS
    lookup initially went to the authoritative nameserver at dyndns.com
    for my domain and did the lookup. No big deal for sub-domains. As
    long as the resolver can find an authoritative nameserver for the
    domain, the updates are almost instantaneous.

    What methinks you're thinking of is new domains. These can take a few
    days because the local nameserver doesn't have a clue who the
    authoritative nameserver is for that new domain. Last time I created
    a new domain on Joker.com, it took about 2 days for SBC to get the
    update. About the same for 1and1.com.

    >And in a week your IP on your modem/router
    >may have changed 7 times. Ie, it will depend not only on the dynamic dns
    >but also on how often your local dns server updates its cache.


    It's really loads of fun when the local ISP's primary and secondary
    DNS servers don't agree. I've been there a few times. They were
    intentionally delaying updates on the secondary so that if the primary
    got trashed during an update, the secondary would still be useable.

    Most of the local ISP's flushes their DNS cache once per day.

    If using W2K or XP don't forget about the local DNS cache.
    ipconfig /displaydns
    ipconfig /flushdns

    --
    Jeff Liebermann jeffl@comix.santa-cruz.ca.us
    150 Felker St #D http://www.LearnByDestroying.com
    Santa Cruz CA 95060 http://802.11junk.com
    Skype: JeffLiebermann AE6KS 831-336-2558

  6. Re: SSH'ing between machines with private IPs

    wrote:
    >I have a workstation with a private IP address getting its signal from
    >a wireless AP that is behind a cable modem.
    >I would like to SSH into another workstation with a private IP address
    >getting its signal from a wireless AP that is behind a cable modem. Can I
    >do this? If so, how?


    You mean you want to connect from outside into a box that's behind a NAT
    system?

    This is easy if the NAT device (your AP, in this case) supports "port
    forwarding" - set it so that port 22/tcp gets forwarded to the appropriate
    internal address.
    --
    Mark Rafn dagon@dagon.net


  7. Re: SSH'ing between machines with private IPs

    Jeff Liebermann writes:
    >>
    >>Unfortunately the updates to the public routing tables are usually very
    >>slow. A week is not uncommon.


    >Not exactly. I just added a new sub-domain to my dyndns.com account.
    >About 3 minutes to get recognized by my ISP's nameserver. My DNS
    >lookup initially went to the authoritative nameserver at dyndns.com
    >for my domain and did the lookup. No big deal for sub-domains. As
    >long as the resolver can find an authoritative nameserver for the
    >domain, the updates are almost instantaneous.


    YMMV. I had a Telus ADSL and when they would change my routable address, it
    usually took almost a week for the change to propagate to the University
    where I work. I think that Telus put a long "stale date" on the DNS
    address and/or the DNS caches here took a long time.

    I also changed the address of one of my mail machines here, and mail was
    still being delivered to the other one a month later. (Ie, there were DNS
    caches out there that had not refreshed themselves for a month).

    Do NOT trust that just because your DNS server is serving out the new
    address that anyone else in the world knows it. If your provider changes
    the address more ofteh than once in a few months the chances of your being
    able to use DNS to discover the new address are slim.


    >What methinks you're thinking of is new domains. These can take a few


    Nope. Simple address change of a dynamic address associated with a fixed
    name. Or simple MX record change to another machine on exactly the same
    subdomain.


    >days because the local nameserver doesn't have a clue who the
    >authoritative nameserver is for that new domain. Last time I created
    >a new domain on Joker.com, it took about 2 days for SBC to get the
    >update. About the same for 1and1.com.


    string.physic.ubc.ca to info.physics.ubc.ca
    or a simple IP change to the same address.



    >>And in a week your IP on your modem/router
    >>may have changed 7 times. Ie, it will depend not only on the dynamic dns
    >>but also on how often your local dns server updates its cache.


    >It's really loads of fun when the local ISP's primary and secondary
    >DNS servers don't agree. I've been there a few times. They were
    >intentionally delaying updates on the secondary so that if the primary
    >got trashed during an update, the secondary would still be useable.


    >Most of the local ISP's flushes their DNS cache once per day.


    >If using W2K or XP don't forget about the local DNS cache.
    > ipconfig /displaydns
    > ipconfig /flushdns


    Whatever the cause the symptoms are that you cannot trust DNS to get your
    name or IP change out there anytime soon.

  8. Re: SSH'ing between machines with private IPs

    >>>>> "Unruh" == Unruh writes:

    Unruh> The short answer is no. The longer answer is maybe. private
    Unruh> ips are better called unroutable IPs.

    That doesn't make sense -- any IP address is perfectly "routable;" entire
    organizations with large, complex networks route these packets every day.
    The are correctly called "private" addresses for their intended use: they
    must be kept within private networks, since they are not globally unique
    and hence cannot be used on the public Internet.

    Besides, these address ranges are defined in RFC 1918, entitled "Address
    Allocation for Private Internets," which refers explicitly and repeatedly
    to "private address space" and "private addresses."

    >> Yeah, it's easy with dynamic DNS. Your routers or an application
    >> running on the computahs updates the WAN IP address to a dynamic
    >> DNS service provider. You don't need to know the IP address of the
    >> other side of the link, just the FQDN (fully qualified domain
    >> name).


    Unruh> Unfortunately the updates to the public routing tables are
    Unruh> usually very slow. A week is not uncommon.

    I'm sorry, but this is nonsense. Convergence time for routing protocols
    is commonly measured in seconds, a few minutes at the outside perhaps for
    changes in the topology of the Internet at a large scale involving complex
    BGP relationships.

    Also, this has nothing to do with the text preceding your comment: he was
    talking about the DNS; you responded with a comment about routing tables.

    Now perhaps, you meant to say something about changes to the DNS, rather
    than "routing tables." Even allowing that, your comment is still
    incorrect. Changes to second-level delegations (as when you register a
    new domain or transfer one) take two days to be completely effective once
    actually done by the TLD nameservers, since that is the enforced TTL on
    those NS records. But this fact is irrelevant to a service such as
    dyndns.org, which is changing records within their own zones, and can
    change them just as quickly as it likes. These names can be updated
    within seconds or minutes of a DHCP change on a client.

    Unruh> depend not only on the dynamic dns but also on how often your
    Unruh> local dns server updates its cache.

    The "local DNS server" does not determine this; it is determined on a
    per-RR basis by their TTL values, which are in turn set by the owner of
    the containing zone -- in this case, the "dynamic DNS" service provider.

    --
    Richard Silverman
    res@qoxp.net


  9. Re: SSH'ing between machines with private IPs

    "Richard E. Silverman" writes:

    >>>>>> "Unruh" == Unruh writes:


    > Unruh> The short answer is no. The longer answer is maybe. private
    > Unruh> ips are better called unroutable IPs.


    >That doesn't make sense -- any IP address is perfectly "routable;" entire
    >organizations with large, complex networks route these packets every day.
    >The are correctly called "private" addresses for their intended use: they
    >must be kept within private networks, since they are not globally unique
    >and hence cannot be used on the public Internet.


    No All public routers throw them away precisely because of their problems.
    Sure, internally you may be able to route them, but no public router will
    do so (or rather should do so.)

    So I repeat, private IPs are better called unroutable IPs.



    >Besides, these address ranges are defined in RFC 1918, entitled "Address
    >Allocation for Private Internets," which refers explicitly and repeatedly
    >to "private address space" and "private addresses."


    > >> Yeah, it's easy with dynamic DNS. Your routers or an application
    > >> running on the computahs updates the WAN IP address to a dynamic
    > >> DNS service provider. You don't need to know the IP address of the
    > >> other side of the link, just the FQDN (fully qualified domain
    > >> name).


    > Unruh> Unfortunately the updates to the public routing tables are
    > Unruh> usually very slow. A week is not uncommon.


    >I'm sorry, but this is nonsense. Convergence time for routing protocols
    >is commonly measured in seconds, a few minutes at the outside perhaps for
    >changes in the topology of the Internet at a large scale involving complex
    >BGP relationships.


    Experiments indicate otherwise.
    ALL DNS is cached. Otherwise the net would be constantly clogged up with
    DNS queries. The caching time varies. The Autoritative source is supposed
    to say how long the caching can go on for without renewal, but many do not
    pay any attention to that.



    >Also, this has nothing to do with the text preceding your comment: he was
    >talking about the DNS; you responded with a comment about routing tables.


    No, I was talking about DNS queries and DNS caching. That should have read
    public DNS caches, I agree.

    >Now perhaps, you meant to say something about changes to the DNS, rather
    >than "routing tables." Even allowing that, your comment is still
    >incorrect. Changes to second-level delegations (as when you register a
    >new domain or transfer one) take two days to be completely effective once
    >actually done by the TLD nameservers, since that is the enforced TTL on
    >those NS records. But this fact is irrelevant to a service such as


    You cannot enforce anything. It is up to the other side, the caching side
    to honour your request. Many do not.


    >dyndns.org, which is changing records within their own zones, and can
    >change them just as quickly as it likes. These names can be updated
    >within seconds or minutes of a DHCP change on a client.


    Of course it CAN be. The question is what IS, not what can be.


    > Unruh> depend not only on the dynamic dns but also on how often your
    > Unruh> local dns server updates its cache.


    >The "local DNS server" does not determine this; it is determined on a
    >per-RR basis by their TTL values, which are in turn set by the owner of
    >the containing zone -- in this case, the "dynamic DNS" service provider.


    No, the TTL is a suggestion. The caching dns server must honour that
    request for it to be effective. The evidence is that they do not.


    >--
    > Richard Silverman
    > res@qoxp.net



  10. Re: SSH'ing between machines with private IPs

    >>>>> "Unruh" == Unruh writes:

    Unruh> No All public routers throw them away precisely because of
    Unruh> their problems. Sure, internally you may be able to route
    Unruh> them,

    Hence they are not "unroutable;" the term is a contradiction, period. It
    makes no sense.

    Unruh> So I repeat, private IPs are better called unroutable IPs.

    The document which defines their use disagrees with you:

    >> Besides, these address ranges are defined in RFC 1918, entitled
    >> "Address Allocation for Private Internets," which refers explicitly
    >> and repeatedly to "private address space" and "private addresses."


    Interesting that you did not comment on this.

    As for changes taking "weeks" for DNS changes to propagate: of course some
    DNS servers behave incorrectly. I have run into ISPs which do this.
    However, it is an exception, not the rule, as well as being nonstandard
    behavior, and I don't think claiming this is a normal occurrence is
    reasonable. I run DNS for several organizations, and changes to RR's with
    short TTLs are typically visible to most people within the span of those
    TTLs.

    --
    Richard Silverman
    res@qoxp.net


  11. Re: SSH'ing between machines with private IPs

    On 18 Apr 2006 23:10:56 GMT, in alt.internet.wireless , Unruh
    wrote:

    >Jeff Liebermann writes:
    >>>
    >>>Unfortunately the updates to the public routing tables are usually very
    >>>slow. A week is not uncommon.

    >
    >>Not exactly. I just added a new sub-domain to my dyndns.com account.
    >>About 3 minutes to get recognized by my ISP's nameserver. My DNS
    >>lookup initially went to the authoritative nameserver at dyndns.com
    >>for my domain and did the lookup. No big deal for sub-domains. As
    >>long as the resolver can find an authoritative nameserver for the
    >>domain, the updates are almost instantaneous.

    >
    >YMMV. I had a Telus ADSL and when they would change my routable address, it
    >usually took almost a week for the change to propagate to the University
    >where I work. I think that Telus put a long "stale date" on the DNS
    >address and/or the DNS caches here took a long time.


    The trick is not to rely on your service provider to update DNS
    records. I use a 3rd party DNS provider and an applet on my PC that
    checks the router WAN IP every 15 mins and updates my DNS entry
    appropriately.
    Mark McIntyre
    --

  12. Re: SSH'ing between machines with private IPs

    "Richard E. Silverman" writes:

    >>>>>> "Unruh" == Unruh writes:


    > Unruh> No All public routers throw them away precisely because of
    > Unruh> their problems. Sure, internally you may be able to route
    > Unruh> them,


    >Hence they are not "unroutable;" the term is a contradiction, period. It
    >makes no sense.


    Again, they are unroutable because the routers in between throw the packets
    away. They do not return them (whatever that would mean), they simply drop
    them. That is what I mean by unroutable.
    Now, it is certainly possible for routers to be set up not to do that, but
    that is not the general situation.

    > Unruh> So I repeat, private IPs are better called unroutable IPs.


    >The document which defines their use disagrees with you:


    Fine.


    > >> Besides, these address ranges are defined in RFC 1918, entitled
    > >> "Address Allocation for Private Internets," which refers explicitly
    > >> and repeatedly to "private address space" and "private addresses."


    >Interesting that you did not comment on this.


    What is to comment? I was not proscribing a term. I was saying that it is
    more useful for the user to think of them as unroutable. Ie, you cannot
    route packets over the internet to addresses in teh private ranges. Now,
    private can mean many things. People could well use addresses which are
    part of the assigned ranges privately and not give any hint that they exist
    to the outside world. That common sense of private is different from the
    technical sense used in the RFC, but non-the-less can cause confusion.
    Whereas unroutable I do not think does. It emphasises that they are
    addresses to which packets cannot be delivered over the net.


    >As for changes taking "weeks" for DNS changes to propagate: of course some
    >DNS servers behave incorrectly. I have run into ISPs which do this.
    >However, it is an exception, not the rule, as well as being nonstandard
    >behavior, and I don't think claiming this is a normal occurrence is
    >reasonable. I run DNS for several organizations, and changes to RR's with
    >short TTLs are typically visible to most people within the span of those
    >TTLs.


    I am giving experimental evidence. In the case of the telus AP, I have no
    idea what their TTL is, but it took a week for the new IP to propagate to
    the local university.
    In the case of the MX record, the TTL was hours, and three weeks later I
    was still getting mail delivered to the wrong IP. So, your systems may be
    set up properly. I was simply telling the OP not to rely on it.

    >--
    > Richard Silverman
    > res@qoxp.net



  13. Re: SSH'ing between machines with private IPs

    >>>>> "Unruh" == Unruh writes:

    Unruh> "Richard E. Silverman" writes:
    >>>>>>> "Unruh" == Unruh writes:


    Unruh> No All public routers throw them away precisely because of
    Unruh> their problems. Sure, internally you may be able to route
    Unruh> them,

    >> Hence they are not "unroutable;" the term is a contradiction,
    >> period. It makes no sense.


    Unruh> Again, they are unroutable because the routers in between throw
    Unruh> the packets away. They do not return them (whatever that would
    Unruh> mean), they simply drop them. That is what I mean by
    Unruh> unroutable.

    That's silly. Not all routers in the world do this; only some. Trucks
    are not allowed to drive on some roads. I suppose the trucks are
    "undrivable," then?

    In English, the construction "unable" means "cannot be ed."
    That's simply what it means; you can pretend it means something else, I
    suppose, but then you're Humpty Dumpty redefining "glory." You have
    alread agreed yourself that in some contexts, these addresses may be
    routed. These contexts are not rare; they are inside every *privately*
    numbered network (gee, there's that word again). Hence, they are *not*
    "unroutable." They are, in some contexts, unrouted. That is not the same
    thing.

    The most you can correctly say in this vein, would be "publically
    unroutable." Even that is suspect, since they certainly could be routed
    on the public Internet; it would just be a very bad idea.

    --
    Richard Silverman
    res@qoxp.net


  14. Re: SSH'ing between machines with private IPs

    On Mon, 17 Apr 2006 22:05:03 -0700, fcache wrote:

    > Hi,
    >
    > I have a workstation with a private IP address getting its signal from
    > a wireless AP that is behind a cable modem. I would like to SSH into
    > another workstation with a private IP address getting its signal from a
    > wireless AP that is behind a cable modem. Can I do this? If so, how?
    >
    > Thanx,
    > John


    Yes you can. If you are on the same network it is a complex matter
    of knowing the IP of the other machine, setting the firewalls to allow
    port 22, having an ssh server running on the other machine
    and on port 22 (default), and having an account on the other machine. If
    the 2 machines are on different networks then the router has to
    additionally allow port forwarding for port 22 as well as direct the
    incoming connection to the IP of the destination machine. I remotely
    connect to my network from another network this way.


  15. Re: SSH'ing between machines with private IPs

    "Richard E. Silverman" writes:

    >>>>>> "Unruh" == Unruh writes:


    > Unruh> "Richard E. Silverman" writes:
    > >>>>>>> "Unruh" == Unruh writes:


    > Unruh> No All public routers throw them away precisely because of
    > Unruh> their problems. Sure, internally you may be able to route
    > Unruh> them,


    > >> Hence they are not "unroutable;" the term is a contradiction,
    > >> period. It makes no sense.


    > Unruh> Again, they are unroutable because the routers in between throw
    > Unruh> the packets away. They do not return them (whatever that would
    > Unruh> mean), they simply drop them. That is what I mean by
    > Unruh> unroutable.


    >That's silly. Not all routers in the world do this; only some. Trucks
    >are not allowed to drive on some roads. I suppose the trucks are
    >"undrivable," then?


    >In English, the construction "unable" means "cannot be ed."
    >That's simply what it means; you can pretend it means something else, I
    >suppose, but then you're Humpty Dumpty redefining "glory." You have
    >alread agreed yourself that in some contexts, these addresses may be
    >routed. These contexts are not rare; they are inside every *privately*
    >numbered network (gee, there's that word again). Hence, they are *not*
    >"unroutable." They are, in some contexts, unrouted. That is not the same
    >thing.


    >The most you can correctly say in this vein, would be "publically
    >unroutable." Even that is suspect, since they certainly could be routed
    >on the public Internet; it would just be a very bad idea.


    Fine. I think this horse is dead, beaten, flayed, and the buzzards have
    left only bones.


    >--
    > Richard Silverman
    > res@qoxp.net



  16. Re: SSH'ing between machines with private IPs

    Jeff,

    So, couldn't I write a script that flushes the dns cache and then
    performs a direct dns query to one of the dyndns DNS server, and then
    have the remote workstation run the script before I attempt to SSH in?

    Thanx,
    Ed


  17. Re: SSH'ing between machines with private IPs

    You can switch, at least to try, from SSH to ViPNet. ViPNet VPN is more
    flexible the SSH to help you.
    www.vpnsolution.info


  18. Re: SSH'ing between machines with private IPs

    fcache@gmail.com hath wroth:

    >So, couldn't I write a script that flushes the dns cache and then
    >performs a direct dns query to one of the dyndns DNS server, and then
    >have the remote workstation run the script before I attempt to SSH in?


    I'm not sure what that would accomplish or what problem that would
    solve. The client on the other end of the SSH session is not
    registered in the internet DNS datapile unless you arrange for a
    dynamic DNS service provider (which is what I previously suggested).
    You could register a private domain and then create sub-domains for
    each machine. I've seen that done, and rapidly un-done when they
    discover that such DNS updates are not sufficiently fast to maintain
    connectivity. A DDNS service provider such as dyndns.com has clients
    that check for changes in IP every 5 minutes with short TTL (time to
    live) for their DNS records. My guess is that any change will be
    publicly available in perhaps 10 minutes. Try the same stunt with an
    ISP's DNS server and it will take a day or more. Of course, you could
    run your own public DNS server, which would give you more control, and
    probably solve the update delay problem. I know some corporations
    that do just that and do have all their workstations registered in
    sub-domains. I don't think the effort involved is justified for just
    a single SSH session. Keep it simple.

    Some details on DNS (which are only marginally relivent).
    You could easily flush your DNS cache on the workstation with:
    ipconfig /flushdns
    However, you cannot do that so easily if your routers (there are two
    in this system) cache DNS queries. The only way to do that on a cheap
    router is to power cycle the router. The solution is to just not use
    the DNS cache on the routers and point your clients DNS servers
    directly to the ISP's DNS server. Some routers have provisions for
    setting DHCP assigned DNS servers to fixed IP's other than the router
    itself. Some don't.

    If I read between the lines of what you're suggesting, your script
    will eventually provide the exact same functionality as a DDNS
    service. The remote client finds the WAN IP address of its router,
    http://checkip.dyndns.org
    and posts it to a web or ftp server. The other end picks up the file
    with the IP address, and uses that to connect to the remote client.
    That will work and is roughly how most do-it-thyself DDNS scripts
    function. I did exactly that using Unix shell scripts many years ago.
    May I humbly suggest you not reinvent the wheel and subscribe to a
    service that already has done battle with the learning curve.

    Incidentally, the most common screwup with DDNS is forgetting to
    disarm the XP and W2K DNS update mis-feature. See:
    http://www.dyndns.com/support/servic...s/faq.html#q28



    --
    Jeff Liebermann jeffl@comix.santa-cruz.ca.us
    150 Felker St #D http://www.LearnByDestroying.com
    Santa Cruz CA 95060 http://802.11junk.com
    Skype: JeffLiebermann AE6KS 831-336-2558

+ Reply to Thread