How to best tunnel public Class-C net and browse through NAT out the WAN link…
-
Just to make it clear: this question relates to pfSense 2.0, since earlier versions don't support some of the things I need anyway.
Basic setup: a public class-C network without a local ISP willing/capable of routing it at anything close to reasonable cost. All addresses of machines in the LAN are publicly routed and belong to that class-C net
Solution: tunneling all the class-C related traffic to a co-hosting provider that will have a second pfSense box that will act as the gateway for the class-C network
Minor details: a variety of IPSec VPN links to private client networks, a guest LAN segment, VoIP devices
Desired: casual browsing is faster and VoIP has lower latency if it's not forced to go through the tunnelQuestion 1: what is the lowest overhead or for other reason best solution to tunnel the class-C between the devices on the LAN and the box located at the colocation service provider? pfSense offers a bunch of potential means to tunnel that traffic, and I need some rationale to decide what to use (openVPN, GRE, PPTP, etc.)
Question 2: what's the best way to send LAN originated web traffic through NAT and directly out over the local ISP? (policy routing, load balancing with some rules, web proxy, etc.)
Question 3: is there a way to use NAT for traffic that then is shoved through a IPsec tunnel? e.g. if I have a IPSec tunnel to a client where the remote LAN is 10.0.1.x and the local LAN is supposed to be 10.0.2.x, but the real addresses on the LAN are 12.34.56.x is there a way to alias 12.34.56.x to 10.0.2.x as traffic enters/exits the IPSec tunnel? (I can do this with my ZyWALL, but that thing is otherwise woefully inadequate)
All of this should be compatible with a separate guest LAN which will be NATed out directly to the local ISP, and preferably also with the FreeSwitch VoIP and DynDNS for the primary WAN interface.
Any help appreciated…
-
1: GRE would have the lowest overhead, but wouldn't be encrypted. OpenVPN would offer the best of both worlds, but would have some overhead.
2: Simple policy routing will do. Have a rule that passes out from your LAN to * on http/https with no gateway set, and a rule underneath that catches the rest and passes out anything else to the gateway for the VPN (If you assign an OpenVPN instance as an interface you can create a gateway for the other end and use it in policy routing, GRE may allow the same)
3: You can't do NAT+IPsec.
-
Thanks for the answer…
3: You can't do NAT+IPsec.
I assume you mean you can't NAT the IPSec addresses, not you can't use IPSec if you use NAT, right?
If so, could I get around it with an extra set of interfaces: bind one interface e.g. to 10.0.2.1 assuming that that's what mu IPSec address is, and then run a cable to another interface which has many-to-many NAT, and maps 10.0.2.x to 12.34.56.x
After all, I have enough USB ports to stick in an extra pair of USB ethernet interfaces…
-
3: You can't do NAT+IPsec.
I assume you mean you can't NAT the IPSec addresses, not you can't use IPSec if you use NAT, right?
Correct. You can't do NAT on the IPsec interface, to be more specific.
Some people have got around that by putting another router on the LAN that connected to a separate interface on the main router for the "translated" subnet, so it can do 1:1 NAT from LAN to that segment.
-
1: GRE would have the lowest overhead, but wouldn't be encrypted. OpenVPN would offer the best of both worlds, but would have some overhead.
2: Simple policy routing will do. Have a rule that passes out from your LAN to * on http/https with no gateway set, and a rule underneath that catches the rest and passes out anything else to the gateway for the VPN (If you assign an OpenVPN instance as an interface you can create a gateway for the other end and use it in policy routing, GRE may allow the same)
Two more things: do L2TP and PPTP have the same capabilities as OpenVPN (i.e. can be assigned as an interface, be used with policy routing, etc.), because should I not just use GRE but a VPN, I'd rather use L2TP and PPTP because Mac OS X supports these out of the box, and I try to use as few different modules as possible, because the more there are, the more potentially unexpected interactions and side effects.
How stable is 2.0 in the mean time? In particular, what I'm interested in is if I should be able to upgrade REMOTELY from whatever beta (4?) we have now to the final release, because I can't ship the unit back and forth to a colocation provider somewhere half across the US just to do a software upgrade. So if the upgrade mechanism is stable and robust enough, and the configuration is forward compatible, I can start working with pfSense. Otherwise I'll have to wait until whenever these two conditions are met.
