A Virtual Private Network, or "VPN", is a tunnel that carries private network traffic from one endpoint system to another over a public network (such as the Internet) without the traffic being aware that there are intermediate hops between the endpoints, or the intermediate hops being aware they are carrying the network packets that are traversing the tunnel. The tunnel may optionally compress and/or encrypt the data, providing enhanced performance and some measure of security.
The "Virtual" part stems from the fact that you are constructing a private link over a public network, rather than actually buying a direct hardwired link over leased lines. The VPN allows you to pretend you are using a leased line to communicate between the endpoints.
You may find the VPN FAQ at http://kubarb.phsx.ukans.edu/~tbird/FAQ.html informative.
IPsec is a set of standard protocols for implementing secure communications and encryption key exchange between computers. It can be used to implement a VPN.
An IPsec VPN generally consists of two communications channels between the the endpoints: a key-exchange channel over which authentication and encryption key information is passed, and one or more data channels over which private network traffic is carried.
The key-exchange channel is a standard UDP connection to and from port 500. The data channels carrying the traffic between the client and server use IP protocol number 50 (ESP).
More information is available in F-Secure's IPsec FAQ at http://www.data-fellows.com/f-secure/support/vpn-plus/faq/techfaq.htm, and in RFC2402 (the AH protocol), RFC2406 (the ESP protocol), and RFC2408 (the ISAKMP key-exchange protocol).
Important note: If your VPN is based on the AH protocol, it cannot be masqueraded. The AH protocol specifies a cryptographic checksum across portions of the IP header, including the IP addresses. IP Masquerade is implemented by modifying the source IP address for outbound packets and the destination IP address for inbound packets. Since the masquerading gateway cannot participate in the encryption key exchange, it cannot generate the correct cryptographic checksums for the modified IP headers. Thus the modified IP packets will be discarded by the recipient as invalid, because they fail the cryptographic checksum test.
PPTP stands for Point-to-Point Tunnelling Protocol. It is a Microsoft-proposed protocol for implementing a VPN.
The PPTP VPN protocol consists of two communications channels between the client and server: a control channel over which link-management information is passed, and a data channel over which (possibly encrypted) private network traffic is carried.
The control channel is a standard TCP connection to port 1723 on the server. The data channel carrying the private network traffic uses IP protocol number 47 (GRE), a generic encapsulation protocol described in RFC1701. The transparent transmission of data over the data channel is achieved by negotiating a standard PPP connection over it, just as if it were a dialup connection directly from the client to the server. The options negotiated over the tunnel by PPP control whether the data is compressed and/or encrypted, thus PPTP itself has nothing to do with encryption.
The details of the PPTP protocol are documented at http://www.ietf.org/internet-drafts/draft-ietf-pppext-pptp-08.txt.
Microsoft's implementation of the PPTP protocol is not considered very secure. If you're interested in the details, here are three seperate analyses:
http://www.counterpane.com/pptp.html
http://www.geek-girl.com/bugtraq/1999_1/0664.html
http://oliver.efri.hr/~crv/security/bugs/NT/pptp2.html
Most current VPN clients assume you will be connecting the client computer directly to the internet. Doing this when you have only a single connection for internet access bypasses your Linux firewall and the security and access-sharing capabilities that it provides. Extending the Linux firewall to also masquerade VPN traffic allows you to retain the firewalling security provided by the Linux firewall as well as permitting the other systems on your local network to access the internet regardless of whether or not the VPN network connection is active.
If your firewall is being used in a corporate setting you may also wish to require your VPN client users to go through that firewall for security reasons, rather than providing them with modems so they can dial out on their own when they need to use VPN. VPN Masquerade allows you to do so even if the desktops do not have registered IP addresses.
Yes, though there may occasionally be minor problems.
The IPsec protocols define a method for identifying the traffic streams called the Security Parameters Index ("SPI"). Unfortunately the SPI used by outbound traffic is different from the SPI used by inbound traffic, and there is no other identifying information available that is not encrypted, so association of the inbound and outbound data streams is difficult and not perfectly reliable.
IPsec Masquerade attempts to associate inbound and outbound ESP traffic by serializing new connections. While this has worked well in testing, it cannot be guaranteed to be perfectly reliable, and the serialization of new traffic may result in some timeouts if the link is saturated or if many local IPsec hosts attempt to initiate communications or rekey with the same remote IPsec host simultaneously.
It is also assumed that should this association scheme fail to associate the traffic streams correctly, the IPsec hosts themselves will discard the incorrectly routed traffic because it will have the wrong SPI values. This is required by the IPsec RFC.
These problems could be eliminated if there was some way to sniff the new SPI values from the ISAKMP key exchange before any ESP traffic appears, but unfortunately that portion of the key exchange is encrypted.
To minimize the problems associated with this, it is recommended that you open a command window on your masqueraded IPsec host and run the "ping" program pinging a host on the remote network for as long as you have the tunnel up.
See the IPsec technical notes at the end of the document for more details.
Yes.
You must enable PPTP Call ID masquerade when configuring your kernel in order to distinguish between multiple data streams from the same server. PPTP masq with Call ID masq enabled will support many concurrent masqueraded sessions with no restrictions on which server a client can call.
For another alternative, see the next question...
Yes. However, your VPN client must be able to forward IP traffic.
This means that you'll either have to use a Linux VPN client or a MS NT VPN client. The IP stack in W'95 and W'98 does not support IP forwarding. NT Workstation will work for this, and is less expensive than NT Server if you're only using it to route encrypted traffic.
If you cannot install a Linux or NT-based VPN client, then you'll have to enable PPTP Call-ID masquerade if you are using PPTP, and install VPN client software on every system you want to provide access for. This is inefficient, aesthetically revolting and a security weakness, but it's cheaper than licensing NT.
Network-to-network routing this way works very well. This is how I have my home network set up for telecommuting. It does require a little more networking knowhow than simply giving everybody their own VPN client.
In my experience, network-to-network routing in a pure-MS environment requires RRAS be installed at both ends of the tunnel.
If your VPN server has a registered IP address you do not need to masquerade it, simply configure your firewall to route the VPN traffic properly as described below.
If your VPN server has a Private-Network IP address you will need to
redirect the inbound traffic to it and masquerade the outbound traffic from
it. Masquerading allows you to make a VPN server available to the internet
even if you only have one assigned IP address. This should work even if
your IP address is dynamically assigned: you would publicize the IP address
for clients through the use of a third-party dynamic DNS service such as
that provided by
DDNS.ORG
and configure the clients to connect to a system named
our-company.ddns.org or something similar. Note that this is a
security risk, because it is possible for an incorrect IP address to be
retrieved from the dynamic DNS server through timing problems, a failure to
properly register the current dynamic IP address, or a third party
registering a different IP address under the system name.
The largest problem in masquerading VPN traffic is that the stock 2.0.x Linux kernel has no special awareness of IP protocols other than TCP, UDP and ICMP.
All IP traffic may be forwarded and filtered by IP address, but filtering on or masquerading IP protocols other than TCP, UDP and ICMP requires modifying the kernel.
The PPTP control channel is plain TCP and requires no special setup beyond letting it through the firewall and masquerading it.
Masquerading the IPsec and PPTP data channels requires a modification that adds support for the ESP and GRE protocols to the masquerading code, and masquerading the ISAKMP key exchange protocol requires a modification that prevents masquerade from altering the UDP source port number and adds tracking of the ISAKMP cookie values.
The 2.0.x kernel patch works on kernel 2.0.36 and is incorporated into the standard 2.0.37 kernel release. It may work on earlier kernels but I have not tested it, and I recommend you upgrade to the latest kernel anyway for security reasons if you are running a kernel that old.
The 2.2.x kernel patch works on kernels from 2.2.5 to 2.2.12 and may work on earlier kernels, but that has not been tested. It will be submitted for inclusion in the standard 2.2.13 release if all goes well.
The 2.0.x kernel patch has been tested and works on x86 and Sparc systems, and the 2.2.x kernel patch has been tested and works on x86 systems, but there should be no major problems in porting to other architectures. I believe the architecture dependencies are only in endian-ness within the bitmaps in the GRE header definition used to format debugging log messages. If anyone ports this to a non-Intel architecture I'd appreciate hearing about it so I can merge any changes into the master copy.
A PPTP-only kernel patch for the 2.1.105+ and 2.2.x kernel series is available at http://bmrc.berkeley.edu/people/chaffee/linux_pptp.html.
See the VPN Masquerade home page at http://www.wolfenet.com/~jhardin/ip_masq_vpn.html for the status of the VPN Masq patches, and http://bmrc.berkeley.edu/people/chaffee/linux_pptp.html for the status of the 2.1.105+/2.2.x PPTP-only Masq patch.