Setting up a site-to-site VPN between Microsoft Azure and a Cisco Meraki firewall is typically a straightforward process. Most of the time, once the tunnel shows as connected, you expect everything to just work. But every now and then, you run into a situation where things don’t behave the way they should.
When “connected” doesn’t mean “working”
Recently, I ran into exactly that. The VPN showed as connected, the configuration looked correct on both sides, and there were no obvious errors. On the surface, everything appeared healthy. However, when it came time to test connectivity, traffic simply would not pass between Azure and the Meraki network. It was one of those frustrating scenarios where nothing is clearly broken, yet nothing is working either.
Digging deeper: the hidden NAT requirement
After working through the issue and eventually looping in support, the root cause turned out to be something I didn’t initially expect. The problem wasn’t the tunnel itself, but rather how Azure was handling traffic behind the scenes. Specifically, Azure required certain NAT-related fields to be populated before the VPN would function properly. These fields were labeled as optional, which made it easy to overlook them during the initial configuration.
What made this especially tricky is that Azure still allowed the tunnel to establish successfully. From a status perspective, everything looked correct. But without those NAT-related values defined, Azure didn’t fully understand how to process the traffic moving across the tunnel. As a result, the connection existed, but data never actually flowed. There were no clear error messages pointing to NAT as the issue, which made troubleshooting feel like chasing the wrong problem.
The solution: fill in the details
To access these NAT related fields access your Meraki firewalls. Navigate to the site-to-site VPN settings and edit your VPN tunnel. You will see the “Local ID” and “Remote ID” fields with the text option. These are the settings that need to be configured in order to get through the Azure NAT.
Once those NAT-related fields were filled in properly, the behavior changed immediately. Traffic began flowing without any additional adjustments, and the VPN started working exactly as expected. No changes were required on the Meraki side, which further confirmed that the issue was entirely within Azure’s handling of the connection.
Lessons learned
This experience was a great reminder that in cloud environments, “connected” does not always mean “working.” There is often additional logic happening behind the scenes that isn’t immediately visible in the interface. It also reinforced an important lesson: fields labeled as optional are not always truly optional. Depending on the scenario, they can be essential to making a configuration function correctly.
Troubleshooting tips and final thoughts
If you find yourself troubleshooting a similar issue—where the VPN shows as connected but traffic isn’t flowing, configurations appear correct, and there are no clear errors—it’s worth taking a closer look at the NAT settings in Azure. Even if you didn’t intend to use NAT, those fields may still need to be defined for the tunnel to operate properly.
This was one of those issues that wasn’t obvious at first, but once identified, the fix was quick and straightforward. If your Azure to Meraki VPN is up but not passing traffic, don’t overlook NAT. Sometimes the solution is hiding in the details that seem the least important.
Have any questions about setting up VPNs with Azure?
Feel free to reach out to our experts at any time!
This publication contains general information only and Sikich is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or any other professional advice or services. This publication is not a substitute for such professional advice or services, nor should you use it as a basis for any decision, action or omission that may affect you or your business. Before making any decision, taking any action or omitting an action that may affect you or your business, you should consult a qualified professional advisor. In addition, this publication may contain certain content generated by an artificial intelligence (AI) language model. You acknowledge that Sikich shall not be responsible for any loss sustained by you or any person who relies on this publication.
