Network Security
IPSec VPN Tunnels
Table of Contents
Expand All
|
Collapse All
Network Security Docs
-
- Security Policy
-
- Security Profile Groups
- Security Profile: AI Security
- Security Profile: WildFire® Analysis
- Security Profile: Antivirus
- Security Profile: Vulnerability Protection
- Security Profile: Anti-Spyware
- Security Profile: DNS Security
- Security Profile: DoS Protection Profile
- Security Profile: File Blocking
- Security Profile: URL Filtering
- Security Profile: Data Filtering
- Security Profile: Zone Protection
-
- Policy Object: Address Groups
- Policy Object: Regions
- Policy Object: Traffic Objects
- Policy Object: Applications
- Policy Object: Application Groups
- Policy Object: Application Filter
- Policy Object: Services
- Policy Object: Auto-Tag Actions
- Policy Object: Devices
-
- Uses for External Dynamic Lists in Policy
- Formatting Guidelines for an External Dynamic List
- Built-in External Dynamic Lists
- Configure Your Environment to Access an External Dynamic List
- Configure your Environment to Access an External Dynamic List from the EDL Hosting Service
- Retrieve an External Dynamic List from the Web Server
- View External Dynamic List Entries
- Enforce Policy on an External Dynamic List
- Find External Dynamic Lists That Failed Authentication
- Disable Authentication for an External Dynamic List
- Policy Object: HIP Objects
- Policy Object: Schedules
- Policy Object: Quarantine Device Lists
- Policy Object: Dynamic User Groups
- Policy Object: Custom Objects
- Policy Object: Log Forwarding
- Policy Object: Authentication
- Policy Object: Decryption Profile
- Policy Object: Packet Broker Profile
-
-
-
- The Quantum Computing Threat
- How RFC 8784 Resists Quantum Computing Threats
- How RFC 9242 and RFC 9370 Resist Quantum Computing Threats
- Support for Post-Quantum Features
- Post-Quantum Migration Planning and Preparation
- Best Practices for Resisting Post-Quantum Attacks
- Learn More About Post-Quantum Security
-
-
-
- Investigate Reasons for Decryption Failure
- Identify Weak Protocols and Cipher Suites
- Troubleshoot Version Errors
- Troubleshoot Unsupported Cipher Suites
- Identify Untrusted CA Certificates
- Repair Incomplete Certificate Chains
- Troubleshoot Pinned Certificates
- Troubleshoot Expired Certificates
- Troubleshoot Revoked Certificates
IPSec VPN Tunnels
Explains the steps involved in creating an IPSec VPN tunnel.
Where Can I Use This? | What Do I Need? |
---|---|
| No license required |
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 policygets implemented depends on the device platform. The access lists interpret IPSec policy rule to determine which traffic will be protected by IPSec.The IPSec tunnel comes up only when there is an interesting traffic destined to the tunnel. To manually initiate the tunnel, check the tunnel status and clear tunnels by referring to troubleshooting site-to-site VPN issues using the CLI.
- 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.