You really have two possible ways to go here.
1. Use an SSH Tunnel instead
Get rid of all the PPtP VPN stuff, and use an SSH tunnel instead. Assuming you can SSH to your machine, you won't need to set up anything else or perform any kind of reconfiguration that might break anything.
You didn't specify what operating system you're using on your client, but I assume you're using either PuTTY on Windows or OpenSSH on some other OS (Mac OS X, Linux, etc).
On PuTTY on Windows you would go into SSH->Tunnels, and adding a forwarded port, for example source = 6084, destination = 20.35.166.61:6084 and then connect to the server. (It's helpful to save a profile to save you from setting that up every time.)
With OpenSSH you'd so something like ssh -L 6084:20.35.166.61:6084 yourusername@71.185.153.102 (yourusername@ may be ommitted if it happens to be the same as your local username on your computer).
You should then be able to access the remote web server using http://127.0.0.1:6084. Some web applications won't like you using a different IP address and will break links. In some cases, it will be sufficient to add the hostname to the secure server to your hosts file (C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS on Windows, /etc/hosts on OS X, Linux, and other similar OSes) - with an IP address of 127.0.0.1. This will of course break things if you try to do anything else but connect to port 6084 on that particular hostname, or if the ssh session isn't up.
An alternative to tunneling a single port, is to use "dynamic SSH tunneling" which means that the ssh client emulates a SOCKS proxy. In this mode, you'd do something like ssh -D 3128 yourusername@71.185.153.102 (with OpenSSH) or, using PuTTY, selecting a "dynamic" tunnel with 3128 as the source port (you don't need to specify a destination). You then configure your web browser with 127.0.0.1:3128 as your SOCKS proxy, and bam - all your web browser traffic will be redirected through your server. This includes any other web traffic from your machine though, so take care if that's not what you want. Also, it means your web browser will stop working once your SSH tunnel is down.
2. Fix your PPtP tunnel
You seem to have enumerated a few specific problems.
1. The VPN disconnects after a few minutes.
This is probably because of a firewall with stateful packet inspection (such as your garden variety "broadband router") somewhere between you and the server causing a connection to time out. Depending on the make and model of this firewall you may be able to increase your timeouts. As a workaround you might want to set the set link keep-alive option in PoPToP to something low enough to make sure the sessions don't expire.
2. Your Internet connection stops working when connected.
This is because when connecting your VPN, your "default route" will be set to go via the VPN connection. I.e. it's going to try to send your internet traffic via your server. Unless you set up source NAT, traffic that exits the server onto the greater internet will have an IP between 192.168.0.100-200 as its source IP, and while your packets may get to your destination, you have no way of knowing because the remote host has no way of sending your traffic back to your non-routable IP address.
There are a few possible solutions to this problem:
- Set up NAT on the server so that the source address for any traffic exiting the VPN is the same as the IP address of the server's Internet-facing network interface.
- Use public IP addresses rather than private IP addresses and set up routing accordingly (probably impractical in your scenario)
- Don't route traffic to the Internet via the VPN in the first place - you haven't specified what VPN client you're using so I can't help you with that really. PoPToP might have the capability to "push" routing configuration to the PPtP client, but I'm not sure how. Check out some documentation. But most likely you can fix this at the client side.
3. You cannot reach the remote server
This isn't working for the same reason your Internet connection stops working - the packets may well be reaching their destination, but the remote server has no way of sending packets back to you.
Possible solutions are:
- Make sure the remote server has your VPN in its routing table. (I suspect this might not be feasible in your case, I have a feeling you don't administer the remote server, and the remote admin may well be unwilling to add a route to a private IP range...)
- Use source-NAT to translate the source IP address of packets exiting via the VPN.
The key question here is, "Did you try the VPN yet?" Everything seems fine. If your FreeBSD box can already route to the remote side of the VPN, your job is almost done. That means that the connection is valid and it is aware of the route to the remote network.
The host behind the router shouldn't require any changes at all to communicate "through the VPN." If it has the router set as its default gateway, then all traffic to remote networks (including the other side of the VPN) should go through the router, which as we stated, is already aware of the appropriate route. If you want to be very explicit, add a static route to the routing table of the host in question to ensure that it is aware of the correct route to the remote side of the VPN.
Best Answer
Having set up IPSec in a simple tunnel mode between two hosts once, I swore I would try and stay away forever. In terms of alternatives to IPSec/IPSecuritas, you might want to investigate setting up a PPTP VPN, as Mac OS X (and other major operating systems) contain a PPTP client built-in. There are two good options for PPTP servers on FreeBSD:
net/mpd5- my preferred option, based on the netgraph frameworknet/poptop- the standard choice, available on Linux as wellOpenVPN is also a possibility, although I've never used it on Mac OS X and so can't comment on ease of set-up. A quick web search reveals a few GUI clients, so that might be worth investigating.