IPSec VPN Tunnels
Explains the steps involved in creating an IPSec VPN tunnel.
| Where Can I Use This? | What Do I Need? |
|---|
The process of creating an IPSec tunnel first starts to establish a preparatory
tunnel that is encrypted and secured, and then from within that secure tunnel negotiate
the encryption keys and parameters for the IPSec tunnel.
The VPN negotiations take place in two defined phases: phase one and phase two.
The main purpose of phase one is to set up a secure encrypted channel through which the
two peers can negotiate. When phase one finishes successfully, the peers quickly move on
to phase two for negotiations.
If the tunnel interface is in a zone different from the zone where the traffic
will originate or depart, then define a policy rule to allow the traffic to flow from
the source zone to the zone containing the tunnel interface. Configuring the IP address
on the tunnel interface is optional. You would need this IP address if you intend to run
dynamic routing protocols over the tunnel interface.
While IPSec incorporates many component technologies and offers multiple
encryption options, the basic operation includes the following five main procedures:
- Interesting Traffic or On-Demand—The IPSec tunnel policy rule and the route
table determines which type of traffic is considered to be “interesting” or is
captured “on-demand” and, therefore, protected. How the PAN-OS VPN security policy gets implemented depends
on the device platform. The access lists interpret IPSec policy rule to determine
which traffic will be protected by IPSec.
- IKE Phase 1—IKE is a key management protocol standard used with IPSec. IKE
authenticates each peer in an IPSec session, automatically negotiates two levels of
SAs, and handles the exchange of session keys accomplished in two phases: phase 1
and phase 2.
The main purpose of IKE phase 1 is to authenticate the
IPSec peers and to set up a secure channel between the peers.
- IKE Phase 2—IKE negotiates the stricter IPSec Security Associations (SA)
parameters for the CHILD_SA between the peers.
- IPSec Data Transfer—Qualifying data is transferred between IPSec peers.
Information is exchanged through IPSec sessions based on the method for defining
interesting traffic. Packets are encrypted and decrypted at the IPSec peers using
any encryption specified in the IPSec SA.
- IPSec Tunnel Session Termination—The IPSec session can be terminated because
the traffic ended and the IPSec SA was deleted or the SA can timeout based on either
SA lifetime setting. The SA timeout can be after a specified number of seconds or a
specified number of bytes passed through the connection.
The keys are
discarded when SAs terminate, requiring IKE to perform a new phase two and,
possibly, a new phase one negotiation. New SAs can be established before the
current ones expire, maintaining uninterrupted data flows.
The IPSec session terminates through deletion or by timing
out.
IPSec Tunnel Policy Rule Implementation on Palo Alto Networks Next-Generation
Firewalls
Encapsulating a packet for secure transportation on the network is accomplished by
means of the IPsec protocol. For example, in the case of a site-to-site VPN, a
source host in a network transmits an IP packet. When that packet reaches the edge
of the network, it makes contact with a VPN gateway. The VPN gateway that
corresponds with that network encrypts the private IP packet and relays it over an
ESP tunnel to a peer VPN gateway at the edge of the next network, the gateway of
which decrypts the packet and delivers it to the destination host.
The policy-based VPNs have specific security rules, policy rules, or access-lists
(such as source addresses, destination addresses, and ports) that are configured for
permitting the interesting traffic through IPSec tunnels. These rules are referenced
during the quick mode (or IPSec phase 2), and are exchanged in the first or the
second messages as the proxy IDs. If the Palo Alto Networks firewall is not
configured with the proxy ID settings, then the firewall sets the proxy ID with the
default values (source ip = 0.0.0.0/0, destination ip = 0.0.0.0/0, application:any)
and exchanges it with the peer during the first or the second message of the quick
mode.
