u/samsh92

I recently completed a practical lab for configuring a site-to-site IPsec VPN between two Palo Alto firewalls and wanted to share the configuration flow with the community.

Instead of treating IPsec VPN as one large configuration, I broke it down into the individual pieces that actually need to work together:

WAN Interfaces
      ↓
Tunnel Interface
      ↓
IKE Crypto Profile
      ↓
IKE Gateway
      ↓
IPsec Crypto Profile
      ↓
IPsec Tunnel
      ↓
Route to Remote Network
      ↓
Security Policy
      ↓
NAT
      ↓
VPN Verification

The lab uses two Palo Alto firewalls in EVE-NG with a route-based IPsec VPN and tunnel.2 as the logical tunnel interface.

The interesting part is that creating the tunnel is only one piece of the configuration. You also need the correct routes, security policies, and return path before actual traffic can pass.

In my lab, I tested connectivity between:

Site-1 DMZ:  172.20.1.0/24
Site-2 LAN:  172.20.10.0/24

I documented the complete configuration and verification process here:

How to Configure Site-to-Site IPsec VPN on Palo Alto

For those working with Palo Alto or other firewall platforms, I'm curious: which part of a site-to-site IPsec VPN usually gives you the most trouble—IKE Phase 1, Phase 2, routing, NAT, or security policy?

One of the more confusing Palo Alto VPN issues is when the IKE SA and IPsec SA are both UP, but traffic still doesn't pass.

When troubleshooting a site-to-site IPsec VPN, I usually try to avoid changing multiple settings at once and instead work through the traffic path step by step:

• Is the VPN peer reachable?
• Is IKE Phase 1 established?
• Is IPsec Phase 2 established?
• Are the IKE/IPsec proposals matching?
• Are Proxy IDs or traffic selectors causing an issue?
• Is there a route to the remote subnet?
• Is the security policy matching the traffic?
• Is NAT accidentally being applied?
• Are VPN traffic counters increasing?
• What do the traffic logs show?
• If needed, where should packet capture be performed?

One thing that is easy to overlook is that a tunnel being UP doesn't necessarily mean the application traffic will work. The VPN can be perfectly established while routing, security policy, NAT, or the return path is still wrong.

I put together a practical troubleshooting guide covering these checks along with useful Palo Alto CLI commands such as:

show vpn ike-sa
show vpn ipsec-sa
show vpn flow
test vpn ike-sa gateway <gateway>
test vpn ipsec-sa tunnel <tunnel>

If anyone is troubleshooting Palo Alto IPsec VPNs, I'd be interested to hear what problem you encounter most often — Phase 1, Phase 2, routing, policy, NAT, or something else.

For anyone who wants the full troubleshooting flow, I documented it here:

Palo Alto IPsec VPN Troubleshooting: Common Problems and Solutions

Ran into this one again recently and figured I'd write it up since it trips people up constantly.

Setup: office has a site-to-site VPN to a vendor's network for some internal app. Works fine for anyone sitting in the office. But the second someone connects remotely over NetExtender (SonicWall's SSL VPN client), the same app just... doesn't load. No error, just times out.

The instinct is to blame the site-to-site tunnel, but 9 times out of 10 that tunnel is completely healthy. The actual problem is that the SSL VPN client traffic has to hop through two separate VPNs to get there, and SonicWall treats that SSL VPN client as its own separate network — not as if it's sitting inside the office LAN. So every layer that "just works" for office users has to be explicitly configured for the remote ones too.

The things that usually turn out to be missing, roughly in the order I check them:

• NetExtender handing out the user's home router as DNS instead of the internal DNS server, so the internal hostname never resolves in the first place
• The vendor's subnet not being included in the routes pushed to the SSL VPN client, so even if DNS resolves, Windows just sends the traffic out the regular internet connection instead of the tunnel
• No access rule allowing SSLVPN zone → VPN zone (there's usually already one for SSLVPN → LAN, but that doesn't cover traffic headed to a site-to-site tunnel)
• The SSL VPN client's IP pool not being included in the site-to-site VPN's local network / proxy ID definition, so even correctly-routed traffic gets silently dropped because the tunnel doesn't recognize where it's coming from

That last one is the sneaky one — everything can look right on your end and it'll still fail if the vendor's firewall doesn't know your SSL VPN subnet exists.

I put together the full walkthrough with the exact menus/commands to check each layer (ipconfig, nslookup, tracert, etc.) here if anyone wants the step-by-step: https://www.firewallflow.com/double-hop-vpn-access-on-sonicwall/

Curious if others have hit this with different firewall vendors too — feels like a "learned it the hard way" kind of problem.