FortiGate vs Palo Alto VPN: clients, posture and interop

The two clients

Both vendors ship a client, and both charge for the parts of it that make an estate manageable.

On Palo Alto, remote access through single or multiple gateways works without a GlobalProtect license. A GlobalProtect gateway license is required for the advanced features, which include HIP checks and their associated content updates, mobile app support, IPv6 support and clientless VPN.

On Fortinet, a free standalone client provides basic VPN connectivity to a FortiGate. Managed deployment requires a FortiClient EMS server license plus per-endpoint subscriptions, with tiers separating VPN and ZTNA capability from full endpoint protection. Central configuration, posture enforcement and endpoint telemetry sit in the licensed tier.

Compiled from Palo Alto Networks GlobalProtect licensing documentation and Fortinet FortiClient ordering guide, checked 8 August 2026. SSL VPN web mode availability has changed between FortiOS releases, so confirm it against the release the customer will run.

The practical difference for an MSP is where the cost lands. Palo Alto attaches the advanced capability to the firewall, so the cost scales with sites. Fortinet attaches it to the endpoint, so the cost scales with users. A customer with few sites and many users and a customer with many sites and few users reach opposite conclusions from the same two price lists.

Endpoint posture

Posture checking is the capability customers ask for by describing a scenario rather than a product. They want the laptop with no disk encryption to be refused.

Both platforms can assert facts about a connecting device and use them in policy. Both require the licensed tier to do it. On Palo Alto that is the GlobalProtect gateway license, which covers HIP checks and their content updates. On Fortinet that is EMS licensing, which covers the managed client.

Two things are worth telling the customer before they commit.

Posture is a statement made by software running on the endpoint. It is a meaningful control against misconfiguration and a weaker control against a determined attacker with local administrative rights. Describe it accurately rather than as device attestation.

Posture enforcement generates support load. Every check that can fail will fail for somebody on a Monday morning, and the person answering that call needs to be able to see why the check failed. Confirm who holds that visibility before the control goes live.

IPsec mismatch checklist

FortiGate and Palo Alto interoperate over IPsec. Both implement standard IKE, and a tunnel between them is routine work. Failures are parameter mismatches.

Work phase 1 first and phase 2 second. A phase 2 problem cannot be diagnosed while phase 1 is failing, and most of the time lost on these tunnels is lost by looking at the wrong phase.

Terminology taken from each vendor's current IPsec VPN configuration documentation, checked 8 August 2026. Menu labels move between releases on both platforms. The parameter names are stable enough to search for in whichever version you are running.

Three of these account for most of the calls we take on cross-vendor tunnels.

Selectors disagree more often than ciphers do. A Palo Alto peering with a device configured for policy-based behaviour needs proxy IDs that match the other side's phase 2 selectors exactly. A single mismatched subnet produces a tunnel that establishes and carries nothing.

Lifetimes are the cause of the tunnel that works and then fails on a schedule. Where two sides disagree, the shorter lifetime governs and the rekey is where the failure appears. Match them explicitly rather than leaving both at their defaults.

Packet size is the cause of the tunnel that passes a ping and fails a file transfer. Encapsulation adds overhead, and any path with a reduced maximum transmission unit will drop the resulting large packets. Test with a large payload before concluding the tunnel is healthy.

Where to look when it fails

Check in this order. Each step tells you whether to continue to the next one.

1. Confirm both peers can reach each other on the required UDP ports, and that nothing in the path is filtering them.
2. Read phase 1 status on both sides. Establish which side is rejecting before changing anything.
3. On the FortiGate, use the IKE debug facility and the VPN tunnel listing to see the negotiated parameters rather than the configured ones.
4. On the Palo Alto, read the system log filtered to IKE events, and the IKE manager log for the detail behind a generic failure message.
5. Compare the negotiated proposal against the configured proposal on both sides. These differ more often than expected where a device offers several.
6. Once phase 1 is stable, compare selectors and proxy IDs before touching phase 2 crypto.
7. With the tunnel up and no traffic passing, check routing toward the tunnel interface, then the firewall policy permitting the traffic, then packet size.

Diagnostic commands and log locations differ between releases on both platforms. Confirm the exact syntax against the documentation for the firmware in front of you rather than against a page written for a different version.

SASE, briefly

Both vendors sell a cloud-delivered access platform. Fortinet's is FortiSASE and Palo Alto's is Prisma Access. Both move enforcement from the customer's firewall to a service, and both are priced per user rather than per appliance.

Two observations are safe to make and useful to a customer.

The buying decision changes shape. A per-user recurring cost replaces an appliance refresh cycle, which suits some customers and unsettles others. Model it across the same term as the appliance alternative before presenting either.

The operational load moves rather than disappearing. Policy still has to be authored, access still has to be granted and revoked, and incidents still need somebody to answer them. What changes is where the work happens.

This section carries a short review interval. Both platforms change frequently, so confirm current capability against vendor documentation before quoting anything from here. Checked 8 August 2026.

Should it stay on the firewall

Per-application access is a genuine improvement on a tunnel that places a device on the network. It is also a program rather than a product swap, and presenting it as a straightforward upgrade sets a customer up for a difficult year.

The case for moving is real. Access granted per application limits what a compromised device reaches. Capacity stops concentrating at the firewall, which removes a sizing constraint that grows with the remote workforce. Access decisions become continuous rather than made once at connection time.

The case for staying is equally real.

• It carries a recurring per-user cost where the firewall path is largely already paid for.
• It depends on an identity foundation with accurate groups and reliable joiner and leaver processes. Many customers do not have that yet, and building it is the actual project.
• Legacy applications rarely fit the model cleanly, so a tunnel path usually remains for a subset of access.
• It adds a dependency on a service outside the customer's control, which some customers are required to assess formally.

The useful advice to give a customer is sequencing. Move the applications that fit the model first, keep the firewall path for the rest, and treat the identity work as the prerequisite it is. A customer who hears that from you rather than from the vendor gets a plan they can fund.