>>>>> "Eric" == Eric House <[email protected]> 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@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@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 [email protected] _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
