Site-to-Site VPN tunnels. You need to connect two separate office networks over the internet as if they were one single, secure network. For the PCNSE exam, you must understand how to build this secure connection using IPsec and, just as importantly, how to fix it when it breaks.
Jump to a section
A simple way to picture Site-to-Site VPN Configuration and Troubleshooting
The interoffice mail clerk is the person responsible for making sure two separate company branches can send each other sealed packages securely.
The clerk at branch A and the clerk at branch B first agree on a specific protocol. They decide every package must be placed inside a tamper-proof, fireproof steel box and that the box must be locked with a padlock from a specific, pre-approved set. They also agree that before sending, they will shout a secret code word across the room to confirm the other clerk is ready. This agreement is the IPsec security policy.
Next, the clerk at branch A turns the package into a sealed parcel and puts it into the steel box. They lock it with padlock number one, the encryption padlock. The box is now unreadable to anyone who intercepts it. They then wrap the whole steel box in a second cardboard box and address it to the other branch. This outer wrapping is the IP header that routes the encrypted package across the public internet.
When the box arrives at branch B, the local clerk uses their copy of padlock one to open the steel box, verifying it has not been tampered with using a special seal. They then take out the original package and deliver it to the correct local department. If the seal is broken or the padlock does not fit, the clerk throws the box away and sends a message back to branch A, saying 'The package did not arrive securely. Please resend.' This is the troubleshooting phase.
If a new employee joins branch B and does not know the agreed protocol, they cannot open the steel box, and the entire connection fails until the security settings are re-synchronised. This maps directly to a misconfigured VPN tunnel where the encryption algorithm does not match on both sides.
A site-to-site VPN is a way to connect two separate physical networks — like a head office in London and a branch office in Manchester — over the public internet, making them behave like a single private network. The internet is a dangerous place. Without a VPN, any data sent between the two offices would travel in plain text, readable by any router or internet service provider along the path. A site-to-site VPN wraps that data in a secure, encrypted tunnel so that even if someone intercepts the transmission, they cannot read it.
The technology that makes this possible is called IPsec, which stands for Internet Protocol Security. IPsec is a suite of protocols that work together to provide authentication (proving who you are), encryption (scrambling the data so it is unreadable), and integrity (making sure the data has not been tampered with during transit).
The process of establishing an IPsec tunnel happens in two main phases: Phase 1 and Phase 2. Phase 1 is sometimes called IKE Phase 1, where IKE stands for Internet Key Exchange. This phase is the negotiation. The two VPN gateways (the firewalls at each site) introduce themselves to each other. They agree on a set of security parameters called a proposal. This proposal includes things like:
The encryption algorithm (for example, AES-256, which is a strong encryption standard)
The authentication algorithm (for example, SHA-256, which verifies data integrity)
The Diffie-Hellman group (a method for securely exchanging cryptographic keys over an insecure channel)
The result of Phase 1 is a secure, but unauthenticated, channel called an ISAKMP SA (Internet Security Association and Key Management Protocol Security Association). Think of this as a single secure hallway between the two buildings, but the hallway itself does not know who is allowed to walk through it yet.
Phase 2, also known as IKE Phase 2 or Quick Mode, builds on the hallway created in Phase 1. In Phase 2, the two firewalls negotiate the actual parameters for the data traffic. They agree on which specific networks can talk to each other — for example, the 10.1.1.0/24 network at the head office is allowed to talk to the 10.2.2.0/24 network at the branch office. Phase 2 creates the actual tunnel, called an IPsec SA. This is the twin of specific, limited-use tunnels inside the hallway, one for each direction of traffic.
Once both phases are complete, data starts flowing through the tunnel. The packet at the head office is encrypted, wrapped in a new IP header, and sent across the internet. The branch office firewall receives it, removes the outer header, decrypts the inner packet, and forwards it to the correct internal device.
Troubleshooting a site-to-site VPN on a Palo Alto Networks firewall usually starts with checking the IKE and IPsec parameters. The most common configuration errors are mismatched encryption algorithms, mismatched pre-shared keys (a shared secret password used to authenticate the connection), and incorrect proxy IDs (the specific networks being tunneled). If Phase 1 fails, you will see 'IKE phase 1 negotiation failed' in the system logs. If Phase 1 succeeds but Phase 2 fails, the peers can authenticate but cannot agree on which networks to tunnel. Palo Alto Networks firewalls provide a built-in tool called 'tunnel monitor' that can automatically detect when a tunnel has gone down and attempt to re-establish it.
A site-to-site VPN replaces the need for expensive leased lines or private MPLS (Multiprotocol Label Switching) circuits. It uses the existing public internet, which is much cheaper, while providing a similar level of security through encryption. However, performance depends on your internet connection speed and the processing power of the firewalls at each end, because encryption and decryption take CPU cycles.
Define the IKE Gateway
Create an IKE Gateway object on the Palo Alto Networks firewall. This defines the remote peer’s public IP address, the pre-shared key, and the IKE version (v1 or v2). It also specifies the authentication and encryption algorithms for Phase 1. This step is the initial handshake setup. Without a correctly defined IKE gateway, the firewall does not know whom it should talk to or how to authenticate.
Configure the IPsec Crypto Profile
Create an IPsec Crypto profile that defines the Phase 2 parameters: the encryption algorithm (e.g., AES-256), the authentication algorithm (e.g., SHA-256), the Diffie-Hellman group, and the IPsec SA lifetime. This profile tells the firewall how to encrypt and authenticate the actual data packets that will traverse the tunnel.
Create the IPsec Tunnel Object
Combine the IKE gateway and the IPsec crypto profile into an IPsec tunnel object. In this step, you also configure the tunnel interface that will be used as the logical endpoint for the tunnel. You assign the tunnel to a virtual router and define the proxy IDs (the source and destination subnets that the tunnel will carry). This is where you specify exactly which networks are allowed to communicate through the tunnel.
Add Security Policies
Create security policies that allow traffic from the source zone (e.g., trust zone) to the tunnel zone or destination zone. The policy must permit traffic based on source IP, destination IP, and services. Without this step, even a perfectly configured tunnel will block all traffic because the firewall’s default behaviour is to deny all.
Verify and Troubleshoot the Tunnel
Check the tunnel status from the dashboard or using CLI commands. Use 'show vpn ike-sa' to verify Phase 1 is up, and 'show vpn ipsec-sa' to verify Phase 2. If the tunnel is down, examine the system logs, look for 'IKE' or 'IPsec' error messages, and use the 'Test VPN Tunnel' feature. This step is critical to confirm the configuration works and to diagnose any issues.
Imagine you are the new IT administrator for a company called BrightPath Consulting. They have a main office in London with 200 employees and a new sales office in Manchester with 20 employees. The Manchester office needs access to the file server and the customer relationship management (CRM) database that are hosted in London. You cannot run a physical cable between the two cities, so you must use a site-to-site VPN over the internet.
First, you would log in to the Palo Alto Networks firewall at the London office. You would navigate to the 'Network' tab, create a new 'IPsec Tunnel' profile. You would give it a name, for example 'London-to-Manchester'. Next, you would configure the IKE gateway. This is the object that represents the other side. You enter the Manchester firewall's public IP address — something like 203.0.113.10. You then set the pre-shared key to a strong, random string, for example '9f7kD!2sP@m'. You would also choose the IKE version, typically IKEv2 for modern deployments, and select the encryption and authentication algorithms (AES-256, SHA-256).
Then you would configure the IPsec crypto profile. This defines the Phase 2 parameters. You would set the same encryption and authentication algorithms as the remote end. You would also define the proxy IDs. In the Palo Alto Networks firewall, the proxy IDs are crucial. They define exactly which source and destination subnets are allowed to use the tunnel. For the London side, you set the source subnet to 10.1.1.0/24 (London) and the destination subnet to 10.2.2.0/24 (Manchester). The local proxy ID must match the remote side's remote proxy ID, and vice versa. This is the most common place for configuration mistakes.
After applying the configuration, you would check the tunnel status. On the dashboard, you look at the 'IPSec Tunnels' widget. It should show 'active' or 'green'. If it shows 'down' or 'red', you would go to the 'Monitor' tab, look at the system logs, and filter for 'ike' or 'ipsec'. A log entry like 'phase 2 negotiation failed, no matching proposal' tells you exactly where to look: the encryption algorithms or proxy IDs do not match between the two firewalls.
You might also use the 'troubleshooting' tab in the GUI. Palo Alto Networks firewalls have a 'Test VPN Tunnel' feature. You select the tunnel and click 'Test'. The firewall then sends a packet through the tunnel and waits for a response. If the test fails, you get a specific error message. If the tunnel is properly configured but the remote site is offline, the tunnel will remain down until the remote firewall comes back online. In that case, you might configure tunnel monitor to automatically ping the remote side and re-establish the tunnel if it fails.
The real-world troubleshooting steps you would follow include:
Verify that both firewalls have reachability to each other's public IP addresses using a ping from the CLI (command line interface).
Confirm that the pre-shared key is identical on both sides. A single character difference causes the entire tunnel to fail.
Check the IKE and IPsec crypto profiles for identical algorithm settings. If one uses AES-128 and the other uses AES-256, they will not agree.
Validate that the proxy IDs are symmetrical. The London 'local' must match the Manchester 'remote' exactly.
Look at the 'ipsec sa' and 'ike sa' counters in the CLI to see if any packets have passed through the tunnel. If the count is zero, the tunnel is established but no traffic is using it, which points to a routing or policy issue.
The PCNSE exam will test your ability to configure and troubleshoot site-to-site VPNs on Palo Alto Networks firewalls. Expect the questions to be scenario-based. They will describe a situation where a tunnel is not working and ask you to identify the cause or the correct configuration step.
The exam loves to test the relationship between IKE Phase 1 and Phase 2. A common question will give you a log snippet showing 'IKE phase 1 negotiation failed' and ask you what is wrong. The correct answer is almost always something about mismatched IKE parameters: the pre-shared key is wrong, or the IKE version does not match (e.g., one side is set to IKEv1 and the other to IKEv2), or the encryption algorithm in the IKE gateway profile does not align.
Another favourite trap is proxy IDs. The exam will present a scenario where Phase 1 succeeds but Phase 2 fails. The answer will point to mismatched proxy IDs, or the absence of a proxy ID on one side. They might show a configuration where the local proxy ID is 0.0.0.0/0, which means 'any', but the remote side has a specific subnet defined. The correct answer is that both sides must explicitly define the same proxy IDs, unless one is set to '0.0.0.0/0', which some beginners think is a catch-all but actually causes a negotiation failure because the remote side expects an exact match.
Specific concepts you must memorise:
The difference between IKEv1 and IKEv2. IKEv2 is simpler, more secure, and supports faster reconnection. The exam will ask which protocol to use for a modern VPN. The answer is IKEv2.
The default settings on a Palo Alto Networks firewall for IKE and IPsec profiles. For example, the default IPsec profile uses 'esp' (Encapsulating Security Payload) with '3des' and 'sha-1'. You must know that '3des' is outdated and 'sha-1' is deprecated; the exam will test if you know to change these to 'aes-256' and 'sha-256' for a secure configuration.
The function of a 'tunnel interface' vs a 'loopback interface'. A tunnel interface is the logical interface that traffic flows through for the VPN. It must be added to a security policy to allow traffic. A loopback interface is a virtual interface on the firewall itself, often used for management. Beginners confuse them; the exam will test the difference.
'AS number' for BGP over VPN. Sometimes the exam combines IPsec with dynamic routing. They will ask what additional configuration is needed if you want to use BGP (Border Gateway Protocol) across the VPN. The answer is that you must enable BGP on the tunnel interface and configure an autonomous system number.
The 'Advanced' tab in the IPsec tunnel configuration. The exam will ask where you configure 'Enable Replay Protection' or 'Enable Tunnel Monitor'. These are specifically in the IPsec tunnel's advanced settings, not in the IKE gateway profile.
Traps to watch out for:
A question that says 'The VPN is established, but no traffic passes.' The answer is never 'the IKE parameters are wrong.' It is almost always 'the security policy does not allow traffic through the tunnel interface' or 'the proxy IDs are incorrect for the specific traffic.'
A question with a log showing 'invalid key ID' during IKE negotiation. The answer is the pre-shared key does not match.
A question that mentions 're-keying' failing. The answer is that the IPsec SA lifetime is set shorter than the IKE SA lifetime, causing the tunnel to drop during renegotiation.
A question with 'multi-vendor' VPN. The exam loves to set up a scenario where one side is a Palo Alto firewall and the other is a Cisco or generic router. They will test whether you know that the Palo Alto firewall requires explicit proxy IDs, whereas some other vendors do not. The correct approach is to define them explicitly on the Palo Alto side to ensure compatibility.
A site-to-site VPN uses IPsec to encrypt and authenticate all data between two separate physical networks over the public internet.
IPsec tunnel establishment consists of two phases: IKE Phase 1 creates a secure channel, and IKE Phase 2 creates the actual data tunnel.
The most common cause of a failed tunnel is mismatched IKE or IPsec parameters, including encryption algorithms, pre-shared keys, and Diffie-Hellman groups.
Proxy IDs must be defined symmetrically on both sides; the local proxy ID on one firewall must exactly match the remote proxy ID on the other.
Even with a correctly configured tunnel, traffic will not flow unless a security policy permits it and routing directs traffic to the tunnel interface.
Palo Alto Networks firewalls provide built-in troubleshooting tools, including system logs and the 'Test VPN Tunnel' function, instead of requiring third-party tools.
IKEv2 is preferred over IKEv1 because it offers faster reconnection, fewer round trips, and built-in support for NAT traversal.
Tunnel monitor is a feature that actively pings the remote peer and can automatically re-establish a failed tunnel.
These come up on the exam all the time. Here's how to tell them apart.
IKEv1
Requires more round trips (9 packets) to establish a tunnel.
Uses separate Main Mode and Aggressive Mode; Main Mode is more secure.
Less resilient to network changes; tunnel takes longer to recover after a failure.
IKEv2
Requires fewer round trips (4-6 packets) for faster tunnel establishment.
Has built-in support for NAT traversal and is more secure by default.
Supports faster re-keying and quicker recovery from connectivity loss.
IKE Gateway
Manages the Phase 1 negotiation (authentication and secure channel).
Contains the pre-shared key, IKE version, and IKE crypto profile settings.
Produces an IKE SA, which is temporary and used to protect Phase 2 negotiations.
IPsec Tunnel
Manages the Phase 2 negotiation (actual data tunnel).
Contains the IPsec crypto profile, proxy IDs, and tunnel interface.
Produces an IPsec SA, which encrypts and authenticates actual data packets.
Security Policy (Allow Rule)
Controls whether traffic is permitted through the firewall at all.
Specifies source zone, destination zone, source IP, destination IP, and service.
Exists independently of the VPN; you can have policies that do not involve VPN.
IPsec Crypto Profile
Defines the encryption and authentication algorithms used for the VPN data.
Specifies the Diffie-Hellman group and SA lifetime for the IPsec tunnel.
Only applies when an IPsec tunnel is established; has no effect on non-VPN traffic.
Tunnel Monitor
Is a continuous feature that periodically sends pings through the tunnel.
Can automatically trigger a re-establishment of the tunnel if pings fail.
Configurable in the advanced settings of the IPsec tunnel object.
Test VPN Tunnel
Is a one-time diagnostic action initiated manually by an administrator.
Sends a single test packet and reports success or failure.
Located in the GUI under the 'Troubleshooting' tab.
Mistake
Once a site-to-site VPN tunnel is up, all traffic between the two sites automatically flows through it.
Correct
Traffic only flows through the tunnel if a security policy explicitly permits it and the routing table points traffic to the tunnel interface. The tunnel is just a path; you must create a policy that allows traffic from the source zone to the tunnel zone or destination zone.
Beginners think the tunnel automatically acts like a physical cable. They forget that a firewall, by default, blocks all traffic unless a policy allows it.
Mistake
If Phase 1 succeeds but Phase 2 fails, the problem is always with the pre-shared key.
Correct
Phase 1 uses the pre-shared key for authentication. If Phase 1 succeeds, the pre-shared key is correct. Phase 2 failure is almost always caused by mismatched proxy IDs, mismatched encryption/authentication algorithms in the IPsec crypto profile, or incorrect Diffie-Hellman group settings for the IPsec SA.
Beginners learn that the pre-shared key is crucial, so they blame it for every failure. They do not understand that Phase 1 and Phase 2 are separate negotiations with separate parameters.
Mistake
A site-to-site VPN tunnel can be configured on any interface, including the management interface.
Correct
The tunnel interface is a separate logical interface. The management interface (MGT) is for out-of-band management and must not be used for VPN traffic. The data-plane interfaces (like ethernet1/1) are used for the VPN termination point.
Beginners see the management interface as another network connection and assume it can handle VPN traffic, but Palo Alto Networks firewalls strictly separate the management plane from the data plane for security and performance.
Mistake
If the tunnel is down, the only way to troubleshoot is to reboot both firewalls.
Correct
You should first check the system logs, verify the IKE and IPsec SA status using commands like 'show vpn ipsec-sa' and 'show vpn ike-sa', and use the GUI's 'Test VPN Tunnel' feature. Rebooting is unnecessary and may lose critical log information.
Beginners panic and think a hard reset is the universal fix. They do not know the specific diagnostic commands available on Palo Alto Networks firewalls.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Check the IKE version setting. If one side is set to IKEv1 and the other to IKEv2, the negotiation will fail immediately. Also verify that the public IP addresses are correctly entered and reachable from each side.
Yes, you must define proxy IDs unless you are using IKEv2 with the option to use 'any' for local and remote subnets, which is not recommended. Proxy IDs explicitly tell the firewall which subnets are allowed through the tunnel, preventing misrouting.
It means that Phase 1 was successful (the authentication and secure channel were established), but Phase 2 failed to agree on the data tunnel parameters. The most common causes are mismatched IPsec crypto profiles (encryption or authentication algorithms) or mismatched proxy IDs.
No, each site-to-site VPN tunnel connects exactly two endpoints. For multiple branch offices, you need a separate tunnel from the head office to each branch. You cannot reuse the same tunnel object for multiple remote peers.
Use the command 'show vpn flow tunnel-name' in the CLI. It shows packet and byte counters. Alternatively, in the GUI, go to the 'IPSec Tunnels' widget and look for 'Transmitted' and 'Received' packet counts.
A tunnel interface is a logical interface on the Palo Alto firewall that represents the VPN endpoint. Traffic that should go through the VPN must have its destination route pointing to this tunnel interface. It is required because it ties the security policy and routing together for the VPN traffic.
You've finished Site-to-Site VPN Configuration and Troubleshooting. Continue through the PCNSE study guide to build a complete picture of the exam.
Done with this chapter?