Hi everyone, I’m seeing a very strange one-way performance issue after replacing an MX85 HA pair with an MX67 HA pair at one of our sites and would appreciate any hints or ideas what else to check. Environment Several sites connected via AutoVPN (mixture of hub/spoke). Each key site has an MX pair in HA, routed mode, behind an ISP router. MX WAN and LAN connect via a switch (WAN VLAN, LAN VLAN). One site (“Site A”) hosts a Windows file server. Another site (“Site B”) is a main hub and terminates Client VPN for home users. A third site (“Site C”) is another branch used for tests. At Site A, we replaced an MX85 HA pair with an MX67 HA pair. Configuration was kept essentially identical (networks, AutoVPN settings, no traffic shaping, no special QoS). Problem Since moving Site A to MX67, we see strongly asymmetric throughput over AutoVPN for any traffic involving Site A: From other sites / VPN clients to Site A: throughput is fine. From Site A to other sites / VPN clients: throughput is limited to about 0.5–1 Mbit/s. This affects: SMB access to file shares on the file server in Site A (Windows Explorer freezes when opening shares, files take ages or don’t open at all). RDP sessions that go through Site A (they lag badly and sometimes disconnect). Copying medium files (100–200 MB) from Site A to other sites is extremely slow, while copying in the opposite direction is OK. Latency looks fine: From Site B to the file server in Site A: ~25 ms, 0% loss (32-byte ping). From Site C (e.g. US) to Site A: ~100 ms, 0% loss (32-byte ping). Path MTU tests (ping with DF and increasing size): Between some sites we get “Packet needs to be fragmented” for larger packets; effective MTU on the path is ~1300–1350 bytes. Meraki support told me that: MTU on the MX67 in Site A is currently 1500. MTU on at least one remote uplink is 1492. They suggested reducing Site A MTU to 1492, which I plan to do. However, the performance issue feels too drastic to be “just MTU”, and the captures don’t show obvious fragmentation. iPerf3 measurements All tests are AutoVPN traffic involving Site A and run with iperf3 -P 4 -t 30. Remote user at home → Client VPN to Site B → AutoVPN to file server in Site A Client → Site A (iperf3 -c file-server): ~20–25 Mbit/s total. Site A → client (iperf3 -c file-server -R): ~0.5–1 Mbit/s total. On-prem PC in Site B LAN → AutoVPN to Site A Site B → Site A: ~80–100 Mbit/s. Site A → Site B (-R): ~0.5–1 Mbit/s. Third site (Site C) → AutoVPN to Site A Same pattern: one direction is tens of Mbit/s, the opposite direction is around 1 Mbit/s. So the problem is consistently: traffic originating from Site A towards the rest of the network is extremely slow, regardless of whether the other side is a branch, a hub, or a Client VPN user. What we already checked Switch ports where MX67 connects (WAN and LAN): Speed/duplex correct (1G/full), no CRC errors, no obvious interface errors, no link flaps. Config on the HA pair: Both MX67 units have effectively identical configuration. During some earlier tests, when we temporarily ran only one MX67 (no HA, maintenance situation), RDP felt noticeably faster; after bringing the HA pair back up, the very slow behaviour returned. So I’m not sure if HA plays a role here or it was just coincidence. There are no traffic shaping rules or per-tunnel limits configured on AutoVPN. No special QoS or SD-WAN policies that should cap bandwidth. Packet capture I captured traffic on the Site-to-Site VPN interface of the MX67 at Site A during iPerf tests. High-level observations: AutoVPN UDP encapsulation carries the iPerf TCP flows. TCP MSS on SYN/SYN-ACK is around 1386, which matches a reduced path MTU due to encapsulation. Most data packets are around 1426-byte IP payload and I don’t see IP fragmentation in the capture. I don’t see obvious massive retransmissions bursts that would explain such a hard ~1 Mbit/s ceiling, but I may be missing something. I can share sanitized PCAPs if needed. Question for the community Has anyone seen something like this: One specific MX67 HA site where AutoVPN throughput is fine in one direction and capped around 1 Mbit/s in the other, while latency and small-packet ping looks normal, switches show no errors, and the issue affects both site-to-site traffic and Client VPN users who reach that site through a hub? Any ideas what else I should check on: MX67 HA configuration (any known bugs or gotchas with HA and AutoVPN throughput)? MTU settings (would mismatched 1500/1492 on uplinks realistically cause this exact kind of one-way behaviour even when MSS looks sane)? Hidden counters/logs for queueing, drops, or shaper on the MX uplinks? Known issues with specific firmware versions on MX67 related to AutoVPN or asymmetric throughput? Any pointers or similar experiences would be very helpful. Thanks! ... View more