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

Question

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

Steve G 0

I have an IPsec VPN tunnel using a Meraki MX and an Azure virtual network gateway (Basic SKU). The tunnel is good. I'm trying to use a Meraki load balancing feature called "Multi-Uplink IPsec VPN", but the Meraki Health Check is failing (causing the tunnel to go down when the multi-uplink feature is "ON"). Meraki tech support indicates the health check traffic is going out of the tunnel, but there no return, so it fails. I need your assistance with capturing the flow of this traffic, or otherwise troubleshoot the issue, so that I can see where and what may be blocking the return. Traffic characteristics: TCP; Port:80; SRC: 192.0.2.3; DST: 142.250.138.102 (google.com). Thank you.

0 comments

4 answers

Your answer

Answer 1

Allan Solomon Mejia 7,915

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:

Whether 192.0.2.3 is the actual source and is included in the VPN routing/traffic selectors.
What device provides Internet egress/SNAT after the health-check packet enters Azure.
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.

Allan Solomon Mejia 7,915 Reputation points

2026-08-21T20:15:46.5333333+00:00

Hello @Steve G

Thanks for the additional details. Since 192.0.2.0/24 is already included in the Local Network Gateway address space, there is no NVA/firewall in the VNet, and normal outbound TCP/80 from an Azure VM works, I’d focus the next test specifically on the VPN Gateway path.

For this issue, I wouldn't start with Wireshark on your local PC. A capture there wouldn't necessarily show what Azure VPN Gateway is doing with the Meraki-generated health-check traffic.

The better approach is to capture directly on the Azure VPN Gateway/connection while reproducing the failure. Azure VPN Gateway packet capture supports filtering by source/destination subnet, ports, and protocol, and can capture the inner packets traversing the tunnel.

For your case, the flow we're interested in is:

Source: 192.0.2.3

Destination: 142.250.138.102

Protocol: TCP

Destination port: 80

I would capture both directions, enable the Meraki Multi-Uplink feature, allow the health check to fail a few times, then stop the capture and inspect the resulting PCAP in Wireshark. Microsoft recommends longer captures when troubleshooting VPN Gateway because synchronization between components can make very short captures incomplete.

Once you open the PCAP in Wireshark, a simple display filter would be:

ip.addr == 192.0.2.3 && ip.addr == 142.250.138.102 && tcp.port == 80

Or, to look specifically at traffic originating from the Meraki health-check address:

ip.src == 192.0.2.3 && ip.dst == 142.250.138.102 && tcp.dstport == 80

We're looking for the TCP handshake.

If the capture shows the SYN from 192.0.2.3 entering Azure but nothing being forwarded toward 142.250.138.102, that significantly narrows the issue to Azure routing/egress behavior.

If Azure sends the SYN outward but no SYN/ACK comes back, then we're looking further downstream rather than at an NSG blocking the return.

If a SYN/ACK returns to Azure but isn't sent back through the VPN tunnel to 192.0.2.3, that gives us another very specific direction to investigate.

Network Watcher can also capture packets on an Azure VM, but that only captures traffic to/from that VM. Since 192.0.2.3 → 142.250.138.102 isn't destined for your VM, a VM capture isn't the best primary observation point here.

So I’d start with the VPN Gateway packet capture rather than installing Wireshark on another system.

Microsoft - Configure packet capture for Azure VPN Gateway

If you can share what the capture shows for the SYN/SYN-ACK sequence (you don't necessarily need to upload the entire PCAP), we should be able to determine which side of the tunnel is dropping the flow.

Please don't forget to "Accept the Answer" if this information helped you. This will help us and others in the community.
Steve G 0 Reputation points

2026-08-24T14:25:14.7633333+00:00

Allan:

Thank you for your update (last Friday, at 3:15PM). Unfortunately, I do not see the packet capture option on my "gateway". I notice my Azure resource is called a "Virtual Network gateway", whereas your link refers to a "VPN Gateway" (see embedded image)

. I cannot find a difference, do you know what one is versus the other?
Allan Solomon Mejia 7,915 Reputation points

2026-08-24T14:32:44.4+00:00
Hello @Steve G

Yes, the terminology is confusing, but the resource in your screenshot is correct.

“Virtual network gateway” is the Azure resource type. “VPN Gateway” is the specific type of virtual network gateway you're using. Microsoft describes it this way:

A VPN gateway is a type of virtual network gateway.

You can create a virtual network gateway for different purposes, including VPN and ExpressRoute. When its gateway type is VPN, Microsoft refers to it throughout the documentation as an Azure VPN Gateway.

So you don't have the wrong gateway, and you don't need to create another resource.

The reason you're not seeing Packet capture in the left-hand menu is a separate issue. The documentation I linked describes the VPN Gateway packet-capture capability, but the portal experience can differ depending on the gateway configuration/SKU. Microsoft also supports starting and stopping VPN Gateway packet capture programmatically.

There's one particularly important detail in your environment: you're using the Basic SKU. So rather than spending time looking for a portal blade that isn't appearing, I suggest we first confirm whether packet capture is available for your particular gateway configuration.

Could you run the following in Azure Cloud Shell and post the result?

Get-AzVirtualNetworkGateway ` -Name "<your-VNGW-name>" ` -ResourceGroupName "<your-resource-group>" | Select-Object Name, GatewayType, VpnType, ProvisioningState, @{N="SKU";E={$_.Sku.Name}}

I'm expecting something similar to:

Name: <your gateway>

GatewayType: Vpn

VpnType: RouteBased

ProvisioningState: Succeeded

SKU: Basic

That will confirm exactly what we're working with.

Also, don't confuse this with Network Watcher > Packet capture. Network Watcher's standard packet-capture feature is primarily for capturing traffic to/from Azure VMs or VM scale sets; it isn't the same thing as the VPN Gateway packet capture I was referring to.

For your Meraki issue, we specifically want visibility into the traffic traversing the VPN connection:

So a VM-based Network Watcher capture won't necessarily tell us what the gateway is doing with that Meraki health-check packet.

Your screenshot therefore doesn't indicate that anything is wrong with the resource itself. You do have an Azure VPN Gateway; Azure simply labels the resource as a “Virtual network gateway.”

Microsoft references:

Microsoft – Azure VPN Gateway FAQ

Microsoft – VPN Gateway configuration settings

Microsoft – Configure packet capture for VPN Gateway

Post the PowerShell output when you have it, particularly the GatewayType, VpnType, and SKU, and we can determine the correct capture method from there.
Steve G 0 Reputation points

2026-08-24T15:17:13.18+00:00

Name : redacted

GatewayType : Vpn

VpnType : RouteBased

ProvisioningState : Succeeded

SKU : Basic
Allan Solomon Mejia 7,915 Reputation points

2026-08-24T15:43:58.7233333+00:00
Hello @Steve G

Thank you; that output answers the question.

Your gateway is:

GatewayType: Vpn

VpnType: RouteBased

ProvisioningState: Succeeded

SKU: Basic

So you definitely have an Azure VPN Gateway, and it's correctly configured as a route-based VPN gateway.

The important part is:

SKU: Basic

This explains why you aren't seeing the VPN Gateway Packet capture option I previously referenced.

The Basic VPN Gateway SKU has a limited feature set compared with the VpnGw SKUs. Microsoft recommends Basic primarily for dev/test or proof-of-concept workloads, not production workloads.

More specifically, Microsoft Support has previously confirmed that the VPN Gateway packet-capture API/cmdlet isn't supported for the Basic gateway SKU.

So my earlier suggestion to perform a gateway packet capture isn't applicable to your current Basic SKU. Your screenshot didn't miss anything due to a portal issue.

I also wouldn't recommend upgrading the gateway just to troubleshoot this Meraki health check yet.

Instead, I'd continue by checking the traffic from both sides.

On the Meraki side, capture the health-check traffic and verify whether the MX is sending:

Source: 192.0.2.3

Destination: 142.250.138.102

Protocol: TCP

Port: 80

and whether any response returns through the VPN tunnel.

In Azure, we can use resources behind the gateway to determine whether traffic is actually entering the VNet. If there's an Azure VM on the relevant path/subnet, Network Watcher packet capture can capture traffic to and from that VM, although it won't capture directly on the Basic VPN Gateway itself.

This distinction matters because we're trying to determine whether:

The next question is whether 142.250.138.102 is actually supposed to be reached through Azure.

Could you share the Local Network Gateway address prefixes configured for the Meraki connection?

You can retrieve them with:

Get-AzLocalNetworkGateway ` -Name "<local-network-gateway-name>" ` -ResourceGroupName "<resource-group>" | Select-Object -ExpandProperty LocalNetworkAddressSpace

Also, please share the Azure VNet address space:

Get-AzVirtualNetwork ` -Name "<vnet-name>" ` -ResourceGroupName "<resource-group>" | Select-Object -ExpandProperty AddressSpace

If 142.250.138.102 is a public Internet destination, the next thing we need to establish is why the Meraki MX is routing that health-check destination into the Azure S2S tunnel in the first place, and what Azure resource is expected to provide Internet egress for that traffic.

That may ultimately be more relevant to the health-check failure than the VPN tunnel itself.

Microsoft references:

Azure VPN Gateway SKU and feature information

VPN Gateway packet capture documentation

Network Watcher packet capture overview

For now, don't change or upgrade the gateway. Let's verify the routing path first.
Allan Solomon Mejia 7,915 Reputation points

2026-08-26T16:44:21.2+00:00

Hi @Steve G

Thanks, that clarification is very helpful.

I agree that the Meraki Health Check itself isn't simply testing whether google.com is reachable. The important point here is that the probe leaves through the VPN tunnel on TCP 80, but you're seeing no return traffic.

Given that your Azure VMs in the same VNet can successfully communicate over TCP 80/443, I don't think we have enough evidence to conclude that the Basic VPN Gateway SKU is the limitation. Basic supports site-to-site VPN connectivity; upgrading the SKU may provide additional features/capacity, but it wouldn't necessarily correct an asymmetric return path.

The next thing I would check is the source IP address of the Meraki health-check packet as Azure sees it.

If the MHC traffic enters Azure with a source address that isn't included in the Meraki site's configured Local Network Gateway address prefixes, Azure may not have a route back to that source through the VPN tunnel. That would fit your observation: outbound probe visible, but no response returning.

If you already have a packet capture, please check the packet reaching Azure and provide:

Source IP:

Destination IP: 142.250.138.102

Destination port: TCP/80

Also check the effective routes on one of the Azure VM NICs. We specifically want to confirm whether Azure has a route for the MHC source subnet with the next hop pointing toward the Virtual Network Gateway.

One other important distinction: successful Internet access from an Azure VM doesn't necessarily prove the MHC return path is correct. The VM traffic originates from an Azure VNet address, while the Meraki probe originates on the other side of the VPN and must have a valid symmetric route back through the tunnel.

So yes, I think it's worth continuing with the Basic SKU for now. I wouldn't upgrade the VPN gateway specifically to troubleshoot this until we confirm the MHC source address and Azure's return route.

Please "Accept the Answer" if this information helped you. This will help us and others in the community.

Answer 2

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

Answer 3

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

Answer 4

Allan:

The Meraki Health Check (MHC) actually uses google.com, 142.250.138.102 should resolve to google.com. BTW the MHC fails no matter what FDQN I use. My understanding is that the MHC intentionally uses the tunnel as a way to measure its "connection" status; if the MHC fails, the Meraki should automatically switch its uplink to the other WAN port.

I know, from my open case with Meraki, the Health Check is going out, but no traffic is being returned (using port 80). This is what I'm trying to determine, what is blocking the "return".

Below, you'll see the outputs for the addressing questions you asked. In terms of VMs in the Azure VNET, yes there are Windows VMs. I connect to them daily via RDP, using 10.1.0.0/16 addresses (from my subnet 192.168.0.0/24). From these VM's, we are able to use port 80/443, both incoming and outgoing.

I'm appreciative of your efforts here, but I think this may be a futile attempt to solve something that is likely not possible with the Basic SKU. Once we have some development finished, we will likely upgrade the VNWG to the next up SKU, which I believe will be VpnGw1AZ. If you think we can solve this puzzle, one way or the other, using our current Basic SKU I'm willing to continue this. I'll let you make this call.

Again, thank you!

Steve Griffin

AzureVNETAddressing