Linux – Allow GRE (IP protocol 47) over Linux router NAT for a subnet

greiptableslinuxnat;

I have network setup as shown below:

The VPN server running is windows 2012 server default VPN, which uses GRE protocol. I am able to have VPN connection to that remote vpn server, from my intranet single IP only. But I am not able to connect for range of intranet IP 172.16.14.0/24. The problem is with linux router, which is doing NAT.
My iptable for nat table looks like this for working vpn connection (for single IP), allowing gre protocol:

 iptables -I PREROUTING -t nat -p 47 --src 202.xx.yy.abc  -j DNAT --to-destination 172.16.14.15
 iptables -I POSTROUTING -p 47 -t nat --src 172.16.14.15  -j SNAT --to-source 202.xx.yy.zz
 iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE 
 iptables -A INPUT -p 47 -j ACCEPT

This rule works fine for single IP 172.16.14.15. How can I make this works for whole 172.16.14.0/24 range so that I can have VPN connection to the remote VPN server ?

Best Answer

I found the solution.

I did this:

 sysctl -w net.netfilter.nf_conntrack_helper=1

Then add

modprobe ip_nat_pptp

I was using Ubuntu 18.04.2 LTS, kernel version 4.15.0-45-generic. There was no need to do anything related with GRE protocol inside iptables PREROUTING, POSTROUTING tables. Adding just above two lines worked.

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.

IPTables: NAT multiple IPs to one public IP

You can't do 1-to-1 NAT with only 1 outside IP address when you're working with 2 internal hosts. The reason is because the firewall will never have a true destination for outside source connections, unless one of the internal hosts is down. In this case, you would require 2 iptables rules to provide round-robin functionality:

$ipt -t nat -A PREROUTING -s $srcip -d $wanip -j DNAT --to 192.168.1.2
$ipt -t nat -A PREROUTING -s $srcip -d $wanip -j DNAT --to 192.168.1.3

Also, your "DNAT: Multiple --to-destination not supported" error comes from the capability of specifying more than 1 DNAT destination being removed from the version you're running (v1.4.14). This functionality was removed in favor of the round-robin functionality.

If you want to allow multiple hosts a connection to the internet, you must use the POSTROUTING chain of the NAT table as follows:

$ipt -t nat -A POSTROUTING -o $wanif -s $lan_network -j MASQUERADE

MASQUERADE is used with dynamic IP configurations. For static IP, use SNAT in place of MASQUERADE:

$ipt -t nat -A POSTROUTING -o $wanif -s $lan_network -j SNAT --to $wanip

This will not, however, make the open ports on your internal hosts available to the outside world. DNAT is used for outside->inside and SNAT is used for inside->outside for basic scenarios like yours.