Ok, if this is indeed the case, Meraki needs to put a headline alert on every client's dashboard overview page or send out a mass email or something. I do find it curious that some random person coming from an IP in Poland the first round and now in Texas the second round is hitting numerous customers with at the exact same time with the exact same Zyxel unauthenticated IKEv2 command injection attempt  &  Zyxel unauthenticated IKEv2 overflow attempt alert. (I'm sure a lot more that just don't get on this community and report). ... View more

I have added to my original Meraki case about this issue 2 weeks ago with this new info, have not heard back yet..   From Snort site about this allowed action we are seeing.   Link to CVE listed on Zyxel site - https://www.cve.org/CVERecord?id=CVE-2023-28771   Makes no sense, is a public Zyxel firewall trying to access our Meraki MX's public WAN's..?   ... View more

Happened again, these IP's were allowed on (2) of my MX's external WAN IP's - 98.194.65.91:500; 98.195.67.12:500; 98.194.65.92:500   Zyxel unauthenticated IKEv2 command injection attempt   Zyxel unauthenticated IKEv2 overflow attempt   ... View more

I agree. I was the one that started this case last Tuesday and have been engaged with the community here and Meraki support ever since trying to determine what if anything malicious was allowed to access our MX public WAN's. Jess ... View more

Ok, thank you for the detailed response on this issue. ... View more

Latest from support on my case   Thank you for contacting Cisco Meraki Technical Support. We understand that you are having concerns over your MX being compromised, but after looking over some backend logs you should not worry about your MX being compromised. We could see that the alert was identified as malicious traffic, but it was dropped afterwards because it was no longer present. This caused dashboard to show the event as allowed. However, you should not have any issues with a breach on your Client VPN. If you're still experiencing issues feel free to reach back to us. ... View more

At this point I am just leaving VPN enabled, I tried layer3 outbound rule to deny any traffic within the VPN subnet as a precaution, but it's then pointless to enable VPN again since user can't access internet, shared drives, etc. ... View more

So I just tested connecting to VPN, as soon as I connected my internet went to blocked and I could not Remote Desktop into my work computer, so back to square one, I will need to remove that layer3 deny for the VPN subnet if I want to leave VPN enabled. ... View more

Ok, thanks for confirming that. One thing I did find out after adding the layer3 rule is that when I connect to our VPN over my phone to access my security cameras that was blocked until I removed the rule. Which does go along with what you were talking about as the cameras are on a separate internal subnet. So at least if a bad actor did connect to our VPN, they wouldn’t be able to attempt to access any of our internal computers or servers, which is a good thing. Thanks ... View more

So even though you left the VPN enabled, adding that layer3 rule to deny any internet traffic on your VPN subnet, won’t users that connect to VPN not be able to get to the Internet then? ... View more

From support:  We understand that you are expecting issues with 95.214.52.173 on port 500. However, there has been a recent update on the IDS/IPS ruleset and an improvement in terms of coverage and detection efficacy is expected. As result, certain traffic that before would not trigger an alert may now result in one.   that’s all fine and good but still doesn’t explain how an unauthenticated attempt from a foreign IP was allowed.. ... View more

How did you create a layer3 rule to isolate the VPN subnet? Thanks  ... View more

I'm seeing alerts like this from an internal Windows 10 PC, no clue what Destination 255.255.255.255:5093 means..logs it ever hour   ... View more

Ok, but support still needs to give an explanation of alerts like these, did an unauthenticated user get access to our external WAN IP's. I have my VPN disabled for now as a precaution but remote users are barking about when I can re-enable. ... View more

I'm throwing everything at the wall, added this layer 7 rule, IP source in my issue showed from Poland, but I added some other countries too..random I know but I figured why not. ... View more

I've seen those before, but so far they have always shown blocked not allowed. Support definitely needs to escalate this issue as it's starting to affect more and more customers. Are they false positives or actual allowed attacks.. ... View more

Anyone else got any feedback from Meraki support, having VPN disabled is not ideal of course, remote users are barking. ... View more

Yes we do have VPN enabled on 2 of 4 of our MX's. I have disabled for now as well, good idea on that. ... View more

As far as gaining access via our external public IP's, with a strong password and 2FA on our Meraki MX's don't see how they could have authenticated successfully. Also I checked logs for any rogue VPN connections from the IP in question at the time of the alert, not finding anything.. ... View more

Thank you for contacting Cisco Meraki Technical Support.  We understand that you are obtaining traffic from that source IP and you would like this IP blocked from accessing your MX. In order to do this you will have to go to Security & SD-WAN and go to Security Center. Here you will be able to go to MX Events, and then here in this page you will be able to see the IDS alert that you received. If you were to click where it says "Zyxel unauthenticated IKEv2 overflow attempt", here you will be able to disable whitelist. After doing this you will no longer see this allowed. If you're still experiencing issues feel free to reach back to us.   My response:The whitelist on this Zyxel event is already set to Off, so of course I would not want to set to On to whitelist (allow). The issue is Meraki IDS allowed in the first place instead of blocking. ... View more

So I sent support the times the IP was allowed, their response doesn't really address why it was allowed since it's a pretty high threat on Virus Total. I even added under Content Categories to Block; Regional Restricted Sites for all the ones available, Great Britain, Italy, Germany, Poland (IP 95.214.52.173 looked to come from Poland) ... View more

From Meraki Support:   Thank you for contacting Cisco Meraki Technical Support! We understand that you are having issues with the source IP 95.214.52.173. However, would you be able to tell us when you saw this IP on your Firewall's external WAN IP's. In addition, by you adding it to your URL block list the firewall will block the traffic coming from outside to your MX. Therefore, if a device with that IP address is trying to access your MX it will be blocked. Now if there is a device in your network that is trying to access that IP they will be able to since, the MX blocks traffic coming in not going out. ... View more

Ok, so the exact same IP address and Zyxel under details? No haven’t heard back yet.   ... View more

Still waiting to hear back from Meraki Support on this. Virus Total has 10 hits on the IP, so now sure how Action was allowed via IDS. Since attempts were at our MX firewall external WAN IP's not sure what damage could be done..   please advise. thanks   ... View more

Ok. Yes I did open a case this morning about it. thanks for your input ... View more