Alright, let's set the stage. I'm the guy who changes CRMs annually, so I'm no stranger to the exquisite pain of complex system migrations and the inevitable integration failures. Now I'm staring down a different beast: our shiny new Versa SD-WAN deployment, which was supposed to unify our chaos, is instead refusing to play nice with our Azure environment.
The mandate was simple: establish a reliable site-to-site IPSec VPN from our Versa CPEs to an Azure Virtual Network Gateway. The reality, as usual, is a festival of cryptic log entries and silent failures. We've followed the standard recipes—shared keys match, BGP is configured (and then disabled for testing), policy-based traffic selectors are set, IKE versions aligned. Yet, the tunnel flaps, or worse, establishes but passes no meaningful traffic. The Versa Director logs are a masterclass in obfuscation.
Here’s a taste of our current purgatory:
* Phase 1 negotiates successfully. IKE SA shows as established. A brief moment of hope.
* Phase 2 then fails intermittently with `NO_PROPOSAL_CHOSEN` errors, despite the Azure-side and Versa-side IPSec policies being mirror images of each other (AES256-GCM-16 for encryption, SHA384 for integrity, PFS group 24).
* On the occasions Phase 2 does complete, the tunnel appears "up" in Director, but a simple ping from an on-prem subnet to an Azure VM subnet results in timeout. Route tables are correct, security policies are wide open for testing.
* The Azure network watcher shows the packets arriving at the gateway but being dropped with the generic "Traffic Selector Mismatch" diagnostic, which is hilariously unhelpful given the traffic selectors are defined as 0.0.0.0/0 to our specific Azure VNet subnet.
The suspicion, born from years of watching vendors point fingers, is that there's a subtle mismatch in the IKE or IPSec payload construction that isn't surfaced in the GUI logs. Perhaps it's the DH group interpretation, or the handling of NAT-T, or the lifetime values. Azure is notoriously particular.
Has anyone else navigated this specific trench warfare between Versa and Azure? I'm particularly interested in:
* The exact IKEv2 and IPSec configuration parameters that finally yielded stability, beyond the boilerplate documentation.
* Any gotchas with policy-based vs. route-based VPN configuration on the Versa side when connecting to Azure's route-based gateway.
* Whether using a custom IPSec policy in Azure (disabling the default "policy-based traffic selector" checkbox) made a tangible difference.
* The utility (or futility) of trying to get more granular debug logs from the Versa appliance itself via CLI, and what those magic commands might be.
I'm documenting this process with the same grim satisfaction I apply to CRM migrations. Every broken integration is a lesson in vendor-specific dogma. Let's see if Versa's dogma can be reconciled with Microsoft's.
That `NO_PROPOSAL_CHOSEN` even after Phase 1 success is maddening. While your policies look mirrored, Azure's gateways can be particular about exact matches for PFS group and SA lifetime. I've seen similar silent failures when the lifetime seconds don't match, even though the tunnel establishes.
Check the Phase 2 SA lifetime settings in both configs. Azure defaults to 3600 seconds for IPSec SA. If Versa is sending a different value, it'll cause a mismatch that logs as a proposal error.
Also, with AES-GCM, verify the data integrity algorithm is explicitly set. Some platforms treat it as combined mode, others expect it separately.
sub-100ms or bust