25

I've run into a bit of a puzzle and haven't had much luck finding a solution. Right now I am (sadly) connected to the net via Verizon 3G. They filter all incoming traffic so it is impossible for me to open ports to accept connections.

I currently have a Linux virtual machine at linode.com, and the thought crossed my mind to install pptpd and attempt to do some iptables port forwarding. I have pptpd installed and my home machine connects happily. That said, here's some general info:

Server (Debian) WAN IP: x.x.x.x on eth0 - pptpd IP: y.y.y.1 on ppp0 - Client VPN IP: y.y.y.100

To verify I wasn't going insane, I attempted some connections from the server to the open ports on the client, and the client does accept the connections via the VPN IP.

What I want to accomplish is this:

Internet -> WAN IP:Port -> Forward to Client VPN IP:Port

So for instance, if I had port 6000 open on my client, a person could telnet in to x.x.x.x:6000, and the server would catch that and forward it to 192.168.3.100:6000.

I have tried at least 20 different Googled up iptables configs and none have worked yet. Does anyone have any ideas, or perhaps even a totally different approach I might not be aware of? The goal here is to listen through a horribly firewalled connection, preferably both TCP and UDP traffic.

manatwork
  • 31,277
Vile Brigandier
  • 353

4 Answers4

29

You need to do three things on your VPN server (the Linode) to make this work:

  1. You must enable IP forwarding:

    sysctl -w net.ipv4.ip_forward=1

  2. Set up destination NAT (DNAT) to forward the port. You've probably already figured this out because it's standard port forwarding stuff, but for completeness:

    iptables -t nat -A PREROUTING -d x.x.x.x -p tcp --dport 6000 -j DNAT --to-dest y.y.y.100:6000

  3. Set up source NAT (SNAT) so that from your VPN client's perspective, the connection is coming from the VPN server:

    iptables -t nat -A POSTROUTING -d y.y.y.100 -p tcp --dport 6000 -j SNAT --to-source y.y.y.1

The reason you need the SNAT is because otherwise your VPN client will send its return packets straight to the host which initiated the connection (z.z.z.z) via its default gateway (i.e. Verizon 3G), and not via the VPN. Thus the source IP address on the return packets will be your Verizon 3G address, and not x.x.x.x. This causes all sorts of problems, since z.z.z.z really initiated the connection to x.x.x.x.

In most port forwarding setups, the SNAT is not needed because the host performing the port forwarding is also the default gateway for the destination host (e.g. a home router).

Also note that if you want to forward port 6000 to a different port (say 7000), then the SNAT rule should match on 7000, not 6000.

AGWA
  • 579
  • 1
    Hello AGWA,

    Thanks for the response. I already had ip_forwarding on, and your rules worked perfectly, although not initially. The issue was (in my iptables noobness) that I didn't realize iptables -F didn't flush the nat entries, and iptables -L wasn't listing them. After figuring out how to properly list them I noticed several conflicting entries from tries before. After flushing and trying your rules, it works perfectly.

    One quick question though, in your rules you specify tcp. Would changing this to "all" work for both TCP/UDP traffic?

     – Vile Brigandier Nov 15 '12 at 22:24
  • You're welcome! (By the way, I like using iptables-save to show my iptables rules - while the output isn't intended for human consumption it's still readable and shows all your iptables rules.) No, unfortunately you can't use "all" there, because --dport only works with protocols that actually have ports ("all" would include e.g. ICMP, which has no notion of ports). You'll need separate rules for TCP and UDP. – AGWA Nov 15 '12 at 22:42
  • Thanks for the iptables-save tip. Everything works as expected for both TCP and UDP. Cheers. – Vile Brigandier Nov 16 '12 at 05:07
  • 2
    Just an update to this answer is that with iproute2, you can actually setup your VPN client to have 2 gateways and route DNAT traffic back over the VPN. This is beneficial if you don't want to use SNAT and have all the traffic appear to be coming from the vpn server. http://www.thomas-krenn.com/en/wiki/Two_Default_Gateways_on_One_System includes information on how to set this up. – PressingOnAlways Dec 25 '14 at 02:37
  • Works for me as long as ufw is disabled, even though i have allowed 8080 in ufw, but as soon as i enable ufw, this forwarding stuff doesnt work.. any idea ? – Sudhir N Sep 25 '16 at 11:33
4

I also had this problem and tried to solve it for hours.. Here is my solution:

  • I had more than one VPNClient with the same IPAddress. So I gave each of them a static IPAddress

Define a directory where the client scripts should be stored , e.g. /etc/openvpn/staticclients and create the directory

mkdir /etc/openvpn/staticclients

Add this directory as option to your openvpn configfile at the server:

client-config-dir /etc/openvpn/staticclients

For each client you have to create a file. The filename must match the common name attribute that was specified at the certificate of the client. This command gets the CN from the computers certificate:

This example pushs the IPAddress 10.1.134.110/10.1.134.109 to the Client with the common name TESTCLIENT and also pushes a additional route for subnet 10.1.135.0.

cat /etc/openvpn/staticclients/TESTCLIENT

ifconfig-push 10.1.134.110 10.1.134.109
push "route 10.1.135.0 255.255.255.0 10.1.134.62"

sysctl -w net.ipv4.ip_forward=1

iptables -t nat -A PREROUTING -p tcp --dport 28006 -j DNAT --to 10.1.134.110
Dominic Jonas
  • 151
2

Most servers have ip forwarding disabled in default configuration. You need to enable it if you want to redirect incoming connections through your VPN.

Try this:

sysctl -w net.ipv4.ip_forward = 1

I mean in addition to iptables configuration.

Andrey Voitenkov
  • 226
0

What you want to achieve is (probably) very possible with pptpd or OpenVPN and iptables, however, you might find tinc a better candidate for this use case. I just read this which describes how to setup tinc for exactly this use case. It's a (potentially simpler) alternative to the pptdp or OpenVPN part. Then you'd need exactly the same rules for iptables.

chmac
  • 130