You're sending the traffic to 10.52.208.221. Given the config you posted, your problem is the webserver, not the firewall. Your rules look to be correct. FORWARD and INPUT are redirected to RH-Firewall-1-INPUT where your first rule is to allow all traffic. As somebody else pointed out, you could be allowing all traffic on eth1, while the world is actually coming in eth0. Secondary, you have to NAT the traffic as it goes back out to the world
iptables --table nat --append POSTROUTING --proto tcp --dport 80 --jump MASQUERADE -o OUT_INTERFACE
Your traffic originating from the router will never hit the input or forward chains, but instead traverse the output chain on to the webserver. Other systems in that subnet will similarly go directly to the webserver. Systems out on the world at large however will traverse the INPUT / FORWARD chains and need SNAT as well as DNAT so that it appears to the world to be one machine. You still cannot test from within your network. you must test from the opposite interface from the webserver. Get me your IP addresses and I'll point you to the proper configs.
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.
Best Answer
I recommend you do this
eth0 is your "public interface"
active routing
set nat to redirect requests to internal ipsec server