I have a Linux (Debian on ARM) box on a remote network (IP 192.168.150.100, subnet 255.255.255.0).
The Linux box is also running Hamachi VPN software, which has given it an address (5.50.60.177) that I can reach from desktop (via a local Hamachi install). I can therefore ping 5.50.60.177 and SSH to it.
I would like to route to the 192.168.150.x network via the working Hamachi connection. To that end I have enabled IP forwarding: $ cat /proc/sys/net/ipv4/ip_forward 1
.. and at the desktop end route -p add 192.168.150.0 mask 255.255.255.0 5.60.70.177 (desktop is Windows because the Hamachi VPN client was already running on it, but I don't think that's relevant to the problem).
I am unable to reach either my box via its local address (192.168.150.100) or the rest of the remote LAN.
What am I missing?
[IP addresses changed to protect the innocent.]
Mark
On 15 Oct 09:51, Mark Rogers wrote:
I have a Linux (Debian on ARM) box on a remote network (IP 192.168.150.100, subnet 255.255.255.0).
The Linux box is also running Hamachi VPN software, which has given it an address (5.50.60.177) that I can reach from desktop (via a local Hamachi install). I can therefore ping 5.50.60.177 and SSH to it.
I would like to route to the 192.168.150.x network via the working Hamachi connection. To that end I have enabled IP forwarding: $ cat /proc/sys/net/ipv4/ip_forward 1
.. and at the desktop end route -p add 192.168.150.0 mask 255.255.255.0 5.60.70.177 (desktop is Windows because the Hamachi VPN client was already running on it, but I don't think that's relevant to the problem).
I am unable to reach either my box via its local address (192.168.150.100) or the rest of the remote LAN.
What am I missing?
You'll probably also have to tell the linux box that it needs to MASQUERADE the packets going over that interface.
Assuming that your VPN interface is ppp0:
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Should do what you want and allow the packets to bounce around neatly.
On 15/10/12 10:09, Brett Parker wrote:
You'll probably also have to tell the linux box that it needs to MASQUERADE the packets going over that interface.
Assuming that your VPN interface is ppp0:
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADEShould do what you want and allow the packets to bounce around neatly.
No joy, unfortunately. (In my case the VPN interface is ham0.)
Thinking about it, I assume that it's possible that Hamachi blocks this? Is there any easy way to see whether packets are even reaching my box?
As an alternative, what's the quickest way to set up "port forwarding" so that (say) 5.50.60.177:443 goes through to the router at 192.167.150.250:443 so I can look at the VPN settings in the Draytek to see what's wrong?
Mark
Mark Rogers mark@quarella.co.uk
Thinking about it, I assume that it's possible that Hamachi blocks this? Is there any easy way to see whether packets are even reaching my box?
It's possible that Hamachi blocks this.
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.
Not sure about any easy way to see whether packets are even reaching my box, but things like wireshark or ngrep should show it.
As an alternative, what's the quickest way to set up "port forwarding" so that (say) 5.50.60.177:443 goes through to the router at 192.167.150.250:443 so I can look at the VPN settings in the Draytek to see what's wrong?
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
Hope that helps,
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
Mark Rogers mark@quarella.co.uk
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.
Yeah. Unless the remote router is the remote Hamachi endpoint or you can tell it to send packages for 192.168.200.0/24 out via it, then there's no way "to route to the 192.168.150.x network via the working Hamachi connection" because you also need a route back for the replies to reach you.
You'll need to do classic NAT / IP Masquerading, like Brett suggested.
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.
Right. I thought you wanted to see it by accessing https://5.50.60.177/ on other machines on your side of the network. Sorry for my confusion.
Establishing the connection from your desktop end is simpler. Just run ssh -L 443:192.167.150.250:443 SomethingThatCanSeeTheDraytek as root (for :443) and access https://localhost but it will complain about the certificate like this too:
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.
That's because socat only forwards one connection by default. Give it the fork option and maybe reuseaddr like in the man socat EXAMPLES section.
Hope that helps,
On 15/10/12 17:38, MJ Ray wrote:
That's because socat only forwards one connection by default. Give it the fork option and maybe reuseaddr like in the man socat EXAMPLES section.
Perfect, the following works like a charm:
socat TCP4-LISTEN:443,fork,reuseaddr TCP4:192.168.150.250:443
I really must use socat more often, it's a great "get out of jail free" tool.
Thanks for the help.
Mark
-
Brett Parker -
Mark Rogers -
MJ Ray