IPSEC WORKING IN PALO ALTO

PALO ALTo IPSEC

The IP Security (IPSec) set of protocols is used to set up a secure tunnel for the VPN traffic, and the information in the TCP/IP packet is secured (and encrypted if the tunnel type is ESP). The IP packet (header and payload) is embedded in another IP payload, and a new header is applied and then sent through the IPSec tunnel. The source IP address in the new header is that of the local VPN peer and the destination IP address is that of the VPN peer on the far end of the tunnel. When the packet reaches the remote VPN peer (the firewall at the far end of the tunnel), the outer header is removed and the original packet is sent to its destination.

In order to set up the VPN tunnel, first the peers need to be authenticated. After successful authentication, the peers negotiate the encryption mechanism and algorithms to secure the communication. The Internet Key Exchange (IKE) process is used to authenticate the VPN peers, and IPSec Security Associations (SAs) are defined at each end of the tunnel to secure the VPN communication. IKE uses digital certificates or preshared keys, and the Diffie Hellman keys to set up the SAs for the IPSec tunnel.The SAs specify all of the parameters that are required for secure transmission— including the security parameter index (SPI), security protocol, cryptographic keys, and the destination IP address—encryption, data authentication, data integrity, and endpoint authentication.

The following figure shows a VPN tunnel between two sites. When a client that is secured by VPN Peer A needs content from a server located at the other site, VPN Peer A initiates a connection request to VPN Peer B. If the security policy permits the connection, VPN Peer A uses the IKE Crypto profile parameters (IKE phase 1) to establish a secure connection and authenticate VPN Peer B. Then, VPN Peer A establishes the VPN tunnel using the IPSec Crypto profile, which defines the IKE phase 2 parameters to allow the secure transfer of data between the two sites.

Site-to-Site VPN

Site-to-Site VPN Concepts

A VPN connection provides secure access to information between two or more sites. In order to provide secure access to resources and reliable connectivity, a VPN connection needs the following components:

• IKE Gateway
• Tunnel Interface
• Tunnel Monitoring
• Internet Key Exchange (IKE) for VPN
• IKEv2

IKE Gateway

The Palo Alto Networks firewalls or a firewall and another security device that initiate and terminate VPN connections across the two networks are called the IKE Gateways. To set up the VPN tunnel and send traffic between the IKE Gateways, each peer must have an IP address—static or dynamic—or FQDN. The VPN peers use preshared keys or certificates to mutually authenticate each other.

The peers must also negotiate the mode—main or aggressive—for setting up the VPN tunnel and the SA lifetime in IKE Phase 1. Main mode protects the identity of the peers and is more secure because more packets are exchanged when setting up the tunnel. Main mode is the recommended mode for IKE negotiation if both peers support it. Aggressive mode uses fewer packets to set up the VPN tunnel and is hence faster but a less secure option for setting up the VPN tunnel.

Tunnel Interface

To set up a VPN tunnel, the Layer 3 interface at each end must have a logical tunnel interface for the firewall to connect to and establish a VPN tunnel. A tunnel interface is a logical (virtual) interface that is used to deliver traffic between two endpoints. If you configure any proxy IDs, the proxy ID is counted toward any IPSec tunnel capacity.

The tunnel interface must belong to a security zone to apply policy and it must be assigned to a virtual router in order to use the existing routing infrastructure. Ensure that the tunnel interface and the physical interface are assigned to the same virtual router so that the firewall can perform a route lookup and determine the appropriate tunnel to use.

Typically, the Layer 3 interface that the tunnel interface is attached to belongs to an external zone, for example the untrust zone. While the tunnel interface can be in the same security zone as the physical interface, for added security and better visibility, you can create a separate zone for the tunnel interface. If you create a separate zone for the tunnel interface, say a VPN zone, you will need to create security policies to enable traffic to flow between the VPN zone and the trust zone.

To route traffic between the sites, a tunnel interface does not require an IP address. An IP address is only required if you want to enable tunnel monitoring or if you are using a dynamic routing protocol to route traffic across the tunnel. With dynamic routing, the tunnel IP address serves as the next hop IP address for routing traffic to the VPN tunnel.

If you are configuring the Palo Alto Networks firewall with a VPN peer that performs policy-based VPN, you must configure a local and remote Proxy ID when setting up the IPSec tunnel. Each peer compares the Proxy-IDs configured on it with what is actually received in the packet in order to allow a successful IKE phase 2 negotiation. If multiple tunnels are required, configure unique Proxy IDs for each tunnel interface; a tunnel interface can have a maximum of 250 Proxy IDs. Each Proxy ID counts towards the IPSec VPN tunnel capacity of the firewall, and the tunnel capacity varies by the firewall model.

Tunnel Monitoring

For a VPN tunnel, you can check connectivity to a destination IP address across the tunnel. The network monitoring profile on the firewall allows you to verify connectivity (using ICMP) to a destination IP address or a next hop at a specified polling interval, and to specify an action on failure to access the monitored IP address.

If the destination IP is unreachable, you either configure the firewall to wait for the tunnel to recover or configure automatic failover to another tunnel. In either case, the firewall generates a system log that alerts you to a tunnel failure and renegotiates the IPSec keys to accelerate recovery.

Internet Key Exchange (IKE) for VPN

The IKE process allows the VPN peers at both ends of the tunnel to encrypt and decrypt packets using mutually agreed-upon keys or certificate and method of encryption. The IKE process occurs in two phases: IKE Phase 1 and IKE Phase 2 . Each of these phases use keys and encryption algorithms that are defined using cryptographic profiles— IKE crypto profile and IPSec crypto profile—and the result of the IKE negotiation is a Security Association (SA). An SA is a set of mutually agreed-upon keys and algorithms that are used by both VPN peers to allow the flow of data across the VPN tunnel. The following illustration depicts the key exchange process for setting up the VPN tunnel:

IKE Phase 1

In this phase, the firewalls use the parameters defined in the IKE Gateway configuration and the IKE Crypto profile to authenticate each other and set up a secure control channel. IKE Phase supports the use of preshared keys or digital certificates (which use public key infrastructure, PKI) for mutual authentication of the VPN peers. Preshared keys are a simple solution for securing smaller networks because they do not require the support of a PKI infrastructure. Digital certificates can be more convenient for larger networks or implementations that require stronger authentication security.

When using certificates, make sure that the CA issuing the certificate is trusted by both gateway peers and that the maximum length of certificates in the certificate chain is 5 or less. With IKE fragmentation enabled, the firewall can reassemble IKE messages with up to 5 certificates in the certificate chain and successfully establish a VPN tunnel.

The IKE Crypto profile defines the following options that are used in the IKE SA negotiation:

• Diffie-Hellman (DH) group for generating symmetrical keys for IKE.
  The Diffie-Hellman algorithm uses the private key of one party and the public key of the other to create a shared secret, which is an encrypted key that both VPN tunnel peers share. The DH groups supported on the firewall are: Group 1—768 bits, Group 2—1024 bits (default), Group 5—1536 bits, Group 14—2048 bits, Group 19—256-bit elliptic curve group, and Group 20—384-bit elliptic curve group.
• Authentication algorithms—sha1, sha 256, sha 384, sha 512, or md5
• Encryption algorithms—3des, aes-128-cbc, aes-192-cbc, aes-256-cbc, or des

IKEv2

An IPSec VPN gateway uses IKEv1 or IKEv2 to negotiate the IKE security association (SA) and IPSec tunnel. IKEv2 is defined in RFC 5996 .

Unlike IKEv1, which uses Phase 1 SA and Phase 2 SA, IKEv2 uses a child SA for Encapsulating Security Payload (ESP) or Authentication Header (AH), which is set up with an IKE SA.

NAT traversal (NAT-T) must be enabled on both gateways if you have NAT occurring on a device that sits between the two gateways. A gateway can see only the public (globally routable) IP address of the NAT device.

IKEv2 provides the following benefits over IKEv1:

• Tunnel endpoints exchange fewer messages to establish a tunnel. IKEv2 uses four messages; IKEv1 uses either nine messages (in main mode) or six messages (in aggressive mode).
• Built-in NAT-T functionality improves compatibility between vendors.
• Built-in health check automatically re-establishes a tunnel if it goes down. The liveness check replaces the Dead Peer Detection used in IKEv1.
• Supports traffic selectors (one per exchange). The traffic selectors are used in IKE negotiations to control what traffic can access the tunnel.
• Supports Hash and URL certificate exchange to reduce fragmentation.
• Resiliency against DoS attacks with improved peer validation. An excessive number of half-open SAs can trigger cookie validation.

Before configuring IKEv2, you should be familiar with the following concepts:

• Liveness Check
• Cookie Activation Threshold and Strict Cookie Validation
• Traffic Selectors
• Hash and URL Certificate Exchange
• SA Key Lifetime and Re-Authentication Interval

After you Set Up an IKE Gateway , if you chose IKEv2, perform the following optional tasks related to IKEv2 as required by your environment:

Methods of Securing IPSec VPN Tunnels (IKE Phase 2)

IPSec VPN tunnels can be secured using manual keys or auto keys. In addition, IPSec configuration options include Diffie-Hellman Group for key agreement, and/or an encryption algorithm and a hash for message authentication.

• Manual Key—Manual key is typically used if the Palo Alto Networks firewall is establishing a VPN tunnel with a legacy device, or if you want to reduce the overhead of generating session keys. If using manual keys, the same key must be configured on both peers.
  Manual keys are not recommended for establishing a VPN tunnel because the session keys can be compromised when relaying the key information between the peers; if the keys are compromised, the data transfer is no longer secure.
• Auto Key— Auto Key allows you to automatically generate keys for setting up and maintaining the IPSec tunnel based on the algorithms defined in the IPSec Crypto profile.

IKEv2

An IPSec VPN gateway uses IKEv1 or IKEv2 to negotiate the IKE security association (SA) and IPSec tunnel. IKEv2 is defined in RFC 5996 .

Unlike IKEv1, which uses Phase 1 SA and Phase 2 SA, IKEv2 uses a child SA for Encapsulating Security Payload (ESP) or Authentication Header (AH), which is set up with an IKE SA.

NAT traversal (NAT-T) must be enabled on both gateways if you have NAT occurring on a device that sits between the two gateways. A gateway can see only the public (globally routable) IP address of the NAT device.

IKEv2 provides the following benefits over IKEv1:

• Tunnel endpoints exchange fewer messages to establish a tunnel. IKEv2 uses four messages; IKEv1 uses either nine messages (in main mode) or six messages (in aggressive mode).
• Built-in NAT-T functionality improves compatibility between vendors.
• Built-in health check automatically re-establishes a tunnel if it goes down. The liveness check replaces the Dead Peer Detection used in IKEv1.
• Supports traffic selectors (one per exchange). The traffic selectors are used in IKE negotiations to control what traffic can access the tunnel.
• Supports Hash and URL certificate exchange to reduce fragmentation.
• Resiliency against DoS attacks with improved peer validation. An excessive number of half-open SAs can trigger cookie validation.

Before configuring IKEv2, you should be familiar with the following concepts:

• Liveness Check
• Cookie Activation Threshold and Strict Cookie Validation
• Traffic Selectors
• Hash and URL Certificate Exchange
• SA Key Lifetime and Re-Authentication Interval

How to Configure IPSec VPN

by dtickoo on ‎03-12-2014 08:08 PM - edited on ‎08-12-2016 02:35 PM by editeur(182,054 Views)

This document describes the steps to configure IPSec VPN and assumes the Palo Alto Networks firewall has at least two interfaces operating in Layer 3 mode.

Steps

1. Go to Network >Interface > Tunnel,  click Add to create a new tunnel interface and assign the following parameters: 
   Name: tunnel.1
   Virtual router: (select the existing virtual router)
   Security Zone: (select the layer 3 internal zone from which the traffic will originate)
   
   Note: If the tunnel interface is in a zone different from the zone where the traffic will originate or depart, then a policy will need to be created to allow the traffic to flow from the source zone to the zone containing the tunnel interface.
   
2. Go to Network > Network Profiles > IKE Crypto , click Add and define the IKE Crypto profile (IKEv1 Phase-1) parameters. Name does not matter, can be whatever you like. 
   These parameters should match on the remote firewall for the IKE Phase-1 negotiation to be successful.
   
   
3. Go to Network > Network Profiles > IKE Gateway to configure the IKE Phase-1 Gateway. There are options for the Version where you can select IKEv1 only mode, IKEv2 only mode or IKEv2 preferred mode.
   
   Select the IKE version that the gateway supports and must agree to use with the peer gateway. IKEv2 preferred mode causes the gateway to negotiate for IKEv2, and if the peer also supports IKEv2, that is what they will use. Otherwise, the gateway falls back to IKEv1.
   
   Note: The tunnel configured above will terminate in the Trust zone for traffic traversing the tunnel, although if more granular control is desired for the policy configuration in the tunnel, use a VPN or other zone. Also, note that the gateway configuration below will be configured for the Untrust interface, not to be confused with the tunnel terminating on a trusted interface.
   
   
4. Under Network > Network Profiles > IPSec Crypto , click Add to create a new Profile, define the IPSec Crypto profile to specify protocols and algorithms for identification, authentication, and encryption in VPN tunnels based on IPSec SA negotiation (IKEv1 Phase-2). These parameters should match on the remote firewall for the IKE Phase-2 negotiation to be successful.
   
   
5. Under Network > IPSec Tunnels, click Add to create a new IPSec Tunnel. In the General window use the Tunnel Interface, the IKE Gateway and IPSec Crypto Profile from above to set up the parameters to establish IPSec VPN tunnels between firewalls. 
   
   Note:  If the other side of the tunnel is a third-party VPN device configured as a route-based VPN, then enter the local proxy ID and remote proxy ID to match, these will typically be the local and remote LAN subnets.
   
   When configuring an IPSec Tunnel Proxy-ID configuration to identify local and remote IP networks for traffic that is NATed, the Proxy-ID configuration for the IPSec Tunnel must be configured with the Post-NAT IP network information, because the Proxy-ID information defines the networks that will be allowed through the tunnel on both sides for the IPSec configuration.                            
6. Under Network > Virtual Routers, click on your Virtual router profile, then click Static Routes, add a new route for the network that is behind the other VPN endpoint. Be sure to use the proper Tunnel Interface. Click OK when done.
   
7. Commit the configuration.

Note: The Palo Alto Networks supports only tunnel mode for IPSec VPN. The transport mode is not supported for IPSec VPN.