Meraki MX IPsec VPN Health Check is failing because its return traffic is being blocked in azure (port 80)

Allan,

Thank you for your response. I should have indicated that I'm not a networking expert, so some of what you say is not understood by me. Let me start with some easy answers to your questions.

I understand and am aware of the Basic SKU advice.

The 192.0.2.3 is per Meraki support, evidently this is their standard source address for their Health Check configuration.

There is no firewall or NVA in my Azure VNET. From one of the VMs in the VNET, I can use port 80. NSG has been tested, it allows outbound 80.

My local network gateway does include 192.0.2.0/24 as an address space, along with my other Meraki SDWAN subnets.

I have not seen the article related to configuring a packet capture for VPN gateway, so thanks for that. I will give that a try.

Finally, I am familiar with Wireshark, but need a bit of advice from you as to how to accomplish what you suggest. Do I do the Wireshark capture from a VM in the VNET, or can it be done from my local PC (that accesses the VNET through the tunnel)? Either way, can you describe exactly how I setup the filter to do the capture?

Again, thank you!

Steve

Allan,

Thank you for your response. I should have indicated that I'm not a networking expert, so some of what you say is not understood by me. Let me start with some easy answers to your questions.

I understand and am aware of the Basic SKU advice.

The 192.0.2.3 is per Meraki support, evidently this is their standard source address for their Health Check configuration.

There is no firewall or NVA in my Azure VNET. From one of the VMs in the VNET, I can use port 80. NSG has been tested, it allows outbound 80.

My local network gateway does include 192.0.2.0/24 as an address space, along with my other Meraki SDWAN subnets.

I have not seen the article related to configuring a packet capture for VPN gateway, so thanks for that. I will give that a try.

Finally, I am familiar with Wireshark, but need a bit of advice from you as to how to accomplish what you suggest. Do I do the Wireshark capture from a VM in the VNET, or can it be done from my local PC (that accesses the VNET through the tunnel)? Either way, can you describe exactly how I setup the filter to do the capture?

Again, thank you!

Steve

Hello @Steve G

The key detail here is the destination:

192.0.2.3 → 142.250.138.102:80

If Meraki is sending that health-check traffic through the IPsec tunnel toward Azure, Azure VPN Gateway itself isn't an Internet NAT/egress device. The first thing I'd determine, then, is not whether Azure is "blocking port 80," but where Azure is expected to send and NAT that Internet-bound packet after it enters the VNet.

Azure documents that forced-tunneled Internet traffic normally needs to be routed to an appropriate egress path; the VPN Gateway alone doesn't provide Internet NAT in this scenario.

For example, if the expected path is:

Meraki MX

↓ IPsec

Azure VPN Gateway

↓

Azure Firewall / NVA

↓ SNAT

Internet

↓

142.250.138.102:80

then the return traffic must come back through the same NAT/egress path before it can return through the VPN to the Meraki.

Capture the traffic at the VPN Gateway

Azure VPN Gateway supports packet capture directly on the gateway or on an individual VPN connection. It can capture inner packets and supports filtering by source/destination subnet, ports, protocol and TCP flags.

I would start a capture on the specific Meraki VPN connection, reproduce the failed health check, then stop the capture and inspect the PCAP in Wireshark.

Microsoft recommends capturing both directions when troubleshooting this type of issue.

For your example, I'd look specifically for:

192.0.2.3 → 142.250.138.102 TCP/80

and determine whether you see:

SYN →

← SYN, ACK

or only repeated outbound SYNs.

That distinction is important.

If the SYN enters Azure but never leaves toward the Internet, investigate Azure routing/egress.

If the SYN leaves through an Azure Firewall/NVA but no SYN-ACK returns, investigate NAT, firewall policy, upstream routing or the destination.

If the SYN-ACK returns to Azure but doesn't traverse the VPN back to 192.0.2.3, investigate the return route, traffic selectors, and effective routing toward the Meraki network.

I would also check whether 192.0.2.3 is actually included in the Azure Local Network Gateway address prefixes / IPsec traffic selectors. If Azure doesn't have a route back to that source through the Meraki connection, the outbound request could traverse the tunnel, but the response might not return correctly.

One additional point: 192.0.2.0/24 is TEST-NET-1, reserved for documentation. If 192.0.2.3 is the literal address being generated by the Meraki feature rather than an anonymized address in your post, that deserves special attention. I wouldn't assume Azure has a valid routable return path for it.

I'd therefore check these three things before changing NSGs:

1. Whether 192.0.2.3 is the actual source and is included in the VPN routing/traffic selectors.
2. What device provides Internet egress/SNAT after the health-check packet enters Azure.
3. A bidirectional VPN Gateway packet capture showing whether the TCP SYN-ACK ever returns.

I wouldn't focus on NSGs unless the traffic is actually traversing a subnet/NIC controlled by an NSG. The VPN Gateway isn't simply applying an NSG rule that blocks TCP/80.

Microsoft also describes Basic VPN Gateway as having feature/performance limitations and recommends against using it for production workloads. Once we understand this issue, I'd consider planning a migration to a supported production SKU rather than building additional functionality around Basic.

Sharing these references with you:

Microsoft - Configure packet capture for VPN Gateway

Microsoft - About forced tunneling for Site-to-Site VPN

Microsoft - VPN Gateway SKUs

If you can share the Local Network Gateway prefixes, VNet route/UDR configuration, and whether Azure Firewall/an NVA provides Internet egress, we can narrow down exactly where the return path is being lost.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.