The problem
Enterprise firewalls such as FortiGate can use application identification and deep packet inspection to classify VPN traffic independently of the destination port. In an authorised lab, I used this behaviour to compare direct commercial-VPN connections with a routed Tailscale exit-node design and to understand which controls acted at each layer.
FortiNet products specifically maintain signature databases for VPN protocols including OpenVPN, WireGuard, and commercial VPN providers. A standard firewall policy set to "deny VPN" at Layer 7 will block ProtonVPN, PIA and similar services even when they attempt to disguise their traffic as HTTPS.
Why this matters
Understanding how enterprise DPI works and how to architect around it is directly relevant to both security testing and infrastructure design. If you manage firewalls professionally, you need to understand what they can and cannot detect. And if you need legitimate private connectivity through a restrictive network, you need to know which tunnel designs survive DPI and which do not.
How I solved it
Instead of fighting the DPI at Layer 7 where FortiGate is strongest, I designed a solution that operates at a lower network layer. Tailscale uses the WireGuard protocol underneath, but wraps it in a NAT-traversal layer (DERP relays and direct UDP hole-punching) that doesn't present the same protocol signatures as raw WireGuard or OpenVPN.
My architecture routes traffic through a Tailscale exit node running on an LXC container behind pfSense. The exit node forwards traffic through ProtonVPN's WireGuard interface, so the effective path is:
Device → Tailscale tunnel (encrypted, NAT-traversed)
→ LXC exit-node on Proxmox
→ ProtonVPN WireGuard interface
→ Internet via Proton exit serverBecause the initial hop uses Tailscale's NAT traversal (which looks like ordinary UDP traffic rather than a recognisable VPN handshake), it passes through DPI policies that would block a direct ProtonVPN or PIA connection. The Layer 5–7 fingerprinting sees UDP traffic, not a VPN protocol signature.
What I learned
- FortiGate DPI identifies VPN protocols by their handshake patterns, not just by port or destination
- Operating at a lower layer (L2/L3 tunnelling inside NAT-traversed UDP) avoids the application-layer signatures that DPI targets
- Tailscale's DERP relay and hole-punching design makes it resistant to protocol-based blocking
- pfSense policy routing is needed to direct traffic from the exit node through the correct VPN interface
- A watchdog script with automatic recovery is essential for reliability when chaining VPN layers
What this gives you
A practical understanding of how enterprise DPI works, where its blind spots are, and how to design tunnel architectures that provide legitimate private connectivity through restrictive networks. This is real infrastructure design, not a theoretical exercise — it runs on my own hardware and I maintain the routing, failover and monitoring around it.
How to deploy or reproduce it
Build a disposable lab client or gateway, import an authorised Proton VPN profile and route only a test subnet or selected device through it.
Verify the public exit address, DNS path and failure behaviour, then document a rollback route so normal connectivity can be restored immediately.