Auto VPN issues

[ArjunRajeev]

Hello,

Is there any information regarding known issues related to MX 18.107.2 that might be impacting Auto-VPN connectivity? We have a customer with three locations, all running MX 18.107.2, and Auto-VPN is enabled between these sites.

We have been receiving a high volume of alerts related to VPN connectivity changes. Upon reviewing the event logs, I observed VPN flapped logs at one of the sites. Interestingly, the site it is peering with does not show any VPN logs during the same timeframe.

Additionally, we are collaborating with the ISP to investigate if they detect any issues on the circuit. The Meraki TAC team suggested that excessive load on the VPN registry might be the cause and manually changed it to a different registry.

[alemabrahao]

I recommend you try another version.

Known issues  firmware versions MX 18.107.2

• After making some configuration changes on MX84 appliances, a brief period of packet loss may occur. This will affect all MX84 appliances on all MX firmware versions
• Due to an MX 15 regression, the management port on MX84 appliances does not provide access to the local status page
• MX appliances will now properly validate that DBD packets conform to the appropriate MTU size. If the MX's OSPF peer has an improper MTU configured, it may cause the OSPF adjacency to fail to properly form. The updated behavior properly conforms to RFC. Please ensure these settings are properly configured on any MX's OSPF peers to avoid disruption after upgrading to MX 18.1.X.
• AutoVPN tunnels may briefly drop and re-establish after configuration or WAN connectivity changes if 1) the MX is configured in high availability (HA) mode and 2) both AutoVPN peers are running MX 18. This issue is actively being investigated.
• AutoVPN transmissions between peers which are running firmware versions 18.1 and later will consume an additional 4 bytes of overhead, totaling up to 68 bytes.
• In very rare circumstances, MX appliances may report the incorrect interface IP address to the VPN registry. In some circumstances, this can interfere with the proper functioning of AutoVPN and teleworker VPN tunnels.
• MX appliances with content filtering enabled may encounter unexpected device reboots. This is more likely to occur if it has been a long time since the MX appliance was last rebooted.
• MX appliances may encounter latency issues when 1) the appliance is configured in high availability, 2) the appliance is acting as an AutoVPN hub, and 3) IPv6 traffic is traversing AutoVPN. The likelihood of encountering this issue may increase as more time passes since the MX was last rebooted.
• There may be a brief disruption of network traffic when an MX appliance's IPv6 address information for a WAN interface is updated.
• MX appliances may not failover to a backup cellular connection after the WAN interfaces have been disabled from Dashboard.
• MX95, MX105, MX250, and MX450 appliances will incorrectly forward untagged traffic when the ports are configured to drop untagged traffic
• In rare circumstances, there may be excessive device utilization when intrusion detection or prevention are enabled.
• MX67W and MX68(W,CW) appliances may experience unexpected device reboots for reasons currently under investigation. A potential cause may be oversized wireless packets.
• MX64W and MX65W will erroneously drop wireless, intra-vlan broadcast traffic. This issue is most likely to manifest as DHCP failures or clients being unable to successfully ARP for other devices within their subnet.
• In very rare cases, MX appliances on MX 18.1XX may periodically drop AutoVPN and teleworker VPN connections to devices on older firmware versions.
• In rare circumstances the intrusion detection and prevention process may crash and restart. In some circumstances this can cause a minor disruption to network traffic. This issue is expected to be resolved through an update to the IDS/IPS container rather than the MX firmware version.
• In rare cases, the AnyConnect VPN process may crash when tearing down old, unused tunnels.
• Some on-device debugging information may not be cleared after a factory reset.
• MX appliances configured in high availability will incorrectly use their WAN interface IP address for establishing EBGP sessions when a VIP is configured.
• Clients using an older version of the AnyConnect client may not be able to successfully perform Duo multi-factor authentication. This can be resolved by updating the AnyConnect client to 4.10.05085 or higher.
• Due to an MX 17.10.4 regression, the WAN 1 port may be incorrectly set as disabled when making changes via the device local status page.
• Due to unknown reasons, MX64W and MX65W may experience unexpected device reboots. This is most likely related to the wireless subsystem.
• Due to a rare issue with no known method of reproduction, MX appliances have been documented to fail to fetch an updated device configuration for several days.
• MX appliances may fail to free IP addresses from the client VPN subnet pool after IPsec client VPN clients disconnect.
• In rare cases, MX67(C,W) and MX68(W,CW), MX75, MX85, MX95, and MX105 appliances with intrusion prevention configured may erroneously block SIP traffic from client VPN clients. This is most likely related to an issue with IP fragmentation and reassembly.
• In rare cases, MX67(C,W) and MX68(W,CW), MX75, MX85, MX95, and MX105 appliances with intrusion prevention configured may result in increased latency for Citrix. This may be related to an issue with IP fragmentation and reassembly.
• NBAR may prematurely reach its peak capacity for the amount of concurrent flows that it can track. When this happens, the classification of traffic may be less accurate.
• Due to a rare issue under investigation, MX67C and MX68CW appliances may unexpectedly fail to detect some working SIM cards.
• MX95 and MX105 appliances incorrectly forward LLDP and CDP messages.
• In rare cases, large numbers of routes can cause network instability during AutoVPN connectivity changes.
• In rare cases, MX67C, MX68CW, and Z3C appliances may fail to enter into a "Ready" state despite being able to register to a cellular network and obtain an IP address for the modem.
• The default AnyConnect group policy may not be applied consistently, depending on the username’s case/capitalization.
• MXs appliances incorrectly modify the source IP address of ICMP time-to-live exceeded messages when routing them between VLANs.
• MX67W and MX68(W,CW) appliances may experience a crash of the wireless subsystem that results in a device reboot.
• Due to architectural changes to support content filtering powered by Talos, MX devices will no longer report the category that caused a URL to be blocked by content filtering when in full list mode.
• In rare cases, MX appliances may report severely incorrectly data for the loss and latency graphs visible on the Appliance Status page.
• Due to a rare issue with no known method of reproduction, MX95, MX105, MX250, and MX450 appliances may encounter unexpected device reboots.

[cmr]

@ArjunRajeev changing the registry has fixed these kind of issues before, has it made a difference in your logs?  There are several patches for 18.107.2, the latest being .6 and it might be worth looking into that.  We have 18.107.5 running on most of our MXs and rolled back 18.205 on an MX dues to issues, but a Z3 seems okay.  Our main datacentre is still running 17.10.2 due to a number of issues noted where both peers are 18.107 versions...