Sample excerpt. Virtual Private Networks. Contents

Transcription

1 Contents Overview Overview of IPsec Headers IPsec Modes Authentication and Encryption Algorithms IPsec Security Associations (SAs) IKE version IKE Mode Config Advanced IPsec Features Certificates NAT Traversal Configure an IPsec VPN Connection Create Named Objects for the VPN (Optional) Create an IKE Policy Install Certificates for IKE Create an IPsec Proposal Create an IPsec Policy Configure Bypass and Ignore IPsec Policies Configure Global IPsec Settings View VPN Connections Clear VPN Connections View IP Address Pools Sample excerpt 7 7-1

2 Contents Layer 2 Tunneling Protocol (L2TP) over IPsec L2TP over IPsec Overview Configuring L2TP over IPsec Create an L2TP Policy Add L2TP Dial-in Users Manage L2TP over IPsec Connections Generic Routing Encapsulation (GRE) Create a GRE Tunnel Configure GRE over IPsec Configure Firewall Access Policies for Your VPN Access Policies for an IPsec Site-to-Site VPN with IKE Access Policies for an IPsec Site-to-Site VPN with Manual Keying Access Policies for an IPsec Client-to-Site VPN with IKE Access Policies for an L2TP over IPsec VPN Access Policies for a GRE Tunnel Access Policies for a GRE Tunnel over IPsec Verify Routes for the VPN Configure the VPN Client Configure a ProCurve VPN Client TMS zl Module Settings for the HP ProCurve VPN Client Configure IPSecuritas for Macintosh VPN Client TMS zl Module Settings Configure a Windows XP SP2 Client for L2TP over IPsec Configuration with the New Connection Wizard Manual Windows XP Client Configuration Configure a Windows Vista Client for L2TP over IPsec TMS zl Module Settings for an L2TP over IPsec Connection to a Windows Vista Endpoint Configuring the L2TP Shared Secret on the Windows Client

3 Overview Overview The Threat Management Services (TMS) zl Module supports virtual private networks (VPNs), which are tunnels that connect two trusted endpoints through an untrusted network. The tunnel typically provides data integrity and data privacy for traffic transmitted over the tunnel. The TMS zl Module supports these options for VPNs: IP security (IPsec): Site-to-site VPNs: With Internet Key Exchange (IKE) version 1 With manual keying Client-to-site VPNs with IKE v1 L2TP and L2TP over IPsec client-to-site VPNs Generic Routing Encapsulation (GRE) tunneling site-to-site VPNs GRE over IPsec GRE does not offer robust security on its own. GRE over IPsec is a secure tunnel. Table 7-1 displays the type of VPN that you should configure based on your remote VPN gateway or your VPN clients. The table includes all gateways and clients supported by the TMS zl Module. Table 7-1. Selecting a VPN Type Remote VPN Gateway or Clients HP ProCurve VPN Client v (for Windows XP or 2000) Windows XP SP2 clients Windows Vista SP1 clients VPN Type Configuration Guidelines IPsec with IKE v1 client-to-site VPN See Configure an IPsec VPN Connection on page 7-21 for a list of steps. When configuring the IKE policy, IPsec policy, and firewall access policies, follow the instructions in the client-to-site sections. L2TP over IPsec client-to-site VPN See Configuring L2TP over IPsec on page 7-96 for a list of steps. When configuring the IKE policy, IPsec proposal, and IPsec policy, use the settings indicated in Configuring L2TP over IPsec on page When configuring the IKE policy and IPsec policy, follow the instructions in the client-to-site sections. 7-3

4 Overview Remote VPN Gateway or Clients IPSecuritas for Macintosh IPsec with IKEv1 client-to-site VPN See Configure IPSecuritas for Macintosh VPN Client on page for a list of steps. When configuring the IKE policy, IPsec policy, and firewall access policies, follow the instructions in the client-to-site sections. ProCurve Secure Router Series 7000dl software version J VPN Type IPsec with IKEv1 site-to-site VPN See Configure an IPsec VPN Connection on page 7-21 for a list of steps. When configuring the IKE policy, follow the instructions in the site-to-site sections. When configuring the IPsec policy and firewall access policies, follow the instructions in the site-to-site with IKE sections. TMS zl Module IPsec with IKEv1 site-to-site VPN See Configure an IPsec VPN Connection on page 7-21 for a list of steps. When configuring the IKE policy, follow the instructions in the site-to-site section. When configuring the IPsec policy and firewall access policies, follow the instructions in the site-to-site with IKE sections. IPsec with manual keying site-to-site VPN Configuration Guidelines See Configure an IPsec VPN Connection on page 7-21 for a list of steps. When configuring the IPsec policy and firewall access policies, follow the instructions in the site-to-site with manual keying sections. GRE tunnel See Create a GRE Tunnel on page for instructions. See also Access Policies for a GRE Tunnel on page GRE over IPsec tunnel See Access Policies for a GRE Tunnel over IPsec on page When configuring the IPsec policy, follow the instructions in the site-to-site with manual keying section. Use the settings indicated in Access Policies for a GRE Tunnel over IPsec on page

5 IPsec, which supports a variety of industry-standard authentication and encryption protocols, is a flexible, highly secure method of establishing a VPN. The TMS zl Module acts as the gateway device for the IPsec VPN that is, the tunnel endpoint. The other end of the tunnel can be another VPN gateway (in a site-to-site VPN) or a remote endpoint (in a client-to-site VPN). Overview of An IPsec VPN is created with one or more elements of the IPsec protocol suite: Authentication Header (AH) Encapsulation Security Payload (ESP) IKE This section describes how these protocols interact to establish the secure tunnel or security association (SA). A solid understanding of IPsec will help you to configure your VPN correctly. If you already understand IPsec, move directly to Configure an IPsec VPN Connection on page IPsec Headers Operating on the Network Level of the Open Systems Interconnection (OSI) model, IPsec secures IP packets by encapsulating them with an IPsec header, which is either an AH or ESP header. As explained in the next section, the placement of the header depends on the mode. IPsec Modes The TMS zl Module supports both tunnel mode and transport mode. Tunnel Mode. In tunnel mode, the TMS zl Module secures traffic on behalf of endpoints within the private network. The module receives a packet already encapsulated with an IP header. If the packet is selected for the IPsec tunnel, the module encapsulates the IP packet with an IPsec header, as well as a new delivery IP header that directs the packet to the remote tunnel endpoint. 7-5

6 Figure 7-1. Tunnel Mode In tunnel mode, an AH header authenticates both the payload (including the original IP header) and the delivery IP header. An ESP header authenticates only the payload (including the original IP header) but can also encrypt the payload. Transport Mode. In transport mode, a packet is encapsulated with an IPsec header before the IP header is added. Therefore, both ends of the tunnel must be the ultimate originators of the traffic. You can use transport mode to secure traffic for sessions that terminate on the module itself. For example, transport mode is used for the IPsec traffic in L2TP over IPsec connections as well as GRE over IPsec connections because, as the gateway to the L2TP or GRE tunnel, the module is the originator of the L2TP or GRE packet that is encapsulated by IPsec. Figure 7-2. Transport Mode 7-6

7 In transport mode, an AH header authenticates the entire packet including the IP header. The ESP header authenticates only the payload but can also encrypt the payload. Authentication and Encryption Algorithms To provide data integrity, an IPsec tunnel endpoint transforms packets with authentication algorithms. An authentication algorithm uses a specific key to generate a unique message digest for a packet, which the remote endpoint checks using the same key and algorithm. If the data has been altered, the integrity check fails. To provide data privacy, the tunnel endpoint transforms packets with symmetric encryption algorithms. Such an algorithm uses a key to transform data into a new string. Only an endpoint using the same algorithm and key can extract the original data from the encrypted string. The TMS zl Module supports these authentication algorithms for both AH and ESP: Message Digest 5 (MD5) Secure Hash Algorithm (SHA) Advanced Encryption Standard (AES) with Extended Cipher Block Chaining (XCBC) The TMS zl Module supports these encryption algorithms for ESP: Data Encryption Standard (DES) Triple DES (3DES) Advanced Encryption Standard (AES) with 128, 192, or 256-bit keys IPsec Security Associations (SAs) The VPN tunnel itself is called an IPsec security association (SA) and provides the security measures described above. More specifically, a VPN tunnel is defined by two SAs, one for inbound traffic and the other for outbound traffic. An IPsec SA contains information such as the following: Security parameter index (SPI) the ID for the SA, which is included in the IPsec header for each packet that belongs to the SA IPsec header protocol AH or ESP Unique authentication keys DES, 3DES, AES 128, AES 192, or AES 256 Unique encryption keys for ESP MD5, SHA-1 or AES-XCBC Local IP address Public IP address for the local VPN interface Remote IP address Public IP address for the remote VPN interface 7-7

8 When receiving inbound packets, the TMS zl Module first checks the packet for an IPsec header. If an IPsec header is present, the module uses the SPI to identify the packet s SA. The module then uses the keys in the SA to decrypt and authenticate the packet. When sending outbound packets, the TMS zl Module checks whether the packet matches the traffic selector in an active outbound SA. If it does, the module uses the keys in the SA to encrypt and encapsulate the packet. The module also checks whether the packet matches a traffic selector in an IPsec policy. If the packet does, the module uses the associated IKE policy to establish an SA and then uses the SA to encrypt and encapsulate the packet. The TMS zl Module can establish SAs in two ways: Manually Using IKEv1 Defining an SA Manually. You can define the IPsec SA yourself. In this case, you must specify: The SA s SPI The authentication and encryption algorithms The authentication and encryption keys, both inbound and outbound See Create an IPsec Policy That Uses Manual Keying on page Because this method of configuration is relatively unsecure and complex, ProCurve Networking does not generally recommend it. However, manual keying is required when you specify ICMP traffic for the VPN. Defining an SA Using IKE. By far, the more secure and manageable solution for VPN configuration is to allow IKE to negotiate the IPsec SA. IKE regulates the process as hosts authenticate each other, agree upon hash and encryption algorithms, and generate the unique keys used to secure packets. Using IPsec with IKE provides increased security because keys are randomly generated and periodically changed. IKE also eases configuration. Instead of configuring the SA manually, you configure IKE policies. See Create an IKE Policy on page IKE version 1 IKEv1 follows a set process to negotiate the IPsec SA and passes through two phases. The first phase establishes a preliminary tunnel, or IKE SA. The second phase establishes the IPsec SA. When you understand this process, you will find it much easier to configure VPNs on your TMS zl Module. 7-8

9 IKE Phase 1. During phase 1, IKE must complete three tasks: Negotiate security parameters for the IKE SA Generate the keys used to secure data sent over the IKE SA Authenticate the endpoints of the tunnel (the two hosts) Therefor, IKE phase 1 typically involves three exchanges between hosts, or six total messages. Exchange 1: Security parameters. In the first exchange, the endpoint that initiates the VPN connection sends a message to the remote endpoint with one or more security proposals. Each proposal includes one of the options for these parameters: Authentication algorithm: MD5 SHA-1 Encryption algorithm: DES 3DES AES with 128, 192, or 256-bit keys Authentication method: Preshared key Certificates (Digital Signature Algorithm [DSA] or Rivest-Shamir- Adleman [RSA] Signature) Diffie-Hellman group: Group 1 (768) Group 2 (1024) Group 5 (1536) SA lifetime in seconds You will specify these proposals in an IKE policy. 7-9

10 Figure 7-3. IKE Phase 1: Security Parameters Exchange The remote endpoint searches its IKE policies for one that specifies the other endpoint and that includes an identical security proposal. When it finds a match, the remote endpoint returns these security parameters to the original endpoint. If the remote endpoint cannot find a match, the VPN connection fails. This is why it is very important that you match IKE policies at both ends of the connection. Exchange 2: Key generation. You will recall that an SA specifies authentication and encryption keys for transforming traffic. When you use IKE, you only need to configure algorithms, which IKE negotiates in the first exchange. Using the Diffie-Hellman Key Agreement Protocol, IKE generates the actual keys for you during in the second exchange of IKE phase 1. This protocol is a secure method for generating unique, shared keys without sending them over the connection and thus rendering them vulnerable to interception. 7-10

11 Figure 7-4. IKE Phase 1: Key Generation Exchange The final IKE phase 1 exchange and all IKE phase 2 exchanges will be secured by these keys. In this way, IKE provides an additional layer of security; endpoints transmit their authentication information in secured packets, and secured packets negotiate the IPsec SA itself. Exchange 3: Authentication. In the third IKE phase 1 exchange, the tunnel endpoints authenticate each other according to the method agreed upon in the first exchange. The method can be: A preshared key a password known by both endpoints Certificates certificates installed on the endpoints before the connection is initiated Figure 7-5. IKE Phase 1: Authentication The tunnel endpoints also check each other s IDs. When you set up an IKE policy, you specify the TMS zl Module s local ID and the remote ID that it expects from the remote VPN gateway or client. 7-11

12 The ID can be one of these: An IP address A local ID of this type should be the IP address for the interface that handles incoming VPN traffic. Similarly, a remote ID of this type should specify the remote interface to which VPN traffic is destined. The remote ID on one peer must match the local ID on the other peer. A fully qualified domain name (FQDN) A local ID of this type is typically the FQDN of the local VPN gateway. Similarly, a remote ID of this type would be the FQDN of the remote VPN gateway. An address The IKE policy can specify an address as the local or the remote ID. The address does not need to be valid. It simply needs to match the ID expected or transmitted by the peer. An Abstract Syntax Notation distinguished name (ASN.1 DN) Use this type only if the IKE policy specifies certificates for the authentication method. The value is the ASN.1 DN that is associated with the certificate, for example: /CN=TMSzl.procurveu.edu. Note If you use certificates for IKE authentication, you must specify either the DN as the identity type or you must specify a type and value of a subject alternate name that was specified when you generated the IPsec certificate request for the local endpoint. IKE modes. IKE phase 1 can be initiated in one of two modes: Main mode Aggressive mode Main mode consists of the six messages (three exchanges) described above. 7-12

13 Figure 7-6. IKE Aggressive Key Exchange Mode Aggressive mode condenses the process into three total messages two from the initiator and one from the respondent. Aggressive mode is quicker than main. However, it requires endpoints to send identifying information before exchanges are encrypted, so it is less secure. IKE Phase 2. The goal of IKE phase 2 is to negotiate the IPsec SA. For this reason, even though IKE carries out both phases, phase 1 is associated with IKE policies and phase 2 with IPsec policies. Keys generated during IKE phase 2 will secure all data exchanged over the lifetime of the IPsec SA. 7-13

14 Figure 7-7. IKE Phase 2: Security Proposal When negotiating the IPsec SA, IKE follows much the same process it did in IKE phase 1. The initiator sends IKE packets (now secured by the IKE SA), proposing security parameters: IPsec SA lifetime the time in seconds or amount of data in kilobytes before the SA must be renegotiated Perfect forward secrecy (PFS) group an optional setting, required if you want the endpoints to use Diffie-Hellman to generate new keys One or more IPsec proposals. Each proposal includes: An authentication algorithm An encryption algorithm (if using ESP) Traffic selectors the traffic that is allowed over the IPsec SA (VPN tunnel) Other advanced options 7-14

15 The respondent searches its IPsec policies for a match. When it finds a match, it returns the policy to the initiator. IKE then manages the generation and exchange of any hash and encryption keys. It also associates an SPI with the IPsec SA. The endpoints can now transmit data securely over the IPsec SA. XAUTH. XAUTH provides an additional, optional layer of security to IKE. If enabled, XAUTH occurs between IKE phase 1 and IKE phase 2. Most commonly implemented for client-to-site VPNs, XAUTH requires endpoints to authenticate themselves to the network. The TMS zl Module can act as an XAUTH server and require a remote endpoint to authenticate itself to the module s local list of users or a RADIUS database. The module can then apply to the remote user the firewall access policies associated with the group to which the remote user authenticates. T he module can also act as an XAUTH client and authenticate itself to a remote endpoint that requires XAUTH. IKE Mode Config At times you will want to assign a virtual IP address on your organization's private network to remote VPN users. The IKE mode config option can be configured for client-to-site VPNs for example, a VPN used by telecommuters. These users connect to the private network through the VPN tunnel, often from their home Internet connection. IKE mode config assigns virtual private addresses to these mobile users for as long as they connect through the VPN gateway. IKE mode config allows a relatively small pool of mobile users to access the VPN from remote locations. (IKE mode config is not designed for wide-scale management.) The remote client requests an IP address and default gateway from the IPsec Remote Access Server (IRAS) on the TMS zl Module between IKE phase 1 and phase 2 negotiations. It may also request addresses for DNS and WINS servers that will resolve domain names or the user while on the private network. The users appear as internal users on the network once they have received the IKE mode config parameters. When configuring IKE mode config, follow these guidelines. 7-15

16 You can configure IKE config mode only for an IPsec policy that specifies Auto (with IKEv1) for Key Management and that specifies a client-to-site IKEv1 policy. Each IKEv1 client-to-site policy supports only one IP address pool. Microsoft Windows VPN clients and IPSecuritas for Macintosh VPN clients do not support the TMS zl Module implementation of IKE mode config. When configuring the IPsec policy for IKE mode config, on the traffic selector (Step 1 of 4): Local Address must be the local addresses behind the TMS zl Module. You must specify these addresses manually instead of selecting a named object or Any. Remote Address must be the IKE mode config addresses. When configuring firewall access policies for VPNs that use IKE mode config, you must permit traffic between the local zone and the IKE mode config zone. IKE mode config addresses are assigned to a VLAN that is designated irstintxxx on Network > Routing > View Routes, where XXX is a unique threedigit number. Do not create a VLAN association for this VLAN or you will get IP address conflicts. On Network > Routing > View Routes, the irstintxxx VLAN appears as a connected route. Advanced IPsec Features The TMS zl Module supports these advanced features: IP compression Customizable anti-replay window size Extended sequence number Re-key on sequence number overflow Persistent tunnels Fragmentation before IPsec The copying of values from the original IP header The section below describes these features. Table 7-2 indicates which features are enabled by default and other default settings. 7-16

17 Table 7-2. Advanced IPsec Features Feature Default Setting IP compression Disabled Anti-replay window Always enabled default size, 32 Extended sequence number Disabled Re-key on sequence number overflow Enabled Persistent tunnel Disabled Fragment before IPsec Enabled Copy DSCP value from the clear packet Disabled Copy DF bit from the clear packet Enabled IP Compression. Various Data-Link Layer protocols compress packets to decrease the amount of bandwidth that they require. IPsec packets cannot be compressed because such compression would interfere with encryption and with integrity checks. IP compression allows the TMS zl Module to compress IP packets before encryption, which can help to increase network performance. Anti-Replay Window. The TMS zl Module checks the sequence number for IPsec packets within an SA. It drops out-of-order packets to protect against replay attacks (in which hackers snoop legitimate packets and resend them for their own purposes). However, because packets might arrive slightly out of order, the TMS zl Module accepts packets that arrive within the anti-replay window. For example, suppose that the anti-replay window size is at the default, 32. If the highest sequence number that the TMS zl Module has received is 120, the module will accept any packet with a sequence number of 88 or greater. If your VPN users complain of poor quality, you might increase the window size. In particular, you might need to increase the size when the VPN connection uses QoS; low priority packets may arrive later than typically expected. Extended Sequence Number. By default, IPsec uses 32 bits for sequence numbers. Because sequence numbers cannot be reused, this limits an SA to 2 32 (4 million) packets. If your SA has a relatively long lifetime and transmits a great deal of traffic, you might want to enable extended sequence numbers (64 bits) to allow up to 2 64 (18 quintillion) packets. 7-17

18 Re-key on Sequence Number Overflow. As described in the previous section, an SA is limited to 2 32 or 2 64 packets (depending on whether you enabled extended sequence numbers). You can enable the TMS zl Module to automatically renegotiate the SA before it reaches the last sequence number. By default, this feature is enabled. You should typically leave it enabled. Otherwise, if the SA runs out of sequence numbers, it becomes unavailable until its lifetime expires. Persistent Tunnel. An IPsec SA configured as a persistent tunnel always remains open. It is renewed even if it remains inactive longer than the lifetime. You might enable a persistent tunnel for a site-to-site VPN connection. Fragmentation Before IPsec. When you enable this feature, the TMS zl Module detects whether packets will require fragmentation. It even takes into account the extra bytes that will be added by IPsec headers. If fragmentation is necessary, the module fragments the packets first and then encrypts the fragments. Fragmenting the packets before encryption helps the remote tunnel endpoint process and decrypt the packets more quickly. The Copying of Values from the Original IP Header. In tunnel mode, a delivery IP header encapsulates the original IP header. However, the original header might contain information that is important for handling the packet such as: A Differential Services Code Point (DSCP) value, which marks the packet for a particular QoS A Don t Fragment (DF) bit, which specifies whether the packet can be fragmented The TMS zl Module can copy the DSCP value and DF bit from the original IP header to the delivery header. In this way, it ensures the correct handling for the packet. Certificates You can configure IKE to use certificates for authentication during phase 1. Certificates tend to be more secure than preshared keys because they can be unique for each user and are less easily leaked. A certificate itself includes (among other information): A subject name, which identifies the endpoint The host s public key The certificate authority s (CA s) signature 7-18

19 The VPN tunnel endpoints must trust the CAs that sign each other s certificates. The TMS zl Module supports X.509 certificates in Distinguished Encoding Rules (DER) or Privacy Enhanced Mail (PEM) format. For the public/private keypair, it supports DSA and RSA. You can import certificates to the TMS zl Module manually, or you can obtain them automatically using Simple Certificate Enrollment Protocol (SCEP). NAT Traversal VPN users may be behind a device that performs NAT on packets that are destined for the other end of the VPN tunnel. If NAT is performed on packets before they are encrypted, then the packets pass over the VPN connection without difficulty. However, sometimes a device in between the two endpoints of a VPN tunnel performs NAT on packets that have already been encapsulated for the tunnel. As a result of this alteration, packets will fail integrity checks during IKE. In this case, NAT Traversal (NAT-T) is required to notify the tunnel endpoints that the IP addresses will be altered. Figure 7-8 shows an environment that requires NAT-T. In this example, you have configured a VPN to allow remote users to access devices in ZONE1 (VLAN 30) securely over the Internet. The remote client is behind a NAT device, so NAT-T is required. (This example would also apply if the module or both the module and the client were behind NAT devices.) The TMS zl Module automatically establishes NAT-T when required (you do not need to configure any settings). Note, however, that you must create firewall access policies that allow NAT-T traffic in addition to other access policies required for the VPN. See Configure Firewall Access Policies for Your VPN on page Note For a VPN established with manual keying, NAT-T is not required even when one or both of the tunnel endpoints have NAT performed on their traffic. 7-19

20 Figure 7-8. NAT Traversal How NAT Traversal Works. NAT-T uses UDP encapsulation to address this incompatibility between NAT and L2TP over IPsec. UDP encapsulates the IPsec packet in a UDP/IP header. The NAT device changes the address in this header without tampering with the IPsec packet. Peers agree to use NAT-T during IKE negotiations by exchanging a predetermined, known value that indicates that they support NAT-T. When the peers exchange the Diffie-Hellman values, they also send NAT Discovery (NAT-D) packets that include hashes of their source and destination IP addresses and ports. Because one peer s source IP address should be the other s destination address and vice versa, the hashes should match. If they do not, the peers know that somewhere between the two peers, an address was translated by NAT. If the peers discover that NAT has been used, they encapsulate packets in the UDP/IP header. The peer behind the NAT device should also use a one-byte UDP packet that ensures that it keeps the same NAT assignment for the duration of the VPN tunnel. The NAT-T feature on the TMS zl Module automatically detects one or more NAT devices between IPsec hosts and negotiates the UDP encapsulation of the IPsec packets through NAT. 7-20