You have several options for VPN tunnels (and some other tunnel-like things) in pfSense/FreeBSD. I'm simplifying in many cases here...
1) 802.11Q - not really tunnelling, but this allows you to logically segregate traffic if you have a raw Ethernet-type link between two firewalls. (This can be the case for Metro LAN services.) No encryption, requires Ethernet + 802.11q-capable switches end-to-end. 2) QinQ - a way to nest 802.11Q tags, so that if your provider only gives you one VLAN, you can still run your own VLAN tagging end-to-end. No encryption, requires Ethernet + 802.11q + QinQ-capable switches end-to-end. 3) GRE - encapsulates an entire Ethernet frame in IPv4, so any Ethernet-based protocol can be tunnelled. No encryption. Requires IP, no encryption. 4) GIF - encapsulates IPv4 (or IPv6) in IPv4 (or IPv6), so non-IP protocols (including ARP!) cannot be tunnelled. Requires IP, no encryption. 5) PPTP - interoperates with everything under the sun, provides an authenticated point-to-point link, optionally encrypted. Can theoretically tunnel IPX, IP, AppleTalk and a few other protocols but is usually limited to IP only. Security is generally considered to be very poor - default encryption can typically be cracked within 5 minutes using a calculator watch. (OK, not *quite*, but...) 6) L2TP - similar to PPTP, no-one except Cisco uses this in the real world AFAIK. Except Microsoft, of course, and there they've done a proprietary IPSec+L2TP thing that you don't want to use unless you *have* to connect to a Microsoft RAS server. (To be fair, it's gaining some traction, but it's still fairly rare anywhere else.) 7) IPSec transport mode - does encryption of the packets between the firewall and a specific remote host, and nothing else. (This is why you'd use transport mode in conjunction with GRE or GIF, to make sure those packets were encrypted.) 8) IPSec tunnel mode - does what it sounds like, builds an encrypted tunnel between two hosts; depending on the implementation, this either almost completely bypasses the normal IP routing stack or it looks like a new virtual interface and participates almost normally in IP routing. FreeBSD is more along the bypass lines from a routing perspective, where IPSec tunnels (sort-of) override normal IP routing. FreeBSD/pfSense is a little bit less flexible than some other systems when it comes to IPSec, but compatibility appears to be very good so far (IMHO). As Chris mentioned, you can't build redundant IPSec tunnels in pfSense (yet?)... this sure would be a nice feature to have, since many other firewalls (Sonicwall, Fortigate, Palo Alto, Symantec,...) can do redundant tunnels. I don't know if it's a limitation in the underlying FreeBSD IPSec implementation, though. 9) OpenVPN - shows its UNIX roots: there's almost nothing you can't do with OpenVPN, provided you spend a lot of time learning its intricacies, gotchas, and fundamental approach to the universe. Very powerful, very flexible, very portable, yet also not common outside the Linux/*BSD/etc. world. Can do "tun" or "tap" mode, somewhat analogous to the difference between GRE and GIF (one encapsulates Ethernet frames, one only encapsulates IP packets). *Probably* has the lowest overhead of any encrypted VPN technology available here, and seems to be very well-supported under pfSense. I'm sure *someone* here has run performance tests...? Then, to achieve redundancy: 1) LAGG - a way to bundle multiple Ethernet interfaces together for load-balancing and failover. Only supports true Ethernet devices in pfSense, not GRE (even though there's nothing theoretically wrong with running a LAGG protocol over two GRE interfaces, since they do encapsulate all Ethernet fields... but it would be kind of pointless in almost all scenarios.) 2) OSPF - routing protocol that allows for multiple equal-cost paths. Can usually do load-balancing across the multiple paths, not 100% sure if this works in pfSense, never tested it. Typically only used when both devices are managed by the same person/group/organization, as there's little security in the protocol. Relies on drivers to accurately report the status of underlying links for fast convergence/failover. (It'll figure it out on its own eventually, even if the link is still reported as "up", just not very quickly.) 3) BGP - another routing protocol that allows for multiple equal-cost paths. Can usually do load-balancing across the multiple paths, not 100% sure if this works in pfSense, never tested it. Typically used when each device is managed independently. Not typically used in scenarios where fast convergence is required, but it can be tweaked for that purpose if needed. 4) Redundant tunnels - see comments re IPSec above. Other tunnel protocols still need a routing protocol to handle the equal-cost paths so the kernel doesn't go insane... like OSPF or BGP. As I said, there are some over-generalizations here (and probably some mistakes too), but I hope that helped. -Adam Thompson [email protected] > -----Original Message----- > From: Chris Buechler [mailto:[email protected]] > Sent: Sunday, December 05, 2010 22:58 > To: [email protected] > Subject: Re: [pfSense Support] IPSec VPN Question > > On Sun, Dec 5, 2010 at 6:22 PM, Alex Threlfall <[email protected]> > wrote: > > Hi All, > > > > Doing some testing here, and this might not be the best > place to ask > > but thought I'd start off here! > > > > I'm running a pair of pfSense 2.0 Beta 4 LiveCD's back to > back with > > a pair of WAN connections between them via x-over cat5's. Fairly > normal > > hardware, HP DL360 G3's with a Dual Port Intel FXP Card (onboard > BGE is lan) > > > > I'm trying to prove that I can run two IPSec VPN's between > the > > boxes, to provide some fault tolerance, however I can only get > the VPN's to > > link up on the WAN interface, despite specifying on both boxes > that the > > second VPN should be on OPT1 (or WAN1 which I've named it). > > > > You can't do that with tunnel mode. Either use transport mode + GRE > or > gif + OSPF or BGP, or OpenVPN + OSPF or BGP. > > ------------------------------------------------------------------- > -- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > Commercial support available - https://portal.pfsense.org --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] Commercial support available - https://portal.pfsense.org
