Trying to connect to servers in a remote lan with softether vpn client and iptables nat ip_forwarding

Question

I have implemented a softether vpn server on one aws server connected to other instances in a LAN. I can ssh into the server with ssh myname@10.0.1.10 without problem. I followed this guide

My goal is to allow me to access remote aws servers on a LAN with ssh myname@hostname.mydomain.com or http://hostname.domainname.com from my laptop using the vpn. ssh is now working but I can't figure out how to get a web page. My reason for wanting a web page through a vpn is that the website is an admin backend which I want to limit access to users coming from the vpn IP addresses.

I added net.ipv4.ip_forward = 1 to sysctl and

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT

route add -net 10.0.0.0/8 gw 10.0.1.10

ifconfig -a

vpn_tun0  Link encap:Ethernet  HWaddr 00:ac:a3:58:1f:78  
inet addr:10.0.1.11  Bcast:10.0.1.255  Mask:255.255.255.0
inet6 addr: fe80::2ac:a3ff:fe58:1f78/64 Scope:Link

netstat -nr

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth0
10.0.0.0        0.0.0.0         255.0.0.0       U         0 0          0 vpn_tun0
10.0.1.0        0.0.0.0         255.255.255.0   U         0 0          0 vpn_tun0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

on the server in vpnserver:

DhcpTable

ID              |21
Leased at       |2015-06-08 (Mon) 08:49:46
Expires at      |2015-06-08 (Mon) 14:23:06
MAC Address     |00-AC-A3-58-1F-78
Allocated IP    |10.0.1.11
Client Host Name|Inspiron-1564

on my laptop vpnclient

VPN Client>accountlist
AccountList command - Get List of VPN Connection Settings
Item                        |Value
----------------------------+----------------------------------------------------
VPN Connection Setting Name |my_connection
Status                      |Connected
VPN Server Hostname         |hostname.domainname.com:5555 (Direct TCP/IP Connection)
Virtual Hub                 |lan-internal
Virtual Network Adapter Name|tun0

Answer 1

Ok, so following on from https://superuser.com/questions/923747/vpn-ip-forwarding-and-nat/925570#925570 I have what may be a really stupid question to ask, but if all you need is access to specific ports, like http/https have you tried SSH Tunneling? It's much easier than setting up a VPN. Ultimately you ssh from one machine to another, and then have the target machine establish an onward connection to something, and have that connection forwarded back to your local machine.

So say you can access the public (DMZ) part of a machine A.A.A.A which can in turn access a private machine B.B.B.B, and you want to connect to a HTTPS service (port 443), and assuming your desktop already has a service running on 443, so you're going to have the service listen locally on 4443.

   ssh -L4443:B.B.B.B:443 adminuser@A.A.A.A

Then login, and run up a local browser and go to https://localhost:4443 or if you like, add an entry to your hosts file, sending 127.0.0.1 to intended.vhost.name and then go to https://intended.vhost.name:4443/

If you REALLY need a vpn, then...

Can you ping both the IP address of the local and opposite sides of the tunnel from your laptop? Can you ping a different machine on the opposite site network? If you can't try tracerouting it, and see if you get an echo back from the local and remote sites of the tunnel (if not, your routing is wrong).

What are the various network addresses? You might try telling route, which device you're expecting it to send traffic on, otherwise it has to be able to infer.

I was re-reading this and thought I'd add some notes that might make it easier for anyone trying to follow what I suggested:-

To make it possible to access https://intended.vhost.name:4443/ and have that tunnel, you need to add an entry to your hosts file. On linux thats /etc/hosts on Windows it's c:/windows/system32/drivers/etc/hosts Either way you'll need admin privileges to save the file (sudo for linux, open notepad as administrator on windows). Then add the following line:-

127.0.0.1        intended.vhost.name

The other thing I mentioned was setting up a listening tunnel on a machine, which can punch a hole through a firewall. As discussed earlier running ssh -L4443:B.B.B.B:443 adminuser@A.A.A.A will open an ssh terminal on machine A.A.A.A, and while so doing, will tunnel traffic from local (the -L) port 127.0.0.1:4443 to B.B.B.B:443 (the 127.0.0.1 is implied). Assuming your local machine is C.C.C.C and you want to open port 4443 on that IP, for other machines to access you can do this:-

ssh -LC.C.C.C:4443:B.B.B.B:443 adminuser@A.A.A.A

It's worth noting here that if you add a -T parameter, you change the behaviour of ssh, to open the ssl connection, then the tunnel and not start the terminal within it.

When I've done this before, I setup a user on the local machine (lets say tunneluser) and create a set of ssh keys for him in ~tunneluser/.ssh then ensure the file ~tunneluser/.ssh/id_rsa.pub is listed in the remote machines ~adminuser/.ssh/authorized_keys then the ssh connection will start without prompting for a password. As a security feature, you can setup tunneluser remotely, with /bin/false as his shell (in /etc/passwd) then the connection will fail if you miss the -T parameter.

A simply way to implement that is to include it in a script in /etc/init.d that is run after networking (usualling in rc3.d). I would suggest a layer of security though (avoid running it as root) using

sudo -u tunneluser "ssh -T -i/home/tunneluser/.ssh/id_rsa.pub -LC.C.C.C:4443:B.B.B.B:443 tunneluser@A.A.A.A"

Note though, that if the IP you want to listen on (the :4443 listed above) is a 'privileged port' (ie it's amongst the range normally used by system services), you'll need to run ssh as root, to get permission to listen there.

Any window user then need simply access https://C.C.C.C:4443 and they would see the site that was on https://B.B.B.B:443.

If the machine at C.C.C.C doesn't have a service blocking :443, use that instead of :4443 and https://C.C.C.C would be equivalent to https://B.B.B.B

As an aside, if the intention is reversed, say you're on a machine with access to C.C.C.C you want to punch a hole through the DMZ via machine A.A.A.A such that users that can access B.B.B.B, can access C.C.C.C via tunnel, without being able to access it directly, you use -R instead of -L (and the listening socket is at the Remote, rather than Local side of the tunnel). I include -T to show how it's used.

ssh -T -RB.B.B.B:4443:C.C.C.C:443 adminuser@A.A.A.A

Answer 2

There is no difference in the routing needed for ssh and http. Both are running over TCP and are playing no tricks with the underlying IP traffic.

According to your question both are using the same hostname, but you did not mention whether that hostname resolves to just one or multiple IP addresses. Using the telnet command you can verify if a connection can be established to both port 22 and port 80 on the server. It will also tell you along the way which IP address it is connecting to.

From the question I can see that you are running your ssh and http servers on the very same hostname as your VPN server. That could be a problem. The real problem here is not so much that they are using the same hostname, but rather that they are using the same IP address. Even if you used different hostnames pointing to the same IP address, it could still be a problem but then the different hostnames would obscure the source of the problem.

The reason it can be a problem to connect to a service on the same IP as the VPN server has to do with routing. The problem is that if a routing table entry directing traffic through the VPN also covers the IP address of the VPN server, then packets to the VPN server are not send over the network but to the VPN interface. This will introduce a routing loop where each time a packet goes round the loop it will get encrypted one more time and grow a little larger, but it will come no closer to the destination.

One solution that some VPN solutions use to avoid this is that a routing table entry covering only the IP of the VPN server is created before making any other changes. That way traffic to the VPN server will never go through the VPN. But traffic to any other services hosted on the very same IP will also never go through the VPN.

The simplest solution to this is to use two different IP addresses to access VPN and other services hosted on the same box. Usually a VPN server will have enough IP addresses assigned to it, that there is another IP address, which could be used for this purpose.

So why would it work for ssh and not http? The information in your question points to one possible reason.

You mention that you want to limit the http service to only be accessible to users connecting from a VPN IP address. If you already have those filters in place, that may be the reason. The connection is simply not going through the VPN connection and thus gets blocked by the filters. The reason it would then work when using ssh rather than http could be that sshd is configured to allow connections from any IP address and not just the VPN range.

Another possible explanation is that the ssh and http services are not bound to the same IP address. Maybe ssh is bound to the any address and http is bound to only one specific address.

Those two reasons is by no means a complete list of possible explanations, but simply those which sound most likely given the information in your question.