<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Vpn - Tag - Fryguy's Blog</title><link>https://fryguy.net/tags/vpn/</link><description>Vpn - Tag - Fryguy's Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Thu, 13 Aug 2026 15:15:00 +0000</lastBuildDate><atom:link href="https://fryguy.net/tags/vpn/" rel="self" type="application/rss+xml"/><item><title>New Tool - IPsec VPN Configuration Generator (Multi-Vendor, Policy vs Route-Based Interop)</title><link>https://fryguy.net/2026/08/13/new-tool-ipsec-vpn-configuration-generator/</link><pubDate>Thu, 13 Aug 2026 15:15:00 +0000</pubDate><author>Fryguy</author><guid>https://fryguy.net/2026/08/13/new-tool-ipsec-vpn-configuration-generator/</guid><description><![CDATA[<p>Added a new one to the <a href="/tools/" rel="">Network Tools</a> page: an <a href="/tools-ipsec-generator/" rel="">IPsec VPN Configuration Generator</a> for Cisco IOS/IOS-XE, ASA, FortiGate, Palo Alto, Juniper SRX, strongSwan/VyOS, UniFi, and pfSense/OPNsense.</p>
<p>The reason I built this instead of just pointing at vendor docs is the case that actually breaks real deployments: <strong>pairing a policy-based peer with a route-based one.</strong> A route-based side (VTI/tunnel interface) defaults to a catch-all <code>0.0.0.0/0 ↔ 0.0.0.0/0</code> selector, since routing decides what enters the tunnel. A policy-based peer negotiates specific proxy-IDs per subnet pair, pulled straight from its ACL. Put those two together unmodified and phase 2 negotiation just fails — no useful error, just a tunnel that won&rsquo;t come up.</p>]]></description></item></channel></rss>