[PLUG] Seeking a port-forwarding vpn server recipe

[Russell Senior]

>>>>> "Eric" == Eric House <eehouse at eehouse.org> writes:

Eric> I've been googling for what ought to be a commonly sought server
Eric> config recipe without luck and hope the group has some ideas --
Eric> for search terms if nothing else.

Eric> I'm evaluating a new ISP (Webpass, down in the Bay Area). They're
Eric> fast and cheap, the latter in part because they don't pay for a
Eric> public IP address for every customer. They wire buildings, and put
Eric> everybody in the building behind a NATting router with a single
Eric> public IP address. No ports are forwarded, so you can't SSH in
Eric> from work when you forgot something or just want to see what that
Eric> the kids are browsing. :-)

Eric> It's new for broadband providers to be doing this, but colleges
Eric> have been doing it for their dormitories for a decade. There must
Eric> be solutions described out there. My proposed solution is to run
Eric> an AWS instance (or some other cheap virtual host with a public IP
Eric> address), install an openvpn server there, connect an openvpn
Eric> client on my router to that server, and then configure the virtual
Eric> host to forward all ports and protocols to the router via the
Eric> openvpn tunnel. I think the cost of running the instance will be
Eric> less than the difference between what Webpass and Comcast
Eric> cost. And the Webpass people are much less rude.

Eric> Has anybody seen, or can anybody find, a description of how to set
Eric> this up? (The openvpn stuff's easy; port forwarding less so.)
Eric> Alternatively, is there a better way to accomplish the same thing?

This sounds vaguely like something I did for the Nike Community Garden
Smallest Federated Wiki project with Ward.  The problem is you need
network address translation in two direction.

In our case, we had a device out in a field behind a NAT that we didn't
control, but we wanted a public IP addr/port to redirect to that server,
something like this:

HOST A            HOST B           HOST C                   HOST D
local [OPENVPN]___ local ___8888___public[OPENVPN]___8888___public
server[CLIENT ]   gateway   8888   server[SERVER ]   8888   client

pardon the ASCII art, and please use a fixed-width font to improve
comprehension ;-).

You want host D to be able to connect to host C's public ip address/port
and have that get to your local server at host A, when you don't control
host B.

You need to forward the port from C to your server A.  That's the
classic port forward rule, on host C (assuming your VPN is functioning):

  root at C:~# iptables -t nat -I PREROUTING -p tcp -i $PUBIFACE -d $PUBIPADDR --dport $PUBPORT -j DNAT --to $A_IPADDR:$A_PORT

The tricky bit is that the DNAT does not alter the source ip address of
the inbound packet, and the default route on A for host D on the public
internet is not through the tunnel, which means that packets returning
to host D will get routed to host B and then get host B's public IP
address, which will make no sense when they arrive at host D, where it
is expecting a source address of host C, where it sent the SYN packet.

The basic rule is that whenever network address translation occurs, you
need to ensure that both directions are using the same translating
gateways or the return path won't be able to undo the translation
properly.

A solution is to do an additional address tranlation at host C, on the
inbound packet (D->A).  Something like:

  root at C:~# iptables -t nat -I POSTROUTING -p tcp -o $VPNIFACE -m tcp -d $A_IPADDR --dport $A_PORT -j SNAT --to $C_VPNIPADDR

This matches packets that are heading to A, and applies the Source NAT
to make it look like they are coming from host C's VPN IP address.

A downside is that host A won't be able to log the real IP address of
host D, because it got tranlated away by host C, but it will ensure that
the returning packets (A->D) will go to host C (which will recognize the
connection and translate the destination back to D).

Make sense?


-- 
Russell Senior, President
russell at personaltelco.net