Phase 1 of an AutoKey IKE tunnel negotiation consists of the exchange of proposals for how to authenticate and secure the channel. The exchange can be in one of two modes: aggressive or main. Using either mode, the participants exchange proposals for acceptable security services.
Tunnel
Both end points need to agree on the same proposal for Phase 1 and four possible Phase 1 proposal types are defined:
• Method: indicates a preshared key (“pre”) or digital certificate (using “RSA”-Sig or
“DSA”-Sig) used as the authentication method
• DH Group: Indicates the Diffie-Hellman group used for the key generation or exchange (“g1”, “g2” or “g5”)
• Encrypt/Auth: Indicates the encryption algorithm (“3DES”, “DES” or “AES”) and hash algorithm (“MD5” or “SHA-1”) used
Examples of Phase 1 proposals i:
• pre-g2-3des-sha1
• pre-g1-des-md5
• dsa-g2-3des-sha1
• rsa-g5-aes128-md5
Once IKE has been used to establish a tunnel to provide a secure channel of communication, IPSec is used to provide a means of securing the actual data that will traverse the tunnel.
Key lifetime indicates the life of the key (how often the key should be changed) and can be configured in terms of seconds, minutes hours or days. A Phase 1 tunnel may still be established when both ends use different key lifetimes but when one end decides to change its key the tunnel will fail.
PHASE 2 PROPOSAL
Once the tunnel has been established (Phase 1), the SAs to secure the data to be transmitted through the IPsec tunnel are negotiated (Phase 2).
Proposals are exchanged to determine the security parameters to be used for the SA. Phase 2 proposals also include a security protocol—either Encapsulating Security Payload (ESP) or Authentication Header (AH)—and selected encryption and authentication algorithms. The proposal can also specify a DH group and if Perfect Forward Secrecy (PFS) is desired.
Regardless of the mode used in Phase 1, Phase 2 always operates in quick mode and involves the exchange of three messages. Juniper Networks Firewalls support up to four proposals for Phase 2 negotiations, allowing you to define how restrictive a range of tunnel parameters you will accept. ScreenOS also provides a replay protection feature but use of this feature does not require negotiation because packets are always sent with sequence numbers, so you have the option of checking or not checking the sequence numbers.
• PFS: “nopfs” indicates PFS is not used, “g1”, “g2” or “g5” indicates which DH group is being applied.
Page | 18
• Encapsulation: ESP (“esp”) or AH (“ah”) protocol is being used for encryption and authentication.
• Encryption/Authentication: encryption (“DES”, “3DES” or “AES”) and/or the hash algorithm (“MD5” or “SHA1”) used.
Examples of a Phase 2 proposal:
• g2-esp-3des-sha1
• nopfs-esp-des-md5
• g1-ah-null-sha1
IPSEC STANDARD ELEMENTS
Internet Key Exchange (IKE)
The Internet Key Exchange (IKE) protocol a separate protocol and used to automatically generate and negotiate keys and Security Associations. A preshared key or a digital certificate can be used to secure communication between two end points through a VPN tunnel. IKE uses the preshared or public key bound to the certificate to automatically change keys at
predetermined intervals. IKE uses the Diffie-Hellman (DH) key exchange algorithm to allow the secure key exchange. There are five different groups and NetScreen’s supports the following three:
• DH Group 1: 768-bit Modulus
• DH Group 2: 1024-bit Modulus
• DH Group 5: 1536-bit Modulus
The larger the modulus, the more secure the generated key is considered to be.
IPSEC PACKET FLOW
The following shows the packet flow sequence from the initiator to the recipient for a Route-based VPN, The differences for a Policy-Route-based VPN are discussed later
FROM THE INITIATOR:
1. Host attempts to send a packet destined for an IP address on the recipient network via its default gateway.
2. Packet arrives at the egress interface which is bound to one of the zones (Trust zone for this example).
3. With SCREEN options enabled for the zone the NetScreen firewall activates the SCREEN module.
4. The session module then performs a session lookup trying to match the packet with an existing session.
5. The address-mapping module checks if a Mapped IP (MIP) configuration uses the destination IP address.
6. The route module performs a route lookup for the destination IP address and sees that the traffic needs to be routed through a tunnel interface. The tunnel interface is bound to a VPN tunnel and from the ingress and egress interfaces the firewall works out the source and destination zones and can now do a policy lookup.
Page | 19
7. The policy engine performs a policy lookup between the two zones. From the policy match, the policy engine performs the policy action (“permit “for this example).
8. The IPSec module checks if an active Phase 2 security association (SA) with the remote gateway exists and if so the process skips to step 10. If not, the next step is initiated.
9. The IKE module checks if an active Phase 1 SA exists with the remote peer and if so the IPSec module attempts to establish a Phase 2 negotiation. The process continues to the next step on successful completion of Phase 2 negotiation. If Phase 1 negotiations fail, traffic will fail at this point.
10. The IPSec module encapsulates the packet using the appropriate protocols (tunnel mode using ESP in this example). The packet is appended with a new header which includes the outgoing interface’s IP address as its source IP address and the remote gateway’s IP address as the destination. The packet’s payload is then encrypted to the next header field in the original IP header and authenticated from the ESP trailer to the ESP header.
11. The firewall sends the encrypted and authenticated packet destined for the remote gateway through the outgoing interface to the next-hop-gateway.
FROM THE RECIPIENT:
1. Packet arrives at the external interface bound to a particular zone (Untrust zone for this example).
2. Using the SPI, destination IP address, and IPSec protocol contained in the outer packet header, the IPSec module attempts to locate an active Phase 2 SA with the initiating peer along with the keys to authenticate and decrypt the packet. If successful, the firewall moves onto step 4. If an active Phase
3. SA cannot be found, the NetScreen moves onto the next step.
4. IKE module checks if an active Phase 1 SA exists with the remote peer. If a Phase 1 SA does not exist, the NetScreen attempts to establish a Phase 1 tunnel with the remote gateway.
5. IPSec module performs an anti-replay check.
6. IPSec module attempts to authenticate the packet.
7. Using the Phase 2 SA and keys, the IPSec module decrypts the packet, uncovering its original source address (the original host that send the packet) and its ultimate
destination (the original destination of the packet). The firewall determines which VPN the packet came through, and as a result, which tunnel interface the VPN was bound to.
From this point forward, the firewall treats the packet as if its ingress interface is the tunnel interface. It also adjusts the anti-replay sliding window at this point.
8. If SCREEN options have been enabled for the zone, the firewall activates the SCREEN module at this point.
9. The session module performs a session lookup, attempting to match the packet with an existing session. It then either performs First Packet Processing or Fast Processing.
10. The address-mapping module checks if a mapped IP (MIP) or virtual IP (VIP) configuration uses the original destination IP address.
11. The route module first uses the ingress interface to determine the virtual router to use for the route lookup. It then performs a route lookup for the destination and determines which interface it needs to send the packets out from. By determining the ingress interface and the egress interface, the NetScreen can thereby determine the source and destination zones. It is now possible to perform a policy lookup on the respective zones.
12. The policy engine checks its policy list from the source zone to the destination zone and finds a policy that grants access (or possibly denies access).
13. The firewall then forwards the packet through the interface to the destination host.
Page | 20
The packet flow for a Policy-based VPN is the same apart from the following points:
FROM THE INITIATOR:
Route Lookup: To determine the destination zone, the route module does a route lookup for the destination IP address. As there is more than likely not a route for that particular IP address, the NetScreen uses the default gateway and the zone associated with the ultimate outgoing interface (let us assume it’s the Untrust zone). By determining the ingress and egress interfaces, the firewall has thereby determined the source and destination zones, and can now perform a policy lookup.
Policy Lookup: The policy engine does a policy lookup between the two zones. The lookup matches the source address and zone, destination address and zone, and service and finds a policy that references a VPN tunnel.
The NetScreen device then forwards the packet through to the destination using the VPN tunnel configured in the policy.
FROM THE RECIPIENT:
The inbound packet flow on the recipient end is the same for both route-based and policy-based VPN configurations except that the tunnel is not bound to tunnel zone. The NetScreen device learns that the packet came through vpn1 which is bound to the Untrust-Tun tunnel zone whose carrier zone is the Untrust zone. Unlike route-based VPNs the firewall considers ethernet3 to be the ingress interface of the decrypted packet - not tunnel.1.
Route Lookup: The route module performs a route lookup for destination IP address and discovers the relevant interface and zone for the delivery of the packet. By learning the source zone and determining the destination zone based on the egress interface, the firewall can now check for a policy from the respective zones that references the VPN tunnel.
Policy Lookup: The policy engine checks its policy list from the source zone to the destination zone and finds a policy that references the VPN tunnel.
The NetScreen then forwards the packet to its destination.
NOTE: Unlike a Route-based VPN a Policy-based VPN isn’t reliant on a tunnel interface. Instead, all VPNs are bound to a tunnel zone (the Untrust-tunnel-zone). The tunnel zone relies on the carrier zone (Untrust zone in our example) to determine which zones it should use for policy lookup. The physical interface the packet arrives on is used as the ingress interface as opposed to the tunnel interface in a Route-based VPN situation.
MODES
IKE supports two modes of negotiation, Main mode and Aggressive mode. Main mode is the standard method used for site-to-site VPNs with static peers and Aggressive mode is used for VPN clients and sites with dynamic IP addresses.
The VPN tunnel initiator and the recipient send three two-way exchanges, six messages in Main mode.
Page | 21
1. Messages 1 and 2: Propose and accept the encryption and authentication algorithms 2. Messages 3 and 4: Diffie-Hellman exchange with initiator and recipient providing a
nonce (randomly generated number)
3. Messages 5 and 6: Send and verify identities
Exchanging identity information after Messages 3 and 4, after an encryption method has been established ensures the identity information remains secure.
Aggressive mode establishes a secure tunnel but requires two exchanges with a total of three messages.
1. Message 1: The VPN tunnel initiator proposes the SA, initiates Diffie-Hellman key exchange, sends a nonce and its IKE identity
2. Message 2: The recipient accepts the SA, authenticates the initiator, sends a nonce, its IKE identity and its digital certificate (if digital certificates are in use)
3. Message 3: The initiator authenticates the recipient, confirms the exchange and sends its digital certificate (if digital certificates are in use)
Identities of both parties are sent in the clear so Aggressive mode does not provide identity protection.
PERFECT FORWARD SECRECY
Phase 2 can use this same key for the purposes of its encryption when no Perfect Forward Secrecy (PFS) is enabled. PFS requires another separate key to be generated using DH for Phase 2 usage. This increases security as a compromise in Phase 1 keys does not equate to a
compromise in Phase 2 keys.
SECURITY ASSOCIATIONS
A security association (SA) is a unidirectional agreement between the VPN participants regarding the methods and parameters to use in securing a communication channel. Full bidirectional communication requires at least two SAs, one for each direction.
An SA groups together the following components for securing communications:
Security algorithms and keys
Protocol mode (transport or tunnel)
Key-management method (manual key or AutoKey IKE)
SA lifetime
For outbound VPN traffic, the policy invokes the SA associated with the VPN tunnel. For inbound traffic, the Firewall looks up the SA by using the following triplet:
• Destination IP
• Security protocol (AH or ESP)
Security parameter index (SPI) value
PROTOCOLS
To secure packets destined for a VPN tunnel there are two protocols:
Authentication Header (AH) provides authenticity and integrity of the content and origin of a packet. This is achieved with either an MD5 or SHA-1 hash algorithm. AH
Page | 22
leaves the packet payload in its original form with an AH header appended to the packet header.
Encapsulation Security Payload (ESP) provides security of data by encrypting the packet’s payload. ESP supports the DES, 3DES and AES protocols for encryption and an ESP header is appended to the packet.
ENCAPSULATION MODES
IPsec operates in one of two modes—transport or tunnel. When both ends of the tunnel are hosts, you can use either mode but when at least one of the endpoints is a security gateway (router or firewall) you must use tunnel mode. Juniper Networks Firewalls always operate in tunnel mode for IPsec tunnels and transport mode for L2TP-over-IPsec tunnels.
Transport mode retains the original header, the newly appended header (either AH or ESP) and the payload.
Tunnel mode encapsulates the whole packet (including the original header) into a new packet and appends a new header to the packet.
POLICY/ROUTE-BASED VPN CONFIGURATION
A Policy Based VPN is a configuration in which a specific VPN tunnel is referenced in a policy whose action is set as Tunnel. The tunnel icon appears as either a Lock or as a Lock with directional arrows as shown in the sample below. The icon below indicates the policy is configured for a Bi-Directional Tunnel.
Common Reasons to use a Policy-based VPN:
Remote VPN device is a non-Juniper device
Need to access only one subnet or one network at the remote site, across the VPN CONFIGURING A SITE-TO-SITE POLICY-BASED VPN
In order to configure a Policy-based VPN, complete the following steps:
Preshared Keys:
set ike gateway gw-name address remote-gw main outgoing-interface phy-interface preshare preshared-key proposal p1-proposal
set vpn vpn-name gateway gw-name sec-level p2-proposal
Page | 23
Digital Certificates:
set ike gateway gw-name address remote-gw main outgoing-interface phy-interface proposal p1-proposal
set ike gateway gw-name cert peer-ca CA
set ike gateway gw-name cert peer-cert-type ca-type set vpn vpn-name gateway gw-name sec-level p2-proposal Bi-directional policies referring to the tunnel:
set policy top name “policy-name” from src-zone to dst-zone source-net remote-net any tunnel vpn vpn-name
set policy top name “policy-name” from src-zone to dst-zone remote-net source-net any tunnel vpn vpn-name
ROUTE-BASED VPNS
With Route Based VPNs the network topology configuration is removed from the VPN policy configuration. The VPN policy creates a Tunnel Interface between two end points. Static routes can be added to the Tunnel Interface.
The Route Based VPN moves network configuration from the VPN policy configuration to Static Route configuration. This requires changes only to the Static Route when network topology changes.
Route Based VPNs must include the following configuration information:
• Tunnel Interface
• Phase I VPN Gateway configuration (listed under VPNs > AutoKey Advanced > Gateway on the WebUI)
• Phase II VPN configuration (listed under VPNs > AutoKey IKE on the WebUI); including:
o Local and Remote Proxy ID
o VPN configuration bound to tunnel interface
• Route for remote network pointing to tunnel interface
• Policy specifying action of "Permit" to allow traffic
CONFIGURING A ROUTE-BASED SITE-TO-SITE VPN
The configuration for a Route-based VPN requires additional steps. Firstly, create and define the tunnel interface:
set interface tunnel-int-name zone zone
set interface tunnel-int-name ip unnumbered interface phy-interface
NOTE: For a standard Site-to-Site Route-based VPN, the tunnel interface can be configured as unnumbered so it will take on the IP address of the physical interface it’s bound to. In advanced Route-based VPN configurations, you can assign the tunnel interface an IP address for NATing.
The creation of the VPN is quite similar to that of a Policy-based VPN but with one difference.
The tunnel interface must be bound to the VPN tunnel and a proxy-ID must be manually configured:
Page | 24
Preshared Key:
set ike gateway gw-name address remote-gw main outgoing-interface phy-interface preshare preshared-key proposal p1-proposal
set vpn vpn-name gateway gw-name sec-level p2-proposal set vpn vpn-name bind interface tunnel-int-name
set vpn vpn-name proxy-id local-ip local-proxy-id/mask remote-ip remote-proxy-id/mask service
Digital Certification:
set ike gateway gw-name address remote-gw main outgoing-interface phy-interface proposal p1-proposal
set ike gateway gw-name cert peer-ca CA
set ike gateway gw-name cert peer-cert-type ca-type set vpn vpn-name gateway gw-name sec-level p2-proposal set vpn vpn-name bind interface tunnel-int-name
set vpn vpn-name proxy-id local-ip local-proxy-id/mask remote-ip remote-proxy-id/mask service
Route-based VPN’s are instigated through the routing of traffic to a particular destination, and as such, a static route needs to be added:
set vrouter vrouter route remote-net interface tunnel-int-name
A security policy can be used to control traffic outbound to and inbound from the tunnel:
set policy top name “policy-name” from src-zone to dst-zone source-net remote-net any permit
set policy top name “policy-name” from src-zone to dst-zone remote-net source-net any permit
NOTE: If the tunnel interface is bound to the same zone as the destination zone and Intrazone blocking is disabled, a security policy is not required to permit the traffic. It is assumed that all traffic is permitted by default. Binding the tunnel interface to a different zone requires the use of a security policy to explicitly permit traffic.
PROXY-IDS
The proxy-ID determines which networks and services are permitted through the VPN and is made up of the local network, remote network and service. Both end points of the VPN exchange their proxy-ID which needs to match for the Phase 2 negotiation to be complete.
If a Policy-based VPN is being used, the necessary proxy-ID information resides in the policy e.g.
source, destination and service.
If Route-based VPN is being used, a policy may not be necessary, and if so, may not contain the correct information to create the proxy-ID. In this case the proxy-ID must be manually entered when configuring Route-based VPNs.
Page | 25
NOTE: By manually specifying a proxy-ID in a Policy-based VPN scenario, it will overwrite the proxy-ID automatically obtained from the security policy.
HUB/SPOKE CONFIGURATIONS
If two VPN tunnels terminating at the Firewall are set up, it is possible to have routes so that the
If two VPN tunnels terminating at the Firewall are set up, it is possible to have routes so that the