I need to fix about 20 clients have issues passing PCI due to the client VPN. It appears that 15.42 firmware fixes this issue. It automatically pushed to a MX84 I have but not to any of the MX80 or MX100. It looks like I can push it by using a RC/Beta option but wanted to see if anyone here has noticed any side effects from doing this.
even if you push 15 or 16(would not recommend 16) firmware.
mx 80 will still only run at MX 14.x firmware.
for mx100 it should work fine. just check the release notes for bugs, if there any relevant to you.
I saw that. It says it will use 14.55. Do you know if 15 is in the process of being able to run on these. Just curious because if not I have to call into support to have them correct DH settings.
Not a fun call when it needs to be done for around 20 clients.
@Jwiley78 : Below is the post when pushed MX15.42. Check and do accordingly.
You mention client VPN.
First, you need to configure the client VPN to support AES and Group 14. I have written a wizard for generating a script to configure the client VPN to do this. Just tick the "PCI Compliant" button.
You also have to raise a support ticket to get Meraki to turn it on for your MX as well.
Also note the options are mutually exclusive. If Meraki enable Group 14, and the client is not configured for it (like with my script above) the client will no longer be able to connect. Likewise, if you configure the client to use group 14, it won't be able to connect to the MX (or any other MX) until it has been updated.
So it is completely one way or the other.
Going sideways, the MX84 and MX100 (not MX80) support 16.x firmware (currently in public beta). This supports Cisco AnyConnect, which is much better in every regard.
I am specifically posting my experience with Meraki Support and Meraki latest "Stable" release 15.42.1
I upgraded our "X network" MX box on this sunday at 4.30pm PST.
To start with, it's been a very poor code quality since Meraki released 15.42 and 15.42.1.
Taking some packet captures, revealed that there is connectivity and routing issues between Site-to-Site Meraki peers, so while on one location client VPN, you cannot access the resources of the another location, there are intermittent packet loss.
Since the same day we started experiencing the connectivity issues in our Client VPN. These are the behaviours.
1). I connect to our "X network" client VPN on Meraki. Connects fine. Then within one minute the VPN disconnects automatically with no error message nothing.
2). I connect to our "X network" client VPN. Connects fine. No internet works on the VPN, internal and external. I can see packets going out, but no return traffic.
3). I connect to our "X network" client VPN. Connects fine. Internal traffic does not work, external traffic works.
4). I try to connect to our "X network" client VPN. It gives me Authentication failed for the same exact credentials that are saved in my VPN profile which was previously authenticating without any issues.
I have downgraded the "X network" MX box on 14.53, and now everything works fine. This happened on both 15.42 and 15.42.1.
Here is a sneak peak of other blogs of users facing similar issues - https://www.reddit.com/r/meraki/comments/n5hygl/mx_15421_breaks_routing_somehow/
Last but not the least - I have been on support hotline for about 40 Mins now, but no takers of my call. Kudos!
@nsingh this community is not like most on the internet. We try to help each other rather than just spamming the same negative post across multiple threads.
I totally understand your frustration about the client VPN issues you've had with 15.42, but they don't seem to affect most people and there is a requirement to make sure the remote and local IDs are properly matched now. Most IKEv2 VPN servers have needed this to be down for years (Sophos etc.) so please do try that and it may fix one (or more) of your issues. I'm sure we can help fix the others with our usual spirit of collaboration 🙂
@cmr - I totally agree and respect it.
However, it's not frustration but its honest awareness that I wanted to bring out amongst all the Meraki users that we have been dealing from past few months, it's not about a day or two.
Also, the site to site that I am mentioning is Meraki Site to site peer, not the Non-Meraki peers which need the local IDs 😊
@nsingh even more interesting, we have a WAN with 11 sites, all connected by MX autoVPN running 15.42 or 16.6. we don't have any drops or packet loss (we do monitor it 24/7 so we would know).
When you upgraded one MX to 15.42 did it then have random packet loss drops etc. to all the other MXs or is it setup as a spoke?
We have a VPN concentrator pair in the main DC as a hub, 7 HA pairs as hubs and 3 single MXs as spokes connecting to the first hub. All the HA pairs have at least 2 WAN connections, the spokes are single connected.
We have used 15.x for almost two years so far since it was an early beta.
@cmr - We have a very simple hub setup on 3 DC , however we are not using VPN concentrator, we are using Routed mode. Two pairs have single WAN connection and the other has 2 WAN connections.
When I upgraded one MX to 15.42.1/15.42 it had random packet loss drops etc. to all the other MXs from the "Client VPN"
Client VPN is the key issue for us. That is when I see the 4 behaviours I mentioned before.
But looks like no one is nearly using Meraki client VPN as we do, so it's very uncommon for others.
@nsingh ah okay, so you see the packet loss when connected through the client VPN and trying to access other AutoVPN connected sites.
We wouldn't have seen that as we don't use the Meraki client VPN at the moment, sorry I thought you simply had packet loss from one hub to another as well.
I haven't had anyone reporting any issues when using the L2TP over IPSec client built into Windows 10. We are moving about one customer a week to 16.x and changing over to AnyConnect. None of them has had issues either.
One thing we do (which makes all VPNs more reliable) is to make sure all MXs have a public IP directly on their WAN port, rather than putting them behind something else doing NAT (like an ISP router).
@PhilipDAth - Unfortunately, because of all our client VPN issues, we are moving slowly to F5 VPN now. The main purpose of the 15.x upgrade was IKEv2 since it was a blocker for many of our cloud integrations.
And thats a great tip to use the ISP directly on the WAN port, which we have setup in the same way.