On 15/10/12 13:34, MJ Ray wrote:
It's also possible that each "side" of the Hamachi VPN has a different IP address, so the route commands on each side would be slightly different.
I don't think this is the case (but I'm no expert here!).
Remote end (on the remote LAN that I want to connect to): 5.50.60.177 is the address I SSH to, and is also the address that the remote end reports in ifconfig. My end: 5.70.80.21, which is also confirmed by ipconfig (Windows) and I can ping it from the remote end.
Remote end subnet is 192.168.150.x - that's what I'm trying to reach. My local IP is 192.168.200.180.
I think I may confused things by mentioning the Draytek in passing. Both ends have Draytek routers; my office has a static IP (the remote end doesn't on the external side) so the remote Draytek is configured to establish an office-to-office VPN to my local draytek, although that's at best intermittent and slow at the moment, but the Hamachi connection is rock solid and fast. Therefore I want to use the Hamachi VPN to allow me to access the 192.168.100.x subnet to diagnose the problem with the Draytek VPN connection.
ssh tunnels are quickest: as root (because you want :443) on 5.50.60.177, ssh -L 5.50.60.177:443:192.167.150.250:443 SomethingThatCanSeeTheDraytek
With the above comments in mind, I'm a bit confused here. 5.50.60.177 can see its local Draytek already (at 192.168.150.250), but in order to use its web interface I need access from my desktop end (the remote box is headless and won't run anything more sophisticated than Lynx, which the Draytek doesn't seem to work with). Therefore I need to establish the connection from my desktop end.
I figured that (at the remote end): socat TCP4-LISTEN:443 TCP4:192.168.150.250:443 .. would work, and I think that maybe it does get me closer, but when I go to: https://5.50.60.177 .. Firefox gives me a certificate warning but seems unable to download the certificate and therefore won't let me past, and Chrome under the same circumstances causes socat to die.
(I'd still prefer the general IP forwarding as that would be a general solution for access to the remote LAN but for now I'd settle for either!)
Mark