The BANDIT Products in Virtual Private Networks

Transcription

1 encor! enetworks TM Version A.1, March Encore Networks, Inc. All rights reserved. The BANDIT Products in Virtual Private Networks One of the principal features of the BANDIT products is their use in virtual private networks (VPNs). This document discusses transmission security, VPNs, and the functions a BANDIT device performs to set up and use a VPN connection. Virtual private networks are supported in the original BANDIT, the BANDIT II, the BANDIT III, the BANDIT IP, the BANDIT Mini, the BANDIT Plus, the ILR-100, the VSR-30, and the VSR Note: This document discusses VPNs in the BANDIT II and the BANDIT III. For information on VPNs in other BANDIT models, see the BANDIT Products Software Configuration and Maintenance Guide. A VPN is a secure encrypted transmission between two or more private endpoints over a public network. Tunneling encapsulating data within secure packets isolates the private data from other traffic carried by the public network, providing secure transport over the network. The public network uses the header information in the packets to deliver the packets to their destination. When the destination endpoint receives the packets, it authenticates and unpackages them, and decrypts the data. Note: In the BANDIT II and the BANDIT III, assistance for encryption is integral; the security engine is integrated into the processor core. Assistance for encryption in other BANDIT models is external to the processor core. The VSR-1200 uses HiFn processors for hardware assistance. The VSR-30, the ILR-100, the BANDIT Mini, the original BANDIT, the BANDIT Plus, and the BANDIT IP use an MPC 180 chip for hardware assistance. Use of VPNs allows for dynamic, temporary connections instead of permanent physical connections. This allows an organization to build a private network over the public IP network, reducing the number of leased lines that the organization needs to maintain for connections, resulting in a saving of money. In addition, connection (via VPN client software) over the internet allows business travelers to communicate with the office network from any site that has a connection to the internet. To configure a VPN, see the guide Configuring a BANDIT Product for Virtual Private Networks. Note: For a sample VPN setup conforming to the recommendations of the Virtual Private Network Consortium (VPNC), see the guide VPNC Scenario for IPsec Interoperability. For setup with a VPN client, see the guide Scenarios for Operation with a VPN Client. For information on trademarks, safety, limitations of liability, and similar topics, see Notices. Home Module: VPN Configuration Document 1

2 Page 2 VPN Configuration, Document The BANDIT in Virtual Private Networks This section deals principally with a VPN device s role as a VPN gateway. A VPN device can encapsulate information into IP packets, so it can perform as a VPN gateway over public networks that use IP. The BANDIT II or the BANDIT III can support up to 30 VPN tunnels. As a VPN gateway, a VPN device can perform IPsec tunnel initiation, IPsec tunnel termination, and IPsec passthrough. Those processes use IPsec (described in RFC 2401) for VPN security, performing the functions listed in Table 1-1. Table 1-1. IPsec Components Used in the BANDIT Devices Function Protocols Acronym Standard 1 Key Exchange Internet Key Exchange IKE RFC 2409 Internet Security ISAKMP RFC 2408 Association and Key Management Protocol Encryption Data Encryption Standard DES FIPS PUB 46-2 Triple Data Encryption 3DES FIPS PUB 46-3 Standard Advanced Encryption AES FIPS PUB 197 Standard 2 Security Encapsulating Security ESP RFC 2406 Protocols Payload Authentication Header AH RFC 2402 Authentication Hashed Message Authentication Code: Message Digest 5 HMAC MD5 RFC 2403 Hashed Message Authentication Code: Secure Hash Algorithm 1 HMAC SHA-1 RFC Each publication is from the Internet Engineering Task Force (IETF) unless noted as a Federal Information Processing Standard (FIPS). 2. AES is available on the BANDIT II, the BANDIT III, and the VSR A VPN device from Encore Networks, Inc., can implement tunnels with another Encore Networks VPN device or with another IPsec-compliant VPN gateway or VPN client. The Encore Networks VPN products have the following modes of tunnel use: Tunnel initiation: The device receives packets from a local user terminal. The device encapsulates the packets according to the IPsec user policy, and sends them across the public network to a remote VPN gateway to establish a VPN tunnel. Tunnel passthrough: The device receives IPsec-encapsulated packets from a client VPN terminal, and provides transparent forwarding of the IP packets according to the IPsec user policy. The device sends the packets across the public network without repackaging them.

3 The BANDIT Products in Virtual Private Networks Page 3 Tunnel termination: The device terminates (accepts) an IPsec tunnel initiated by a remote VPN gateway or VPN client across the public network. The device authenticates and unpackages the tunnel s packets, and delivers them to the destination terminal. (To perform tunnel termination, the device must maintain a table of VPN users that function as prospective tunnel initiators. Table 1-4 (on page 13) provides an example of tunnel termination: If a record s Direction is incoming, then the record s Source IP Addresses (in the range from Low to High) indicate one or more remote devices. If the Action is tunnel termination, a device with an IP address in the source range can initiate a tunnel that the local device will accept.) Note: Care must be taken when a VPN connection crosses a device that performs network address translation (NAT). As part of address translation, NAT repackages packets. In certain situations, repackaging will disrupt encrypted VPN packets and render them unintelligible to the VPN tunnel endpoints. (For more information, see the Address Translation module, particularly Address Translation Traversal.) Be sure to use the appropriate configuration when a VPN connection will cross a device that performs NAT: When a BANDIT VPN product uses the Encapsulating Security Payload (ESP) protocol, the connection can cross a device that performs NAT. When the BANDIT product uses the Authentication Header (AH) protocol, the connection must not cross a device that performs NAT. Figure 1-1 illustrates two BANDITs functioning as VPN gateways over the IP network. Figure 1-1. Sample Network: BANDITs as VPN Gateways Figure 1-2 shows a simplified example of the BANDIT s encryption and encapsulation of data. Note: The transmission shown in Figure 1-2 originates from the laptop terminal (IP address ) shown in Figure 1-1, and is destined for the desktop terminal (IP address ) in Figure 1-1. To set up IP routing tables, see IP Routing in the BANDIT Products.

4 Page 4 VPN Configuration, Document 1 Figure 1-2. Sample Encryption and Encapsulation 1.2 Internet Key Exchange When a BANDIT device uses automatic keying, it uses the Internet Key Exchange (IKE) protocol to provide secure transmission between VPN endpoints. IKE negotiates security associations (SAs) and provides authenticated keys for these SAs. (A security association is a set of policies that establish a protected, authenticated connection for data transmission.) IKE can be used to do the following: Set up virtual private networks (VPNs). Provide a remote user secure access to a network. (The remote user s IP address does not need to be known in advance.) Negotiate SAs (and hide identities) for VPN client endpoints. The Internet Key Exchange protocol has two phases: Phase 1 is used for key exchange. In this phase, IKE negotiates the following items to establish an SA for Phase 2: - The encryption algorithm - The hash algorithm - The authentication method - The Diffie Hellman group Phase 2 negotiates an SA for services (such as IPsec) in the transmission. Then this phase is used for data transmission. The BANDIT products implement IKE in conformance to IETF RFC 2409.

5 The BANDIT Products in Virtual Private Networks Page Perfect Forward Secrecy Perfect forward secrecy (PFS) the use of uniquely derived keys to establish security associations (SAs) is an important feature of the IKE protocol. PFS comprises the following principles: Material used to derive one key cannot be used to derive additional keys. No key can be used to derive another key. Discovery of a key endangers only transmissions protected by that key. IKE maintains PFS in the way it performs the following: IKE uses a Diffie-Hellman (DH) exchange to set up phase 1. (A DH exchange protects the identities of the originator and the recipient.) Phase 1 can use main mode or aggressive mode (but not both). Phase 1 establishes an SA for phase 2, as follows: - The originator presents proposals for the SA. (The originator may send an unlimited number of proposals; the recipient can limit the number it will consider.) - The recipient chooses one proposal and sends its response. The recipient cannot change the proposal. If the originator notices that the proposal has changed in any way, the originator refuses the response. - When the originator accepts the response, the SA is set up for phase 2. In phase 2, IKE establishes an SA for data transmission. as follows: - Phase 2 negotiates for services that will be used, such as IPsec. - When the phase 2 SA is ready for data transmission, IKE deletes the SA that phase 1 had established. - In the SA for data transmission, quick mode is used for transmission. Both sides of the connection can transmit data. Instead of extensive authentication, which consumes time and CPU resources, the SA now uses cookies for authentication. The cookie order established in phase 1 (originator vs. recipient) is always used; the cookies do not change order when the transmission direction changes. Note: Each IKE phase has a fixed lifetime. The lifetime can be defined in units of time, number of transmissions, or total amount of transmission (in kilobytes). A phase s lifetime cannot be increased during the phase. 1.3 Tunnel Features The VSR-30 or the original BANDIT can provide 1 to 30 tunnels for use at the same time. The BANDIT Plus provides 1 to 100 tunnels. The VSR-1200 provides 1 to 1200 tunnels. The BANDIT II or the BANDIT III can support up to 30 VPN tunnels. In some situations, a single VPN tunnel can provide services for more than one user. The following subsections discuss VPN tunnel features in the BANDITs.

6 Page 6 VPN Configuration, Document Tunnel Initiation A BANDIT device can initiate a tunnel to another BANDIT device or to another IPseccompliant VPN gateway. When a local user originates packets to the BANDIT, and the packets need to travel over a VPN tunnel, the BANDIT searches its database for an appropriate VPN policy and VPN profile. When an appropriate VPN policy and VPN profile have been determined, the BANDIT contacts the remote VPN gateway specified by the profile, and negotiates a security association. When the gateways agree on an SA and set up a VPN tunnel, the BANDIT encapsulates the packets according to the policy, and sends them across the public network. When the remote VPN gateway receives the packets, it forwards them to the remote destination. Note: In order to use a VPN tunnel, the combination of origination and destination must conform to a VPN policy. Otherwise, the request will be rejected. (The policy specifies the VPN profile that the connection must use; the user must also be authorized to use the specified profile.) Tunnel Termination A BANDIT device can terminate a tunnel for another VPN gateway or for a VPN remote user. When a BANDIT acts as a tunnel terminator, it looks for matches against the following items presented by the VPN gateway that initiated the tunnel: IDs Preshared key Peer (remote) user ID (This can be a group ID or a single ID.) If the values match a VPN policy record, the BANDIT accepts the tunnel termination. Then the BANDIT negotiates the key, and accepts or rejects the proposals presented by the initiating VPN gateway. In Figure 1-3, a VPN remote user initiates a tunnel to the BANDIT s external IP address. Because the remote user s IDs matches a record in the BANDIT s database, the BANDIT agrees to terminate the tunnel. Then, because the VPN remote user wishes to communicate with another site, the BANDIT initiates a tunnel to the other site, so that the VPN remote user can communicate with the site. Table 1-2 lists sample parameters for a remote VPN tunnel user.

7 The BANDIT Products in Virtual Private Networks Page 7 Figure 1-3. VPN Remote User Tunneling to BANDIT Tunneling to VPN Host Table 1-2. Sample Remote User Record Field Peer ID (Remote User ID) Sample Value a1234@encorenetworks.com Preshared Key *********** Profile Group 1,2,4,5 Note: The profile group choices can include up to four VPN profiles. The BANDIT chooses the first profile that the peer ID matches. certificate *********** One of the group choices can be a wildcard. A wildcard means any profile listed in the VPN Profile database. You may list VPN profiles before a wildcard, but there is no need to list any profiles after a wildcard. Note: The remote user s IP address does not need to be known in advance.

8 Page 8 VPN Configuration, Document Tunnel Passthrough Tunnel passthrough is used when a remote or local user sends IPsec-encapsulated packets to the BANDIT device. In passthrough mode, the BANDIT provides transparent forwarding of the IP packets according to the VPN policy. Tunnel passthrough occurs most often when packets are received from a VPN client. If a remote user is using VPN client software, the client sets up a VPN tunnel through the BANDIT to a remote network. In this case, the BANDIT uses passthrough mode; it does not initiate a new tunnel. In Figure 1-3, let the remote user be a VPN client. The client initiates a tunnel to the BANDIT s external IP address. Because the VPN client s IP address is in the BANDIT s tunnel user profile table, the BANDIT terminates the tunnel. Because the VPN client wishes to use a VPN tunnel to communicate with another site, the BANDIT passes the tunnel through to the other site, so that the VPN client can communicate with the site. (This also hides the VPN client s IP address.) Tunnel Sharing More than one VPN profile can specify the same local and remote VPN gateways to reach its remote endpoint. If two such profiles are active at the same time, they are using the same tunnel between the gateways for their VPN connections to different endpoints. This is called tunnel sharing (or tunnel multiplexing) Tunnel Switching A remote endpoint can initiate a VPN tunnel into the network. If the remote endpoint wishes to communicate with a destination endpoint that is outside the network, the BANDIT checks to see whether there is a VPN profile describing a tunnel to the requested destination. If so, the BANDIT initiates a VPN tunnel to that destination, and routes the traffic from the initiating endpoint to the destination. This is called tunnel switching. 1.4 VPNs over Satellite Networks Satellite networks permit telecommunication without laying ground lines. Satellite networks also permit communication across longer distances than do ground-based wireless networks. For reasons of topography or mobility, a satellite connection may be the best telecommunication choice for some users. Remote areas that cannot be reached easily with ground lines and mobile users who may not always be in reach of a ground connection or wireless tower can easily maintain access to a satellite network. The BANDIT III, the VSR-30, the VSR-1200, the ILR-100, the BANDIT Mini, the original BANDIT, and the BANDIT Plus support connection to satellite networks, allowing transmission of information to any location that has a satellite dish including a very small aperture terminal (VSAT), a small dish typically used in remote sites. A BANDIT product usually uses its WAN port for broadband IP connection to a satellite groundstation. Figure 1-4 shows BANDITs connecting LANs across a satellite network.

9 The BANDIT Products in Virtual Private Networks Page 9 Figure 1-4. BANDITs Connecting LANs across a Satellite Network Spoofing Transmissions Most satellite networks use a star topology, with a hub directing transmissions to the proper groundstation. These satellite networks have the following components: Hub (the main groundstation) Satellite Other groundstations Geosynchronous-orbit satellites (satellites that maintain the same position above a geographic point on the earth's surface) orbit at about 22,300 miles (about 35,900 km) above the earth's surface. Because of the distance that transmissions travel from one node (a groundstation) to a satellite node and then to another groundstation node, satellite networks have a significant transmission delay (Figure 1-5) about ½ second per round trip. Figure 1-5. Ground-to-Satellite-to-Ground Transmission Many protocols will time out when they encounter the delay in a satellite network. Others, such as TCP, misinterpret the long delay as network congestion and, as a result, reduce their transmission rate. Because of these problems, a transmission from outside a satellite network is not generally sent directly from endpoint to endpoint across the satellite network. Instead, a groundstation node uses a performance-enhancing proxy (PEP) in its connection with an endpoint outside the satellite network. A PEP spoofs its transmission with the endpoint. Note: Satellite vendors and systems integrators developed PEPs as proprietary mechanisms to spoof TCP over satellite connections. There is not yet an official standard for PEPs.

10 Page 10 VPN Configuration, Document 1 In spoofing, a groundstation s PEP receives a transmission from an originating node outside the satellite network. The PEP acts as if it were the destination endpoint, and sends acknowledgment packets (ACK packets) to the originating node. This allows standard protocols to be used for transmission without timing out, as they would in the delay incurred across the satellite network. While the groundstation s PEP is spoofing its transmission with the originating node, the groundstation is also taking the packets received from the originating node and is transmitting them across the satellite network to another groundstation node, for transmission to the destination endpoint. Satellite networks can use any protocol, including IP, to carry information. For IP transmissions, satellite networks use TCP (in the IP transport layer). Satellite network PEPs read the TCP header in order to send IP transmissions across the satellite network. TCP guarantees delivery of packets and guarantees that the packets will be assembled in the proper sequence Satellite Networks and Security Because satellite networks broadcast transmissions, they are inherently insecure; anyone with a satellite dish can receive a transmission. Therefore, endpoints have to create their own security. Virtual private networks based on the IPsec protocol provide one of the most secure transmissions from endpoint to endpoint over ground-based networks, because no node can decrypt the information except the VPN endpoints. IP Security (IPsec) comes in two formats: Encapsulating Security Payload (ESP) encrypts each user IP packet, including the TCP header, and places it inside a new IP packet generated by the customer s VPN router. Authentication Header (AH) does not encrypt the payload, and thus leaves the TCP header visible. Until now, there have been problems in using VPNs over satellite networks: ESP encryption prevents the PEP from seeing or modifying the TCP header s ACK and Window fields, so these sessions cannot be accelerated. AH s strong authentication process rejects a packet in which PEP modifies a header field; this also prevents acceleration by PEP. If the PEP cannot read the TCP header, it cannot spoof the packet; this inability to spoof the packet slows the transmission over the satellite network. The PEP needs to read the TCP header in order to improve performance. There are several proposed methods for getting around this situation. Most of the proposed methods involve a trade-off of VPN security for TCP use. However, Encore Networks, Inc., has developed a method that maintains VPN security while allowing satellite-network nodes to read TCP headers. This method Selective Layer Encryption improves performance of IPsec-based VPNs over a satellite network Selective Layer Encryption Encore Networks has developed a proprietary technology, Selective Layer Encryption (SLE, patent pending), for VPNs that traverse a satellite network. SLE works with a satellite groundstation s performance-enhancing proxy and maintains VPN security over

11 The BANDIT Products in Virtual Private Networks Page 11 satellite networks. Encore Networks technique preserves the authentication and encryption integrity of the IPsec VPN standards, yet allows the TCP to be spoofed over the satellite connection. Combining the use of SLE and PEP allows delay-sensitive applications to traverse satellite networks. Selective Layer Encryption creates satellite VPN solutions with IPsec that are both secure and channel-efficient. This combination of SLE and PEP significantly increases IPsec performance over satellite networks. Encore Networks, Inc., believes that SLE is the preferred method of maintaining IPsec VPN security over satellite networks. Test results have demonstrated interoperability with different satellite modem vendors that preserve the integrity of TCP fields across the satellite link. (To interpret SLE, a BANDIT VPN product must also sit somewhere on the other side of these modems.) All BANDIT VPN products (the original BANDIT, the BANDIT III, the BANDIT Mini, the BANDIT Plus, the ILR-100, the VSR-30, and the VSR-1200) can use SLE VPNs with satellite networks, and they can support non-sle VPNs over ground-based networks. A single BANDIT device in one of these models can support both types of VPNs at the same time. Figure 1-6 shows a sample satellite network combining PEP and the BANDIT s SLE. Note: To configure SLE, see the document Section 3.5, Configuring Selective Layer Encryption in VPNs, in Revising a BANDIT Product s VPN Configuration. Figure 1-6. Sample Satellite Network Configuration Using Encore Networks VPN with SLE

12 Page 12 VPN Configuration, Document Preparing for VPN Configuration Table 1-3 lists the information needed to set up a VPN tunnel. Note: For procedures to configure a BANDIT device for virtual private network connections, see the document Configuring a BANDIT Product for Virtual Private Networks. For a sample VPN setup, conforming to the recommendations of the VPN Consortium (VPNC), see the document VPNC Scenario for IPsec Interoperability. To set a VPN up to accept a tunnel from a traveling client, see the document Scenarios for Operation with a VPN Client. Table 1-3. Information Required to Configure BANDIT Products for VPNs Item Central Site Remote Site WAN IP Address WAN Subnet Mask WAN Default Router, a.k.a. Default Gateway VPN Gateway IP Address or DNS Name (required only for end that initiates tunnel) LAN IP Address LAN Subnet Mask DHCP IP Address Pool (Range, from low to high) Usually a Public Address supplied by your Internet Service Provider, e.g., 68.x.x.34 Subnet Mask for the address above, e.g., The Next Hop router for the WAN IP Address, e.g., 68.x.x.33 Required only if Central Site is the initiator. This will be the WAN IP Address of the Remote Site Unit or the DNS Name of the Remote Site Unit e.g., 65.x.x.72 or bandit@remote.com. Fixed address on the LAN segment to be assigned to the router LAN port, e.g., Subnet Mask for the address above, e.g., If the router is to issue IP addresses via DHCP on the LAN side, enter the address range here, e.g., to Supplied by the VSAT service provider, e.g., 65.x.x.72. If it is issued by the satellite modem operating as a DHCP server, select Dynamic. Subnet Mask for the address above, e.g., (not applicable if WAN IP Address is dynamic) IP Address of the satellite modem, e.g., 65.x.x.65 (not applicable if WAN IP Address is dynamic) Required only if Remote Site is the initiator. This will be the WAN IP Address of the Central Site Unit or the DNS Name of the Central Site Unit e.g., 68.x.x.34 or bandit@central.com. Fixed address on the LAN segment to be assigned to the router LAN port, e.g., Subnet Mask for the address above, e.g., If the router is to issue IP addresses via DHCP on the LAN side, enter the address range here, e.g., to Additional Security Information Required... User ID Preshared Key... When Running SLE or IPsec Encryption Must be the same at both ends, e.g., user1@site2 or test123 Maximum of 18 characters. Must be the same at both ends, e.g., e2we36tjk@s8h12q...if VSR is to Provide DNS Information Primary DNS Address Secondary DNS Address

13 The BANDIT Products in Virtual Private Networks Page VPN Configuration Plan The following tables provide an example of planning a configuration for your virtual private network users. Table 1-4 is a sample IP Policy Table. (Your BANDIT device s IP Policy Table may include additional fields.) IP Policy Tables are used to establish processes and types of connections. The BANDIT s IP Policy Table is described in IP/VPN Policy. Table 1-4. Sample IP Policy Table Field Value for Record 1 Value for Record 2 Low IP Address for Source High IP Address for Source Low IP Address for Destination High IP Address for Destination Global Path LAN LAN... Direction Outgoing Incoming... Action Tunnel Tunnel... Initiation Termination Description Tunnel A Terminate P27... VPN Profile Used Profile 1 Profile 7... Records 3, 4, 5,... The IP Policy Table must include a field naming the profile used in the policy. (In Table 1-4, this is the field VPN Profile Used.) The value in this field cross-references the profile s configuration, shown in a VPN Profile Table. Table 1-5 shows a sample VPN profile table, with the field VPN Profile Name crossreferenced against profiles listed in the IP Policy Table. (Your VPN Profile Table may show additional fields.) The BANDIT s VPN Profile Table is described in the document Configuring a BANDIT Product for Virtual Private Networks. You also need to configure an IP Routing Table. See IP Routing in the BANDIT Products. Note: Site Planning Worksheets contains worksheets for preparing entries for the BANDIT s IP Policy Table and VPN Profile Table. Table 1-5. Sample VPN Profile Table (Sheet 1 of 2) Field 1 Value for Record 1 Value for Record 2 Records 3, 4, 5,... VPN Profile Name Profile 1 John s VPN Connection... Local ID (User ID) Set_1@encorenetworks.com... Remote VPN Gateway Address Keying Manual 2 Auto-Key... Security Protocol ESP...

14 Page 14 VPN Configuration, Document 1 Table 1-5. Sample VPN Profile Table (Sheet 2 of 2) Field 1 Value for Record 1 Value for Record 2 Records 3, 4, 5,... Local SPI 1ffff... Remote SPI Authentication Mode Main mode, Aggressive mode... Authentication Protocol HMAC-SHA1... Authentication Key 48454C4C4F Preshared key ******... Encryption 3DES... Encryption Key 48454C4C4F Phase 1, Proposal 1 PRE-G2-DES-MD5... Phase 1, Proposal 2 VSA-G2-3DES-SHA... Phase 2, Proposal 1 STD-G2-3DES-MD5... Phase 2, Proposal 2 PFS-G2-3DES-SHA... Replay Protection enabled... User ID Verification enabled... Password Verification disabled... Timeout A VPN Profile Table includes all records those that use fields for manual keying and those that use fields for autokeying. (Some fields are used by both types of records.) When the user specifies the type of keying the profile will use, the BANDIT presents for configuration only the fields that apply to the specified keying. (Table 1-6 presents parameters for manual keying. Table 1-7 presents parameters for autokeying.) 2. The BANDIT products do not use manual keying in normal operation. If you wish to use manual keying, contact your Encore Networks representative Manual Keying Note: With software version 0171 and above, the BANDIT products do not use manual keying in normal operation. If you wish to use manual keying in a BANDIT, contact your Encore Networks representative. Manual keying the use of manual keys for authentication and encryption was the original method of exchanging security information between two VPN gateways. This method involves manually entering long strings of characters. The keys do not change during the connection, and may be used for subsequent connections as well. Because the authentication and encryption keys are constant, manual keying is vulnerable to persistent attack, and thus does not provide much security.

15 The BANDIT Products in Virtual Private Networks Page 15 Today manual keying is used mostly for troubleshooting VPN connections. Except for troubleshooting, most VPN gateways now use automatic keying to set up VPN connections. (Autokeying provides excellent security because the keys are always changing and being renegotiated. IKE autokeying is the industry-preferred option for VPN tunnel negotiation. See Section 1.5.3, Automatic Keying.) Table 1-6 shows sample parameters used to set up manual keying for a VPN connection. Table 1-6. Sample VPN Profile, Manual Keying Field Sample Values Profile Name profile 1 Keying manual Remote Gateway w.w.w.w Security Protocol ESP Local SPI 1 **** Remote SPI 1 *** Authentication Protocol MD5, SHA-1 Authentication Key ****************************** Encryption Protocol 3DES, DES Encryption Key **************************** 1. If keying is manual, the SPI (security parameter index) must be indicated Automatic Keying In autokeying, keys are dynamic, always changing. Special keys are exchanged at the beginning of the connection, and the VPN gateways negotiate other keys for the connection. If desired, keys can be timed out, and new keys can be negotiated for subsequent parts of the connection. The BANDIT products use the Internet Key Exchange (IKE) protocol for automatic generation of keys in VPN connections. When a BANDIT uses the automatic keying feature, an IKE tunnel is set up for key exchange. The IKE tunnel sets up keys for the subsequent data tunnel. The data tunnel is used for data exchange. See Section 1.2, Internet Key Exchange. Table 1-7 shows sample parameters to set up automatic keying for a VPN connection. Table 1-7. Sample VPN Profile, Automatic Keying (Sheet 1 of 2) Sample Fields Sample Values Authentication Mode Local ID (User ID) 1 Remote Gateway IP Address 2 Main mode (also known as ID Protection), Aggressive mode Set_1@encorenetworks.com Preshared Key 3 ******

16 Page 16 VPN Configuration, Document 1 Table 1-7. Sample VPN Profile, Automatic Keying (Sheet 2 of 2) Sample Fields Sample Values Phase 1, Proposal 1 4 Phase 1, Proposal 2 Phase 2, Proposal 1 Phase 2, Proposal 2 Replay Protection PRE-G2-DES-MD5 VSA-G2-3DES-SHA STD-G2-3DES-MD5 PFS-G2-3DES-SHA Enable/Disable 1. There are three formats for the local ID: format: ascii-format@ascii-format IP address format: x.x.x.x Perfect domain name format: hostdomain.net 2. There are two kinds of remote IP addresses: static and dynamic. 3. The preshared key is used to establish the IKE tunnel. This preshared key must be protected as a super-password. The preshared key uses Diffie Hellman Exchange 2 (DH2). 4. The BANDIT lets you provide up to four proposals per phase. The recipient must choose at least one proposal for each phase. Table 1-8 and Table 1-9 illustrate sample proposal combinations for phase 1 and phase 2, respectively. Table 1-8. Sample Phase 1 Proposal Sample Fields Sample Values 1 Authentication mode Diffie Hellman (DH) group Encryption Authentication Lifetime 2 Lifetime units 2 preshared group 2 DES, 3DES HMAC-MD5, HMAC-SHA units seconds, minutes, hours, days 1. This sample proposal is tunnel-specific, not session-specific. 2. When the lifetime is reached for the indicated unit, a new key is exchanged.

17 The BANDIT Products in Virtual Private Networks Page 17 Table 1-9. Sample Phase 2 Proposal Sample Fields Perfect forward secrecy (PFS) Security protocol Encryption Authentication Lifetime 1 Lifetime unit 1 Sample Values none DH2 (Diffie Hellman 2) ESP AH 3DES DES HMAC-MD5 HMAC-SHA units number of seconds number of minutes number of hours number of days kilobytes of data sent through the tunnel 1. When the lifetime is reached for the unit indicated, a new key is exchanged Sample Configuration for a Remote User Figure 1-3 shows a VPN remote user tunneling to a BANDIT gateway. The BANDIT, in turn, has created a tunnel to a VPN host at another site. Table 1-10 lists a sample set of values for the connection between the BANDIT and the remote user. Table Sample Tunnel User Table (Sheet 1 of 2) Fields Values Profile Name profile 2 Authentication Mode Keying Local User ID aggressive auto-ike agency_a@encorenetworks.com Gateway Preshared Key ******** Phase 1, Proposal 1 Phase 1, Proposal 2 PRE-G2-DES-MD5 VSA-G2-3DES-SHA

18 Page 18 VPN Configuration, Document 1 Table Sample Tunnel User Table (Sheet 2 of 2) Fields Values Phase 2, Proposal 1 Phase 2, Proposal 2 Replay Protection STD-G2-3DES-MD5 PFS-G2-3DES-SHA enable To configure VPNs for remote users, see the document Scenarios for Operation with a VPN Client. 1.6 Testing and Tracking VPN Connections To implement a VPN connection, see the document Testing and Tracking VPN Connections. Note: Before you can use or track VPN connections, you must configure the BANDIT device for VPNs, as described in the document Configuring a BANDIT Product for Virtual Private Networks.