I will start with IPSEC for two reasons. First, because of its popularity, second because of the number of misconceptions around it. It is possibly the most commonly used while being least fit for purpose VPN technology.
IPSEC it in fact is two technologies - tunnel and transport mode. The first one is a VPN technology while the second one is not. It is a technology to provide data protection to other traffic which may be in some cases a VPN technology.
IPSEC is an industry standard which has been designed with only one thing in mind - link security from both authentication and privacy perspective. Throughout the entire design of IPSEC the underlying IP transport has been considered as reliable and managed by external means. Hence, many features relevant to both infrastructure and RAS usage are missing from the standard.
Tunnel mode is the most common mode used by commercial VPN client/server RAS solutions. It is important to note that the "industry standard" form of tunnel mode IPSEC does not offer the endpoints any information on the link status, has no keep-alives, has no fallback and no high availability provisions. As a result in its "industry standard" and interoperable form it is not fit for use as an infrastructure VPN for anything more then a link between two sites wich have no fallback provisions.
In fact, it is not very suitable for RAS either. Part of the RAS requirements is to supply the client with some basic IP settings like DNS, WINS, routing, etc. In its standard form tunnel mode IPSEC has no provisions for these and they have to be supplied by vendor specific mechanisms. Usually it is done via some proprietary vendor protocol, in some cases via LDAP or an overload of an existing industry standard like Kerberos.
Transport mode is not a VPN technology in itself so the specifics will accompany the sections for the relevant VPN technologies: IPIP, PPP in TCP, GRE, PPTP, L2TP, SSL/TLS VPNs, etc.
For either one of them FreeBSD can do only what is in the standards (RFCs). So if your requirements involve higher reliability or easier management you should be looking at a different technology or a different platform ( 1, 2, 3).
IP-in-IP is the simplest VPN protocol. It requires fixed IP addresses on both sides of the link. It has no authentication provision and no data privacy provisions. It has no sequencing, no flow control, no acknowledgement and can operate on networks with packet reorder. It cannot report the state of the link and other means are required to get link status information.
FreeBSD can interoperate with most other implementations capable of the so called NOS mode (first to appear with K9Q NOS).
IP in IP is a purely infrastructure solution because the endpoint addresses are fixed, there are no provisions to use an anonymous address and both ends of the link are equivalent in terms of link establishment and breakage.
IP in IP can be protected by IPSEC. The result is similar in terms of data privacy and authentication to tunnel mode IPSEC. Due to the number of extra buffer copies it is more expensive in terms of performance. Compared to tunnel mode IPSEC it has the advantage that it can provide an interface which can be used to run a routing protocol.
This is possibly the second simplest VPN protocol. It is also the simplest one to implement. It suffers from a number of significant drawbacks. If packets are dropped due to congestion both the tunnel and the TCP stream inside the tunnel will attempt to retransmit. In some cases this will result in additional congestion which will make matters only worse. It will also result in significant fluctuations of TCP window sizes and bad link performance. In many cases this can be resolved by setting a bandwidth limit on the contents of the tunnel using ALTQ or dummynet as well as setting a lower MTU on the PPP link.
FreeBSD userland PPP can be easily made to operate over TCP and
example is provided in the
ppp man page.
There are also quite a few examples of PPP operating over stunnel and ssh over the net. It is important to note that without additional tuning all of them are considerably less secure then their users expect. The reason for this is that ppp by default starts to send an lcp-echo-request if there is no traffic on the link. This results in having easily identifiable known plaintext on the link. So far noone has published anything on the using the keep-alives for cryptanaliysis, so the actual extent of security degradation is unknown. As a result for TCP links it is advisable to turn off keep-alives (TCP is good enough in looking after the link state).
FreeBSD can interoperate versus other implementations providing they use the same encapsulation semantics.
Due to the fact that TCP has a strict definition of a client and server the endpoints in a PPP over TCP VPN are not equivalent. One is a server, the other is a client and the client is responsible for reestablishing the link. It can be used for both Infrastructure and RAS, after taking into account that it is what it is. Namely, it is a DIY VPN and you will always get significant improvements after switching to more "proper" protocols.
Using transport mode IPSEC on TCP is generally a bad idea because it restricts severely the scope of use to a non-NAT/PAT environment. TCP also has plenty of predictable traffic for plaintext and statistic analysis attacks. If you need data protection and authentication for a PPP in TCP VPN you are likely to get much better performance and higher usability out of stunnel or OpenVPN in TCP mode.
GRE provides for a number of features missing in IP-in-IP. It provides sequencing, acknowledgement for packets, keepalives and is capable of reporting the state of the link (UP/Down). It also adds the restriction that packets must not be reordered.
FreeBSD can interoperate versus most other implementations.
GRE is a purely infrastructure solution because the endpoint addresses are fixed, there are no provisions to use an anonymous address and both ends of the link are equivalent in terms of link establishment and breakage. It also satisfies most of the other infrastructure requirements.
GRE can be protected with Transport mode IPSEC. It should be NATable in most cases. An example of an IPSEC policy for GRE is provided in the PPTP section.
PPTP is based on transporting PPP in GRE and possesses many of the features of a GRE tunnel. It has keepalives and is capable of correctly reporting the link status. Early implementations were strictly adhering to the spec and attempting reliable message transfer as well as discarding any out-of-order frames. Most modern implementations cut a number of corners to this respect in order to be able to accomodate for message reorder. As a result, depending on the negotiated encryption, packets per second rate and the link round trip time PPTP implementations will often switch from reliable to unreliable message transfer. This is valid for both pptp implementations present in FreeBSD ports - mpd and poptop.
PPTP is usually considered a very weak protocol from a security perspective. This perception is not entirely correct. While early PPTP versions had a number of severe deficiencies, the more recent 128
RC4 bit versions have a level of data privacy which is adequate as a protection against adversaries which do not possess significant computational resources (everybody except governments, large corporations, etc).
PPTP popularity is due to the fact that it has been present in nearly all Windows versions since Win 98. Unfortunately the MPPE encryption in the current Windows releases (post SP4 W2K and post SP1 XP) is broken and fails miserably on packet sequence wraparounds against nearly all third party implementations. Also, while the data is encrypted, the control information is not. The evaluation of the actual impact of having non-encrypted control channel varies from "insignificant" to "disaster" depending on the source. To be on the safe side, I would recommend to use "bare" PPTP on networks with low adversary technical level and overlay it with IPSEC in more hostile environments.
PPTP was initially designed to satisfy a list of mostly RAS requirements. At the same time due to the underlying use of PPP and GRE it satisfies many infrastructural requirements. As a result it can be used for some infrastructure where there are additional requirements like initiation from anonymous IP addresses and reuse of RAS infrastructure.
Overall, while still useful and widely supported it has more or less had its day and is going towards the DIY VPN or historic category.
PPTP in fact consists of two protocols. One is GRE and the other one is the control TCP connection. While GRE can be IPSEC protected and still retain NAT-ability, TCP cannot. As a result if you intend to use PPTP with an additional IPSEC protection in a NAT environment you will have to set the policy (1.2.3.4 is your server address) to encrypt only the GRE portion:
spdadd 1.2.3.4/32 0.0.0.0/0 gre -P out ipsec esp/transport//require; spdadd 0.0.0.0/0 1.2.3.4/32 gre -P in ipsec esp/transport//require;
This will leave the control connection unencrypted. If you are not using MPPE encryption and relying only on IPSEC for data protection this mode of operation should be generally OK because the TCP connection is not used once the connection has been established. If you are using both MPPE and IPSEC you are likely to give away that interesting things are happening inside the PPTP tunnel from time to time.
In an earlier version of this HowTo I was suggesting to use IPSEC to overlay the entire connection. I would now suggest to limit the IPSEC policy only to GRE (as above) because of the nearly universal prevalence of NATs (hotels, broadband, etc). This will allow you to still use PPTP, have some reasonable data privacy and avoid dealing with the recent breakage in MPPE encryption introduced by Microsoft.
Microsoft have broken the semantics of the PPP LCP and CCP protocols in implementing MPPE encryption. It overloads the CCP which is a compression negotiation protocol and implies the usage of the Microsoft variant of CHAP. While CHAP and PAP can peacefully coexist Microsoft clients will refuse to negotiate MPPE if PAP is offered. Other clients (Mergic VPN for PalmOS) may refuse to negotiate MPPE if anything, but Microsoft CHAP is offered during the negotiation.
L2TP is a logical evolution of PPTP where the TCP control connection has been replaced by UDP. Similarly, for data GRE has been replaced by UDP as well. L2TP can use MPPE encryption in a fashion similar to PPTP. It also suffers from nearly all of the drawbacks of PPTP and has only one minimal advantage over it - the CPU and network overheads are slightly lower.
NATting IPSEC UDP transport mode traffic does not work if checksums
are in use. If you intend to use L2TP which traverses NAT in an IPSECed
form you must disable UDP checksumming on both ends. It can be done
by setting the net.inet.udp.checksum sysctl to 0.
One of the serious pluses of L2TP is that Windows clients by default try to overlay L2TP with transport mode IPSEC. It is extremely easy to set it up on the BSD side. The following has been abridged from a Microsoft Technet article (with relevant BSD adaptations and syntax).
It necessary to set transport a simple transport mode policy and use certificates for authentication. The policy for a server with an address of 1.2.3.4 is as follows:
spdadd 1.2.3.4[1701] 0.0.0.0/0 udp -P out ipsec esp/transport//require; spdadd 0.0.0.0/0 1.2.3.4[1701] udp -P in ipsec esp/transport//require;
The client will look up if it has a certificate signed by the same CA as the server during IKE negotiation. The client certificate signed by this CA will be supplied in response. From there on if the SPI is established correctly the client will proceed with the the normal L2TP authentication. While IPSEC is more then enough to provide traffic privacy Microsoft will still insist on using MPPE. The only way to provide it on BSD will be to port L2TPD to use one of the proper PPP infrastructures so for the time being you will have to disable this in the clients.
The only FreeBSD supported member in this category for the time being is OpenVPN so this section is OpenVPN specific.
OpenVPN supports four different VPNs technologies via a single product. It offers both bridging (Layer 2) and Point to Point (Layer3) links. Either one of these can be transported with SSL/TLS encryption over UDP and TCP as well as symmetric encryption over UDP. It satisfies most of the requirements for infrastructure. At the same time some modes of operaion approach an acceptable level of ease of use for small RAS deployments. Most importantly, it has internal keep-alive (ping) support which is done as a part of the control channel and does not provide an opportunity for known plaintext attacks like PPP over stunnel/ssh or PPTP/L2TP protected with an extra IPSEC overlay.
Its high speed, low latency and minimal CPU overheads are truly remarkable. Unfortunately, it also shows the signs of software which is still in very active development. Documentation is far from consistent. User interface and visual tools for the windows client for the time being are only a dream. It has more options and deployment modes then 6-7 commercial VPN suites combined which results in having at least twice as many critical caveats suitable for hanging yourself.
Overall, it is possibly the best way to proceed as far as furtureproofing your VPN is concerned and will be covered extensively in a dedicated section.
You are truly paranoid if you are expecting this as well, but if you want to do it you can look at the notes for L2TP if you are using UDP transport and PPP In TCP if you are using TCP transport. In either case you are likely to lose the capability of OpenVPN to traverse NAT.
The list of supported interface types and suppported features in the OpenVPN documentation is inconsistent and quite often fails to reflect recent developments. For example both tap and tun are supported on Windows as of 1.5 and only tap was listed in the 1.5 documentation. If in doubt, check RTFCL (read the fine changelog) .