Site-to-Site VPN Overview

IPSec VPN Basics

Virtual private network (VPN) helps you to establish a secure network connection when using public networks. VPNs encrypt your internet traffic and hide your identity in the internet. This makes the location invisible and makes it more difficult for third parties to track your activities in the internet and steal data. A VPN connection is also secure against external attacks from bad actors in the internet as only you can access the data in the encrypted VPN tunnel.

VPNs create tunnels that allow users and systems to connect securely over a public network, as if they were connecting over a local area network (LAN). To set up a VPN tunnel, you need a pair of devices that can authenticate each other and encrypt the flow of information between them. The devices can be a pair of Palo Alto Networks firewalls, or a Palo Alto Networks firewall along with a VPN-capable device from another vendor.
 
There are many different types of VPNs, and one among them is the most common site-to-site VPN.
A site-to-site VPN is a private network that hides the private intranets and allow users of these secure networks to access each other’s resources. Many organizations use site-to-site VPN for their businesses needs to connect two or more locations. For example, a site-to-site VPN would allow a company’s headquarters at one geographical location to connect with a smaller branch at another geographical location. Site-to-site VPNs enhance the security and efficiency of organizational networks
Site-to-Site VPN Overview
A VPN connection that allows you to connect two local area networks (LANs) is called a site-to-site VPN. You can configure route-based VPNs to connect Palo Alto Networks firewalls located at two sites or to connect a Palo Alto Networks firewall with a third-party security device at another location. The firewall can also interoperate with third-party policy-based VPN devices; the Palo Alto Networks firewall supports route-based VPN.

The Palo Alto Networks firewall sets up a route-based VPN, where the firewall makes a routing decision based on the destination IP address. If traffic is routed to a specific destination through a VPN tunnel, then it’s handled as VPN traffic.
The Internet Protocol 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 pre-shared 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.

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 the 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 a policy rule 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’ll 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 doesn’t require an IP address. An IP address is only required if you want to enable tunnel monitoring or if you’re 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’re 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 received in the packet 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 toward the IPSec VPN tunnel capacity of the firewall, and the tunnel capacity varies by the firewall model.

 

 

 

IPSec VPN
IPSec VPN provides a private and secure IP communication over a public network infrastructure (for example, the internet). With this technology, different sites or users in different geographical areas can communicate over a network and thus safely use their resources. IPSec provides data confidentiality and integrity, including authentication, integrity check, and encryption.
IPSec VPN is one of the two common VPN protocols, or sets of standards used to establish a VPN connection. At the IP layer, IPSec provides secure, remote access to an entire network (rather than just a single device).
 
IPSec VPNs come in two types:
tunnel mode
transport mode
 
Differences between IPSec and VPN
IP SECURITY (IPSec)
Provides IP hosts with methods for encrypting and authenticating data sent on the IP network.
By using IPSec, entities that have IP addresses can create a secure tunnel.
 
 
VPN
Uses encryption to obscure all data sent between the VPN client and server.
 
Many types of VPN protocols offer varying levels of security and other features. The most commonly used tunneling protocols in the VPN industry are Point-to-Point Tunnel Protocol (PPTP), Layer Two Tunneling Protocol (L2TP), IPSec, Secure Socket Tunneling Protocol (SSTP), and OpenVPN.
 
 
IPSec Tunnel Modes
IPSec standards define two distinct modes of IPSec operations: tunnel and transport modes. The key difference between the transport and tunnel mode is where the policy rule is applied. Tunnel mode will add an ESP/AH header to the inner IP packet, and encapsulate it in a new outer IP packet. Hence, the entire inner IP packet including the IP header will be encrypted and authenticated. But, transport mode will add an ESP/AH header to the inner packet’s payload, and move the inner packet’s IP header out. This encrypts and authenticates the inner IP packet’s payload only.
 
 Notes 
  • AH does not work with NAT since the integrity is calculated by using some fields of the IP header. The reason is that AH includes the outer IP header in the hash-based message authentication code (HMAC) calculation that causes NAT to break it.
  • IPSec transport mode is used for end-to-end communications, for example between a client and a server, or between a workstation and a gateway if the gateway is being treated as a host. A good example would be an encrypted Telnet or Remote Desktop session from a workstation to a server.

IPSec VPN Types

Site-to-Site (or Gateway-to-Gateway) VPN and Remote access (client-to-site) VPN are two distinct types of VPNs. Where client-to-site VPN represents a single user connection, site-to-site VPNs deal with remote connections between entire networks.
In a site-to-site VPN, the IPSec security method is used to create an encrypted tunnel from one customer network to a remote site of the customer. Palo Alto Networks VPN tunnels can also be used between partners.
 
 Notes 
Site-to-Site VPNs do not allow for multiple endpoints.
In remote access VPN, individual endpoints are connected to a private network to access the services and resources of that private network remotely. Remote Access VPN is most suitable for the business and home users as it allows multiple endpoints.
 

IPSec VPN Tunnels

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.

    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.
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
 
VPN Deployments
  • Site-to-Site VPN— A simple VPN that connects a central site and a remote site, or a hub and spoke VPN that connects a central site with multiple remote sites. The firewall uses the Internet Protocol Security (IPSec) set of protocols to set up a secure tunnel for the traffic between the two sites. See Site-to-Site VPN Overview.
  • Remote User-to-Site VPN—A solution that uses the GlobalProtect agent to allow a remote user to establish a secure connection through the firewall. This solution uses SSL and IPSec to establish a secure connection between the user and the site. Refer to the GlobalProtect Administrator’s Guide.
  • Large Scale VPN— The Palo Alto Networks GlobalProtect Large Scale VPN (LSVPN) provides a simplified mechanism to roll out a scalable hub and spoke VPN with up to 1,024 satellite offices. The solution requires Palo Alto Networks firewalls to be deployed at the hub and at every spoke. It uses certificates for device authentication, SSL for securing communication between all components, and IPSec to secure data. See Large Scale VPN (LSVPN).
  • Remote Site VPN—Remote sites use IPSec tunnels to secure users and devices in remote network locations. In addition, mobile users secured with GlobalProtect and users at remote sites access private applications using either IPSec tunnels (for service connections or ZTNA Connectors) or GRE tunnels (for Colo-Connect connections).

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.
 
  • IKE Phase 1—Initially, a VPN peer will exchange the proposals for security services, such as, encryption algorithms, authentication algorithm, hash function. Both the VPN peers will form a security association which is a collection of parameters that the two devices use. When both the VPN peers of the tunnel agree to accept a set of security parameters, the IKE phase 1 is completed.
    There are two modes in IKE phase 1, main mode and aggressive mode.
  • IKE Phase 2—Once the IKE phase 1 is completed successfully, IKE phase 2 is initiated. The security associations and services between the VPN peers are negotiated in IKE phase 2. The VPN peers of the tunnel will negotiate which protocol (Authentication Header or Encapsulation Security Protocol) and which algorithm to use.
    IKE Phase 2 operates only in quick mode.

 

Each of these phases uses 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 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 pre-shared keys or certificates to authenticate each other mutually.
(In IKEv1) The peers must also negotiate the mode—main or aggressive—for setting up the VPN tunnel and the SA lifetime in IKE Phase 1. The 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 a faster but a less secure option for setting up the VPN tunnel.
 
(In IKEv2) IKEv2 negotiation process between the IKE gateways is much more efficient and simplified compared to IKEv1 negotiation. IKEv2 performs three types of exchanges: initial exchanges, CREATE_CHILD_SA exchange, and INFORMATIONAL exchange. IKEv2 uses the following two exchanges during the initial exchange process each with two messages.
  • IKE_SA_INIT exchange—Negotiates IKE SA parameters and exchanges keys.
  • IKE_AUTH exchange—Authenticates the identity of the peer and establishes IPSec SAs.
After the four-message initial exchanges, IKEv2 sets up one IKE SA and one pair of IPSec SAs. To set up one IKE SA and one pair of IPSec SAs, IKEv1 goes through two phases that use a minimum of six messages.
 
To set up one more pair of IPSec SAs within the IKE SA, IKEv2 goes on to perform an additional two-message exchange—the CREATE_CHILD_SA exchange. One CREATE_CHILD_SA exchange creates one pair of IPSec SAs. IKEv2 also uses the CREATE_CHILD_SA exchange to re-key IKE SAs and Child SAs.
IKEv2 uses the INFORMATIONAL exchange for errors and notifications.
 
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 pre-shared keys or digital certificates (which use public key infrastructure, PKI) for mutual authentication of the VPN peers. Pre-shared keys are a simple solution for securing smaller networks because they don’t 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 five 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:
IKE Phase 2
After the tunnel is secured and authenticated, in Phase 2 the channel is further secured for the transfer of data between the networks. IKE Phase 2 uses the keys that were established in Phase 1 of the process and the IPSec Crypto profile, which defines the IPSec protocols and keys used for the SA in IKE Phase 2.
The IPSec uses the following protocols to enable secure communication:
  • Encapsulating Security Payload (ESP)—Allows you to encrypt the entire IP packet, and authenticate the source and verify the integrity of the data. While ESP requires that you encrypt and authenticate the packet, you can choose to only encrypt or only authenticate by setting the encryption option to Null; using encryption without authentication is discouraged.
  • Authentication Header (AH)—Authenticates the source of the packet and verifies data integrity. AH doesn’t encrypt the data payload and is unsuited for deployments where data privacy is important. AH is commonly used when the main concern is to verify the legitimacy of the peer, and data privacy isn’t required.

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 a Diffie-Hellman Group for key agreement, 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 aren’t 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 generate keys automatically 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. Palo Alto Networks IKEv2 implementation is based on RFC 7295.
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 reestablishes 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.
Familiarize yourself with the IKEv2 basic concepts before configuring IKEv2.

IPSec VPN (Site-to-Site)

Plan Your IPSec VPN Tunnel Setup

 Before you set up an IPSec tunnel, it’s important that you decide the following factors and plan your IPSec tunnel set up successfully.
  1. Decide on Type of VPN: Site-to-Site or Remote Access
    The site-to-site VPN allows using the IPSec security method to create an encrypted tunnel from one customer network to a remote site of the customer. However, the remote access VPN allows individual users to connect to a private network to access its services and resources.
  2. Select a Security Method for your VPN
    In site-to-site VPN, the IPSec security method is used to create an encrypted tunnel from one customer network to a remote site of the customer.
    In remote access VPN, individual users are connected to the private network.
  3. Decide on your VPN Client
    The site-to-site VPN does not need setup on each client. Remote access VPN may or may not need setup on each client.
  4. Decide on your VPN Tunnel Setup
    The site-to-site VPN does not require every user to initiate the VPN tunnel setup. Remote access VPN requires every remote access user to initiate the VPN tunnel setup.
  5. Decide on your Security Technology
    While site-to-site VPN supports IPSec technology, Remote access VPN supports SSL as well as IPSec technology.
  6. Decide if you wish Single or Multiple Users on your VPN
    In site-to-site VPN, multiple users are not allowed; In remote access VPN, however, multiple users are allowed.
To set up site-to-site VPN:
  • Make sure that your Ethernet interfaces, virtual routers, and zones are configured properly. For more information, see Configure Interfaces and Zones.
  • Create your tunnel interfaces. Ideally, put the tunnel interfaces in a separate zone, so that tunneled traffic can use different policy rules.
  • Set up static routes or assign routing protocols to redirect traffic to the VPN tunnels. To support dynamic routing (OSPF, BGP, RIP are supported), you must assign an IP address to the tunnel interface.
  • Define IKE gateways for establishing communication between the peers across each end of the VPN tunnel; also define the cryptographic profile that specifies the protocols and algorithms for identification, authentication, and encryption to be used for setting up VPN tunnels in IKEv1 Phase 1. See Set Up an IKE Gateway and Define IKE Crypto Profiles.
  • Configure the parameters that are needed to establish the IPSec connection for transfer of data across the VPN tunnel; See Set Up an IPSec Tunnel. For IKEv1 Phase-2, see Define IPSec Crypto Profiles.
  • (Optional) Specify how the firewall will monitor the IPSec tunnels. See Monitor Your IPSec VPN Tunnel .
  • Define Security policies to filter and inspect the traffic.

Notes

If there’s a deny rule at the end of the security rulebase, intrazone traffic is blocked unless otherwise allowed. Rules to allow IKE and IPSec applications must be explicitly included above the deny rule.

 

Notes

If your VPN traffic is passing through (not originating or terminating on) a PA-7000 Series or PA-5200 Series firewall, configure a bidirectional Security policy rule to allow the ESP or AH traffic in both directions.

 

When these tasks are complete, the tunnel is ready for use. Traffic destined for the zones/addresses defined in a policy rule is automatically routed properly based on the destination route in the routing table, and handled as VPN traffic. For a few examples on site-to-site VPN, see Site-to-Site VPN .

Configuration Steps

  • Zone
  • Interface
  • Routing
  • Policy
  • IKE-Cryptography
  • IPsec-Crypto
  • IKE-Gateway
  • IPsec-Tunnel

Firewall No – 1

Step-1  Interfaces Configure

Step- 2 Interfaces Configure

  • Same Way Configure Outside Wan Intefaces
  • Outside Interface Wan NoNeed MGMT Profile Add Only Lanside
  •  Next Create Tunnel interfaces For VPN 
Configure Tunnel Interface 

Step- 3 Static Routing

Step- 4 Security Policy

Same Configuration Firewall No – 2

Site To Site VPN Configuration Firewall No 1

 

 Step -1 IKE-Cryptography 

 

 Step -2 IPsec-Crypto 

 

 Step -3 IKE-Gateway  

Same Method Follow Configuration Firewall No – 2 Same Configuration Main Mode, Des,Md5,Pre-shared Key 123 Changes Only  Peer address – Firewall No 1 Wan Public IP And Peer Identification Address Firewall No -1 Public IP 

Ok And Commit Save Config File

Site A Firewall No -1 Route Configuartion  

Step- 4 IPsec-Tunnel

After Ok Commit.IPsecvpn Ready To Use