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.

Without knowing some more about the specifics of your IP addressing, I would guess that server 1 doesn't know that your workstation should be routed to through server 2.

If you add some more detail about your IP addressing scheme, especially in relation to the IP address that the HTTP requests from your workstation appear to come from, I might be able to expand this answer.

Update: Server 1's best guess as to how to get to 192.168.0.234 is via it's default route, which is wrong. You need to add a static route to 192.168.0.0/24 via server 2 on server 1.

route add -net 192.168.0.0 netmask 255.255.255.0 gw <server2>

I'm making assumptions about the network assigned by pptpd. Also, that route won't survive a reboot, so you probably want to add the route to a configuration file. Which file and what syntax depends on your distribution.