- •Table of Contents
- •Preface
- •What This Book Covers
- •What You Need for This Book
- •Conventions
- •Reader Feedback
- •Customer Support
- •Errata
- •Questions
- •The Need for Cryptography
- •Privacy
- •Security
- •A History of the Internet
- •Holding the Internet Together
- •The Creation of ICANN
- •ICANN Bypassed
- •The Root Name Servers
- •Running the Top-Level Domains
- •History of Internet Engineering
- •The Internet Engineering Task Force (IETF)
- •RFCs—Requests For Comments
- •IETF and Crypto
- •The War on Crypto
- •Dual Use
- •Public Cryptography
- •The Escrowed Encryption Standard
- •Export Laws
- •The Summer of '97
- •The EFF DES Cracker
- •Echelon
- •The End of the Export Restrictions
- •Free Software
- •Free as in Verifiable
- •The Open Source Movement
- •The History of Openswan
- •IETF Troubles over DNS
- •Super FreeS/WAN
- •The Arrival of Openswan
- •NETKEY
- •Further Reading
- •Using Openswan
- •Copyright and License Conditions
- •Writing and Contributing Code
- •Legality of Using Openswan
- •International Agreements
- •International Law and Hosting Openswan
- •Unrecognized International Claims
- •Patent Law
- •Expired and Bogus Patents
- •Useful Legal Links
- •Summary
- •A Very Brief Overview of Cryptography
- •Valid Packet Rewriting
- •Ciphers
- •Algorithms
- •Uniqueness
- •Public-Key Algorithms
- •Exchanging Public Keys
- •Digital Signatures
- •Diffie-Hellman Key Exchange
- •Avoiding the Man in the Middle
- •Session Keys
- •Crypto Requirements for IPsec
- •IPsec: A Suite of Protocols
- •Kernel Mode: Packet Handling
- •Authentication Header (AH)
- •Encapsulated Security Payload (ESP)
- •Transport and Tunnel Mode
- •Choosing the IPsec Mode and Type
- •The Kernel State
- •Encryption Details
- •Manual Keying
- •Final Note on Protocols and Ports
- •Usermode: Handling the Trust Relationships
- •The IKE Protocol
- •Phase 1: Creating the ISAKMP SA
- •Phase 2: Quick Mode
- •The NAT Problem
- •Summary
- •Linux Distributions
- •Debian
- •SuSE
- •Slackware
- •Gentoo
- •Linux 'Router' Distributions
- •Deciding on the Userland
- •Pluto
- •Racoon
- •Isakmpd
- •More Reasons to Pick Pluto
- •Choosing the Kernel IPsec Stack
- •KLIPS, the Openswan Stack
- •ipsecX Interfaces
- •First Packet Caching
- •Path MTU Discovery
- •KLIPS' Downside
- •NETKEY, the 2.6 IPsec Stack
- •The USAGI / SuSE IPsec Stack
- •Making the Choice
- •GPL Compliance and KLIPS
- •Binary Installation of the Openswan Userland
- •Checking for Old Versions
- •Installing the Binary Package for Openswan
- •Building from Source
- •Using RPM-based Distributions
- •Rebuilding the Openswan Userland
- •Building src.rpm from Scratch
- •Openswan Options
- •Building the Openswan Userland from Source
- •Downloading the Source Code
- •Configuring the Userland Tools
- •Optional Features
- •Compile Flags
- •File Path Options
- •Obscure Pluto Options
- •Compiling and Installing
- •Binary Installation of KLIPS
- •Building KLIPS from Source
- •Kernel Prerequisites
- •Identifying your Kernel's Abilities
- •Using Both KLIPS and NETKEY
- •The Kernel Build Options
- •Required Kernel Options
- •Desired Options
- •NETKEY Stack Options
- •KLIPS Stack Options
- •L2TP Options
- •Patching the Kernel
- •NAT-Traversal Patch
- •KLIPS Compile Shortcut
- •Activating KLIPS
- •Determining the Stack in Use
- •Building KLIPS into the Linux Kernel Source Tree
- •Building a Standard Kernel
- •NAT Traversal
- •Patching KLIPS into the Linux Kernel
- •Verifying the Installation
- •Summary
- •Manual versus Automatic
- •PSK versus RSA
- •Pitfalls of Debugging IPsec
- •Pre-Flight Check
- •The ipsec verify Command
- •NAT and Masquerading
- •Checking External Commands
- •Opportunistic Encryption
- •The ipsec livetest Command
- •Configuration of Openswan
- •The ipsec.conf File
- •Host-to-Host Tunnel
- •Left and Right
- •The type Options
- •The auto Option
- •The rsasigkey Options
- •Bringing Up the IPsec Tunnels
- •Listing IPsec Connections
- •Testing the IPsec Tunnel
- •Connecting Subnets Through an IPsec Connection
- •Testing Subnet Connections
- •Testing Properly
- •Encrypting the Host and the Network Behind It
- •Employing Advanced Routing
- •Creating More Tunnels
- •Avoiding Duplication
- •The Also Keyword
- •KLIPS and the ipsecX Interfaces
- •Pre-Shared Keys (PSKs)
- •Proper Secrets
- •Dynamic IP Addresses
- •Hostnames
- •Roadwarriors
- •Multiple Roadwarrior Connections
- •Dynamic IP and PSKs
- •Mixing PSK and RSA
- •Connection Management
- •Subnet Extrusion
- •NAT Traversal
- •Deprecated Syntax
- •Confirming a Functional NAT-T
- •Dead Peer Detection
- •DPD Works Both Ways
- •Configuring DPD
- •Buggy Cisco Routers
- •Ciphers and Algorithms
- •Using ike= to Specify Phase 1 Parameters
- •Using esp= to Specify Phase 2 Parameters
- •Defaults and Strictness
- •Unsupported Ciphers and Algorithms
- •Aggressive Mode
- •XAUTH
- •XAUTH Gateway (Server Side)
- •XAUTH Client (Supplicant Side)
- •Fine Tuning
- •Perfect Forward Secrecy
- •Rekeying
- •Key Rollover
- •Summary
- •X.509 Certificates Explained
- •X.509 Objects
- •X.509 Packing
- •Types of Certificates
- •Passphrases, PIN Codes, and Interactivity
- •IKE and Certificates
- •Using the Certificate DN as ID for Openswan
- •Generating Certificates with OpenSSL
- •Setting the Time
- •Configuring OpenSSL
- •Be Consistent with All Certificates
- •OpenSSL Commands for Common Certificate Actions
- •Configuring Apache for IPsec X.509 Files
- •Creating X.509-based Connections
- •Using a Certificate Authority
- •Using Multiple CAs
- •Sending and Receiving Certificate Information
- •Creating your own CA using OpenSSL
- •Creating Host Certificates with Your Own CA
- •Host Certificates for Microsoft Windows (PKCS#12)
- •Certificate Revocation
- •Dynamic CRL Fetching
- •Configuring CRL
- •Online Certificate Status Protocol (OCSP)
- •Summary
- •History of Opportunistic Encryption
- •Trusting Third Parties
- •Trusting the DNS?
- •OE in a Nutshell
- •An OE Security Gateway
- •DNS Key Records
- •Forward and Reverse Zones
- •The OE DNS Records
- •Different Types of OE
- •Policy Groups
- •Internal States
- •Configuring OE
- •Configuring Policies
- •Full OE or Initiate-Only
- •Generating Correct DNS Records
- •Name Server Updates
- •Verifying Your OE Setup
- •Testing Your OE Setup
- •The trap eroute
- •The pass eroute
- •The hold eroute
- •Manipulating OE Connections Manually
- •Advanced OE Setups
- •Caveats
- •Summary
- •Where to Firewall?
- •Allowing IPsec Traffic
- •NAT and IPsec Passthrough
- •Configuring the Firewall on the Openswan Host
- •Firewalling and KLIPS
- •Firewalling and NETKEY
- •Packet Size
- •Summary
- •Microsoft Windows
- •Layer 2 Tunneling Protocol (L2TP)
- •Assigning an IP for VPN Access
- •L2TP Properties
- •Pure IPsec versus L2TP/IPsec
- •Client and Server Configurations for L2TP/IPsec
- •The L2TP Openswan Server
- •Configuring Openswan for L2TP/IPsec
- •Linux Kernel Runtime Parameters for L2TP/IPsec
- •Protecting the L2TP Daemon with IPsec using iptables
- •Choosing an L2TP Daemon
- •Configuring L2TPD
- •Configuring User Authentication for pppd
- •Microsoft Windows XP L2TP Configuration
- •Microsoft Windows 2000 L2TP Configuration
- •Apple Mac OS X L2TP Configuration
- •Server Configuration for X.509 IPsec without L2TP
- •Openswan Configuration for X.509 without L2TP
- •Client Configuration for X.509 IPsec without L2TP
- •Microsoft's IKE Daemon
- •Microsoft's Certificate Store
- •Clients using Microsoft Native IPsec Implementation
- •The ipsec.exe Wrapper
- •The Linsys IPsec Tool (lsipsectool)
- •Securepoint IPsec Client
- •TauVPN (iVPN)
- •The WaveSEC Client
- •Third-Party Replacement Clients for Windows
- •The GreenBow VPN Client
- •Astaro Secure Client
- •Mac OS X IPSecuritas
- •VPNtracker
- •Manual Racoon Configuration
- •Importing X.509 Certificates into Windows
- •Importing X.509 Certificates on Mac OS X (Tiger)
- •Summary
- •Openswan as a Client to an Appliance
- •Preparing the Interop
- •The Human Factor
- •Terminology
- •Preparation
- •IPsec Passthrough
- •Tunnel Limitations
- •Anticipate Known Problems
- •Update the Firmware
- •GUI Issues
- •Keepalives
- •ISP Filtering
- •Frequently used VPN Gateways
- •Webmin with Openswan
- •Cisco VPN 3000
- •Cisco PIX Concentrator
- •Nortel Contivity
- •Checkpoint
- •WatchGuard Firebox
- •Symantec
- •Frequently used VPN Client Appliances
- •ZyXEL
- •DrayTek Vigor
- •The Vigor Web Interface
- •Windows Logon Issues
- •Other Vigorisms
- •Unresolved Issues
- •NetScreen
- •Known Issues
- •SonicWALL
- •BinTec
- •LANCOM
- •Linksys
- •Lucent Brick
- •NETGEAR
- •KAME/Racoon
- •Aftercare
- •Summary
- •Methods of Encryption
- •Host-to-Host Mesh
- •Host-to-Gateway Setup
- •Single IP Extrusiautomation or L2TP
- •Opportunistic Encryption in the LAN
- •Non-OE-Capable Machines
- •Designing a Solution for Encrypting the LAN
- •Design Goals
- •Separation of WiFi and Crypto
- •Link Layer Protection
- •The Logical Choice: IPsec
- •Hotspot
- •WaveSEC
- •Full WaveSEC
- •Catch 22 Traffic
- •Building a WaveSEC Server
- •DHCP Server Setup
- •DNS Server Setup
- •Openswan Server Setup
- •Catch 22 Traffic Setup
- •Building a WaveSEC Client
- •DH Client Setup
- •Openswan Setup
- •Testing the WaveSEC
- •Starting the WaveSEC Connection
- •Known Issues with WaveSEC
- •WaveSEC for Windows
- •Design Limitations
- •Building a WaveSEC for Windows Server
- •Obtaining the Certificate and Client Software
- •Our Prototype Experiences
- •Openswan Issues
- •Windows Kernel Issues
- •Summary
- •Cipher Performance
- •Handling Thousands of Tunnels
- •Managing Large Configuration Files
- •Standard Naming Convention
- •The also= Parameter
- •The include Parameter
- •Openswan Startup Time
- •Limitations of the Random Device
- •Other Performance-Enhancing Factors
- •Logging to Disk
- •Disable Dead Peer Detection
- •Reducing the Number of Tunnels
- •OSPF Setup
- •BGPv4 Setup
- •High Availability
- •Heartbeat
- •Xen Migration
- •Using Anycast
- •Summary
- •Do Not Lock Yourself Out!
- •Narrowing Down the Problem
- •Host Issues
- •Configuration Problems
- •Connection Names
- •Interoperability
- •Hunting Ghosts
- •Rekey Problems (After an Hour)
- •Openswan Error Messages
- •IKE: Unknown VendorIDs
- •Network Issues
- •Firewalls
- •MTU and Fragmentation Issues
- •Debugging IPsec on Apple Mac OS X
- •Debugging IPsec on Microsoft Windows
- •Oakley Debugging
- •Debugging ipsec.exe
- •Microsoft L2TP Errors
- •You Suddenly Cannot Log in Anymore over the VPN
- •Software Bugs
- •Userland Issues: Assertion Failed or Segmentation Faults
- •Kernel Issues: Crashes and Oopses
- •Memory Issues
- •Common IKE Error Messages
- •Common Kernel-Related Error Messages
- •Common Errors when Upgrading
- •Using tcpdump to Debug IPsec
- •Situation A: No Communication on Port 500
- •Situation B: Failure at Third Exchange
- •Situation C: QUICK Mode Initiates, but Never Completes
- •Situation D: All IKE Messages Occur, but no Traffic Flows
- •A Final tcpdump Example
- •User Mode Linux Testing
- •Preparing the Openswan for the UML Build Process
- •Running the UMLs
- •Writing a UML Test Case
- •Debugging the Kernel with GDB
- •Asking the Openswan Community for Help
- •Internet Relay Chat (IRC)
- •The Openswan Mailing Lists
- •Posting to the Lists
- •Research First, Ask Later
- •Free, as in Beer
- •Do not Anonymize
- •Summary
- •Linux Kernel Developments
- •Kernel API Changes between 2.6.12 and 2.6.14
- •Red Hat Kernel Developments
- •Fedora Kernel Source/Headers Packaging Change
- •MD5 Insecurities
- •Discontinuation of Openswan 1 by the End of 2005
- •Update on UML Testing Suite Installation
- •Openswan GIT Repositories
- •Openswan on Windows and Mac OS X Updates
- •Known Outstanding Bugs
- •Vulnerability Fixes in Openswan 2.4.4
- •The OSI Model and the IP Model
- •No Layers, Just Packets
- •The Protocol
- •IP Network Overview
- •IP Address Management
- •The Old IP Classes
- •Classless IP Networks
- •The Definition of a Subnet
- •Calculating with Subnets: The Subnet Mask
- •The Rest of the Network
- •Linux Networking Commands
- •Routing
- •Routing Decisions
- •Peering
- •Network Address Translation
- •Port Forwarding
- •Openswan Links
- •Community Documentation
- •Generic Linux Distributions Containing Openswan
- •Specialized Linux Distributions Containing Openswan
- •Overview RFCs
- •Basic Protocols
- •Key Management
- •Procedural and Operational RFCs
- •Detailed RFCs on Specific Cryptographic Algorithms and Ciphers
- •Dead Peer Detection RFCs
- •NAT-Traversal and UDP Encapsulation RFCs
- •RFCs for Secure DNS Service, which IPSEC May Use
- •RFCs Related to L2TP, Often Used in Combination with IPsec
- •RFCs on IPsec in Relation to Other Protocols
- •RFCs Not in Use or Implemented across Multiple Vendors
- •Index
Configuring IPsec
To make it easier to maintain, you can use include statements in the configuration files, which may contain wildcards. This can help you organize your VPN connections, for instance by grouping them in directories per region:
include /etc/ipsec.d/canada/*.conf include /etc/ipsec.d/netherlands/*.conf include /etc/ipsec.d/ussa/*.conf
Host-to-Host Tunnel
Now let us make an example ipsec.conf configuration for a VPN tunnel from East to West. This ipsec.conf configuration file needs to be created on both ends.
version 2
config setup interfaces=%defaultroute
#klipsdebug=all
#plutodebug=control
conn %default authby=rsasig
conn west-east left=193.110.157.131 right=205.150.200.209 type=tunnel
leftrsasigkey=0sAQOkF1Ggd4iFfI2nQxJYbN9HGD...
rightrsasigkey=0sAQPEAl+N52EIRrIAA5cxl8U...
auto=start
And that is all you need to define an IPsec tunnel with Openswan. It can't be easier! Though most options should be self explanatory, let's review all of them so we will fully understand their usage.
Left and Right
Most network administrators are used to the concepts of source and destination addresses, and they expect an IPsec configuration to have a source and a destination. But this doesn't really apply to IPsec, bearing in mind that an IPsec connection actually contains two halves, one for incoming and one for outgoing packets. It would be confusing, and not to mention extremely annoying, if after transferring a file to the other IPsec endpoint you had to then swap source and destination parameters. And the terms client and server won't help either, since IPsec really is a peer-to-peer protocol. Not all IPsec peers are either clearly the client or the server. They could even be considered a client for one tunnel, and a server for another.
For these reasons, the concepts of left and right are used. These terms are dependent on your point of view (look in a mirror, or teach in front of a group of people to see how left and right can become exchanged). So the choice of which end to call left or right is completely up to you. You might look at your draft network sketch and call the one you drew on the left "left".
The good thing is that when Openswan loads a new connection, it will look at both left and right entries, and it will try to figure out which end it is. It does so by comparing the specified IP address (or resolved hostnames) to the list of currently active IP addresses on the host. In our
82
Chapter 4
example, West will figure out it is left because it can see that its network configuration has the IP address 193.110.157.89, which matches the left= option. East will figure out it is right, because the right= option matches one of its IP addresses. If Openswan cannot determine whether it is left or right, the connection will fail to load, and a warning will be logged.
Because of Openswan's automatic left/right detection, simple connection definitions can be used on both IPsec endpoints without editing them. The exception is when you are using roadwarrior connections.
The type Options
The type= option sets the IPsec mode to use. When left out, it defaults to tunnel mode, which should be correct for most cases, with the exception of Microsoft L2TP connections.
IPsec mode |
Description |
|
|
type=tunnel (default) |
Use tunnel modes |
type=transport |
Use transport modes |
type=passthrough |
Do not process packets, just pass them through to the kernel |
|
|
The auto Option
The auto=start option tells Openswan to immediately start this connection on startup. The auto option can have the following values:
Start-up option |
Description |
|
|
auto=start |
Load, route, and initiate the connection |
auto=add |
Load the connection and respond to an incoming request |
auto=ignore (default) |
Ignore this connection completely |
auto=manual |
This connection will be keyed manually (not recommended) |
auto=route |
Load and route the connection (used for special routing cases) |
|
|
The first two are the most common. auto=start is used for static IPsec tunnels, whereas auto=add is used mostly when the connection defined cannot initiate, but only respond. This is for instance the case with roadwarriors, where the server end does not know where or when the roadwarrior will appear, because it is a roaming user that pops in at various dynamic ISP-dependent IP addresses assigned through DHCP.
83
Configuring IPsec
The rsasigkey Options
The last remaining question in our example is that of where the RSA key entries come from. These entries correspond to the public RSA keys of the RSA key-pairs that were generated when we first started Openswan. It is unique for every host.
Both these private and public RSA keys are stored in ipsec.secrets; you could cut and paste the public key from there, but it is usually easier to use the following command, which will do the formatting for you. For example, to create a leftrsasig= statement on West, we simply run the following command on West:
#ipsec showhostkey --left
#RSA 2192 bits west.testbed.xelerance.net Sun Jan 5 16:21:41 2005
leftrsasigkey=0sAQPEAl+N52EIRrIAA5cxl8UanVSr2mCVPWmzgLK62G1jeKrZ6OxM9kdY1jm
9Fv/7HOmLWzYJZSYdPnh9DIHY15ipfZkXDapewaFvSH0yX3V7GUrVF9N8dZSAkPg/nOc+A
VjJfWHHxT4/e4AA6syOYFGQCyRt4BXZ5xY0U/10QRL/Ra2xtF4aV1GdNCfcFT4/VeUbrfMB0e
RI++hTUx4MriX2zO5VwRxRSoMpMcSqv7QbICiKw+gRu/63HroR0n1Wmp8VQzWd3SMpUCw
QhoBSkeP5Ib8jXg+sNrb7LDC7fSNHbAzgg8vGSwcotBisUiES/8JXkI9PQAPrRaxrY2fP8sWky0 tsySlJytweSWLdfjPwcoOZ
The first # line is a comment, which you can also keep in your connection definition if you like. Be careful when copying and pasting such a line from one window to another. It is one big line and some desktop environments, or email programs, may automatically wrap this line for you.
You must not break up the line!
Note that in the rest of this chapter, to save space and improve clarity, we won't show these long rsasigkey= lines in full, and they will instead appear thus:
leftrsasigkey=0sAQPEAl+N52EIRrIAA5cxl8UanV.....
When you see such a line, be aware that you should put in your key, which might be several lines long.
Bringing Up the IPsec Tunnels
Once we have copied our ipsec.conf file from West to East, and restarted Openswan on both ends, we will see something in the logs that looks like this:
Sep 15 20:05:05 west pluto[20362]: "west-east" #365: initiating Main Mode Sep 15 20:05:05 west pluto[20362]: "west-east" #365: transition from state
STATE_MAIN_I1 to state STATE_MAIN_I2
Sep 15 20:05:05 west pluto[20362]: "west-east" #365: I did not send a certificate because I do not have one.
Sep 15 20:05:06 west pluto[20362]: "west-east" #365: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
Sep 15 20:05:06 west pluto[20362]: "west-east" #365: Peer ID is ID_IPV4_ADDR: '205.150.200.209'
Sep 15 20:05:06 west pluto[20362]: "west-east" #365: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
Sep 15 20:05:06 west pluto[20362]: "west-east" #365: ISAKMP SA established Sep 15 20:05:06 west pluto[20362]: "west-east" #366: initiating Quick Mode
RSASIG+ENCRYPT+TUNNEL+PFS+UP {using isakmp#365}
Sep 15 20:05:06 west pluto[20362]: "west-east" #366: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
Sep 15 20:05:06 west pluto[20362]: "west-east" #366: sent QI2, IPsec SA established {ESP=>0xe5f72aaa <0xc51033f4}
84
Chapter 4
In the last line, you'll note the message IPsec SA established, meaning we've successfully set up an IPsec VPN tunnel between West and East. The ESP in curly braces tells us that we are using Encapsulated Secure Payload, which means tunnel mode with full encryption, commonly called VPN.
The log file locations differ from distribution to distribution. Red Hat and Fedora Core log this information in /var/log/secure, while Debian logs it in /var/log/auth.log. If in doubt, check /etc/syslog.conf and look where the authpriv.* priority is logged to.
Listing IPsec Connections
The eroutes are the kernel's internal encrypted routes and reflect the internal SPD policies. It is easy to think of eroutes as encryption routes—all active IPsec connections correspond with one eroute entry. Since the eroutes are displayed as one line per IPsec connection, they provide a condensed and clear view of the IPsec connections for a machine.
# ipsec eroute
5 193.110.157.131/32 -> 205.150.200.209/32 => tun0x109a@205.150.200.209
The eroute output tells us that five packets have been sent or received over the IPsec tunnel between our local machine (West, 193.110.157.131) and the remote endpoint (East, 205.150.200.209), and that the tunnel policy says that only packets between 193.110.157.131 and 205.150.200.209 are allowed to be sent through this tunnel.
If you need more details on the connections, use the following command:
# ipsec auto --status
This will produce an enormous amount of output, but it will contain all the details you might want to know. When using NETKEY, you can also use setkey -D and setkey -P -D directly, which also give a few screens of information.
Testing the IPsec Tunnel
To actually confirm your VPN connection works, you can run a traceroute. Running one on West to East will show us:
# traceroute 205.150.200.209
traceroute to east.testbed.xelerance.net (205.150.200.209) from 193.110.157.131, 30 hops max, 38 byte packets
1 east.testbed.xelerance.net (205.150.200.209) 136.378 ms 137.755 ms 136.478 ms
West is in Canada, and East is in Amsterdam, but instead of the many hops across the Atlantic such a packet would travel without IPsec, we now see it travels only one hop, since the packet is traveling through the tunnel. Note that the hop takes about 136ms, which is roughly the time it takes to cross the Atlantic.
You can run tcpdump to check that traffic actually got encrypted. First, let us show an example using KLIPS, which is the easiest to read because it separates traffic on the physical and virtual interfaces:
# tcpdump -n -i eth0
20:20:50.322743 193.110.157.131 > 205.150.200.209: ESP(spi=0xe5f72aaa,seq=0x19) 20:20:50.370512 205.150.200.209 > 193.110.157.131: ESP(spi=0xc51033f4,seq=0x19)
85