On Saturday 10 January 2009 22:48, you wrote:
I am confused by your description. Do you mean you have Machine A and Machine B and you want to be able to access both of them at any time over the next three years from Machine C but you could be behind a firewall with machine C i.e. I assume you will be traveling and that's the reason so you never know what network you will be coming out of?
No, the main problem is that A is behind my ISP's NAT. I want to access it from C (yes, I'll be travelling a lot and C might be just about anywhere). But the problem is that since A is behind a NAT, the connection must be initiated from A's side to C. Also, since C might be behind some other NAT, the connection must be initiated from C's side to A. This simply cannot work simultaneously, so I tried to make use of my public server B which can be used as a "bridge" between A and C. So, A connects to B, C connects to B, and then A and C communicate. Roughly speaking...
That was my initial idea, but seems too complicated to work out, so I asked for a possible easier alternative. :-)
Or if want your own set up you could of course for example run some sort of remote access service like VNC and just pay for a static IP for Machine A from its ISP and set up Port Forwarding for VNC
That would be the most obvious solution, if only the ISP were willing to give me a static IP. But they are not. :-(
(or if you don't want to pay use http://www.no-ip.com/ and use their free dns service where you can create a free dns name for use with dynamic ip's. You just install their software on Machine A and it will login to No-IP.info and check your ip is still current and if not update it like if your IP changes because your dsl line drops for a minute and you get a knew ip?).
Hmmm... This is interesting. I'll look up to www.no-ip.com, but I think that such dns trick may work only with public IP numbers. And A's IP is of type 10.0.*.* which is a no-go, afaik.
However, I might ask the ISP to provide me with a public IP. It could still be dynamic, but public rather than local, and in that case the trick with the dns just might work... ;-)
Thanks for the pointer!
Best, :-) Marko
That was my initial idea, but seems too complicated to work out, so I asked for a possible easier alternative. :-)
Might be to easy an alternative.
No, the main problem is that A is behind my ISP's NAT. I want to access it from C (yes, I'll be travelling a lot and C might be just about anywhere). But the problem is that since A is behind a NAT, the connection must be initiated from A's side to C. Also, since C might be behind some other NAT, the connection must be initiated from C's side to A. This simply cannot work simultaneously, so I tried to make use of my public server B which can be used as a "bridge" between A and C. So, A connects to B, C connects to B, and then A and C communicate. Roughly speaking...
That was my initial idea, but seems too complicated to work out, so I asked for a possible easier alternative. :-)
Or if want your own set up you could of course for example run some sort of remote access service like VNC and just pay for a static IP for Machine A from its ISP and set up Port Forwarding for VNC
That would be the most obvious solution, if only the ISP were willing to give me a static IP. But they are not. :-(
(or if you don't want to pay use http://www.no-ip.com/ and use their free dns service where you can create a free dns name for use with dynamic ip's. You just install their software on Machine A and it will login to No-IP.info and check your ip is still current and if not update it like if your IP changes because your dsl line drops for a minute and you get a knew ip?).
Hmmm... This is interesting. I'll look up to www.no-ip.com, but I think that such dns trick may work only with public IP numbers. And A's IP is of type 10.0.*.* which is a no-go, afaik.
However, I might ask the ISP to provide me with a public IP. It could still be dynamic, but public rather than local, and in that case the trick with the dns just might work... ;-)
Thanks for the pointer!
Best, :-) Marko
I see now. Well in this case I would defiantly recommend something like www.logmein.com then. All you need is http (tcp port 80) access out, so web access and your sorted, from anywhere in the world! Just goto www.logmein.com from Machine A and install the free version. Then login from Machine C and connect back to your machine A and take it over!
Or as you mentioned you could set something up like a crontab that runs every 15 minutes and ssh's (using passwordless ssh, as in public/shared keys?) to your static Machine B and look for a flagfile, and if its found keep the connection open to tunnel through from Machine C back to Machine A via static Machine B?
HTH and good luck!
Regards, James ;)
-----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT/MU/U dpu s: a--> C++>$ U+> L++> B-> P+> E?> W+++>$ N K W++ O M++>$ V- PS+++ PE++ Y+ PGP t 5 X+ R- tv+ b+> DI D+++ G+ e(+++++) h--(++) r++ z++ ------END GEEK CODE BLOCK------
the connection must be initiated from C's side to A. This simply cannot work simultaneously, so I tried to make use of my public server B which can be used as a "bridge" between A and C. So, A connects to B, C connects to B, and then A and C communicate. Roughly speaking...
That was my initial idea, but seems too complicated to work out, so I asked for a possible easier alternative. :-)
Easy. John R Pierce's idea works no problem. Just do it the other way round for A.
A will run ssh (or putty) and connect to B with a ssh key and do port forwarding.
So instead of ssh -L as suggested by John, do the equivalent of ssh -R on A.
Then your problem will become: how do I secure B:3389 against unauthorized connections. Again, ssh (or putty) on C -> B to the rescue.
Back to John's suggestion. C will do ssh -L and B will firewall all access to port 3389 except from localhost.
A ssh -R3389(or whateverA):localhost:3389 | | |/
B
/|\ | | C -L3389(or whateverB):localhost:3389(or whateverA)
rdesktop or Remote Desktop on C connections to localhost port 3389 (or whateverB)
On Monday 12 January 2009 04:13, Christopher Chan wrote:
the connection must be initiated from C's side to A. This simply cannot work simultaneously, so I tried to make use of my public server B which can be used as a "bridge" between A and C. So, A connects to B, C connects to B, and then A and C communicate. Roughly speaking...
That was my initial idea, but seems too complicated to work out, so I asked for a possible easier alternative. :-)
Easy. John R Pierce's idea works no problem. Just do it the other way round for A.
A will run ssh (or putty) and connect to B with a ssh key and do port forwarding.
So instead of ssh -L as suggested by John, do the equivalent of ssh -R on A.
Then your problem will become: how do I secure B:3389 against unauthorized connections. Again, ssh (or putty) on C -> B to the rescue.
Back to John's suggestion. C will do ssh -L and B will firewall all access to port 3389 except from localhost.
A ssh -R3389(or whateverA):localhost:3389
|/
B
/|\
C -L3389(or whateverB):localhost:3389(or whateverA)
rdesktop or Remote Desktop on C connections to localhost port 3389 (or whateverB)
Hmmm, I see... Yes, this seems doable/possible, indeed. I am just not too confident in WinXP ssh capabilities. I mean, putty could do it, but it also needs to keep the connection alive through the NAT/firewall in front of A, and survive across reboots, without hickupps :-). But I guess this can also be arranged without much trouble.
Up to now I wasn't aware of -L and -R options of ssh, they are actually very powerful when used in combinations like this.
Anyway, I found that openvpn would suit all my needs, and this seems to be an equivalent alternative. Maybe I'll implement both openvpn and this, to have a backdoor if openvpn fails for whatever reason.
Thanks for help, this is very useful ! :-)
Best, :-) Marko
-
Christopher Chan -
James Bensley -
Ken Godee -
Marko Vojinovic