Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- About NordOps
NordOps
Getting noticed
Member since Jan 29, 2018
06-06-2023
Community Record
26
Posts
33
Kudos
0
Solutions
Badges
01-26-2023
01:12 PM
Thank you @PhilipDAth, really appreciate the response. I thought so too but it's always good to see if others are seeing the same thing!
... View more
01-26-2023
12:55 PM
I am sorry if this has been posted before, we're seeing this error on multiple Azure vMX's, multiple regions. I've checked and there are no outbound firewall rules applied. I am not sure 100% how these tests are performed but is anyone else seeing the same issue? I'd like to make sure the vMX's we manage aren't going to be impacted by back end changes but I am not sure what else to try on the Azure side if it is as Cisco says a Azure issue. This is the error on the dash: Our automated tests show that you have one or more Meraki devices unable to reach our platform on IP address ranges 216.157.128.0/20 and 158.115.128.0/19. After January 28, 2023 our platform may begin using these address ranges for connectivity. Some of your devices will have a degraded experience after this time, unless upstream firewall rules are changed. You can view devices that are failing connectivity tests in the “Firewall Test Failures” section on the Firewall info page. For more information, please review our documentation. Last update on a Support case says that , "Upon further investigation, I have pushed the case over to our development team as the vMX is displaying unexpected behavior. However, production should not be hindered by the issue at hand. Functionality should remain consistent and unbothered. As of now, we have an internal case between me and our development team. Once we have a solution, this will be pushed and you will be alerted. If you have any further questions please reach out!" The Case number is 09135628 I am not sure if that means the testing won't impact the vMX but there are still issues or if it's just a false positive (this test and alert) so would like to check with the community if others are seeing that on their Azure vMX's?
... View more
10-24-2022
11:00 AM
3 Kudos
I should have updated the thread - case 08784236, support responded. The file is benign and Security Center is reporting a Retrospective Malware Detection of wsasme.exe. So it is indeed a false positive
... View more
10-24-2022
06:44 AM
1 Kudo
We're seeing a lot of these as well.
... View more
07-26-2022
02:06 PM
Thanks for the feedback. Some of the webroot documentation seems to point to that URL so I think it's just an AMP update that flagged the files disposition as malicious or maybe it didn't like that the computers were trying to run executables from a website.
... View more
07-26-2022
01:54 PM
1 Kudo
We're seeing the same thing on multiple networks, I started a case with Meraki support and also started a post. I am not sure if there is a way to Merge them. https://community.meraki.com/t5/Security-SD-WAN/Webroot-AMP/m-p/155472#M39074
... View more
07-26-2022
01:39 PM
2 Kudos
Any Webroot users out there seeing issues with AMP? We've received new information from the Advanced Malware Protection (AMP) cloud about 1 file downloaded on your The following files were determined to be malicious in retrospect: File Hash: 54fd619d136646c014ca6e270e4a483dce033894c918a462b5a0352290ce95db (link) Download Info: The AMP alert shows a wsasme.exe file on webroot's site. I opened a case to see if its a false positive but we've had a few customers that got flagged around the same time.
... View more
05-05-2022
07:22 AM
Yeah, I just find it surprising they haven't extended End of Support (not End of Sale) with a lead time on an MX67 being about 8 months.
... View more
05-03-2022
01:38 PM
It's official which is kind of surprising given the fact the lead time is so terrible for the MX67 https://documentation.meraki.com/General_Administration/Other_Topics/Meraki_End-of-Life_(EOL)_Products_and_Dates
... View more
03-11-2022
12:57 PM
We just had a couple customers that called in having problems to specbooks.com Nslookup reveals Non-authoritative answer: Name: specbooks.com Address: 74.208.210.187 Aliases: www.specbooks.com This tool classifies that IP block as Russian https://www.maxmind.com/en/geoip-demo Other tools do not NetRange: 74.208.0.0 - 74.208.255.255
CIDR: 74.208.0.0/16
NetName: 1AN1-NETWORK
NetHandle: NET-74-208-0-0-1
Parent: NET74 (NET-74-0-0-0-0)
NetType: Direct Allocation
OriginAS: AS8560
Organization: IONOS Inc. (11INT)
RegDate: 2006-11-22
Updated: 2017-08-09 Anyone experience false positives with the geo filtering? Would be nice to have the Content Filtering take priority over the Geo-Filtering but wondering if anyone else is having problems with it today. This seems to have just started today.
... View more
09-24-2021
10:10 AM
7 Kudos
Just adding feedback based on some of the comments from other users here about how to improve things so they could be identified easier in terms of using the geo filtering. Allow geo blocking with the ability to add a site or IP to the "allow" even though the rest of a country is denied. That way it's not all or nothing if there is legitimate traffic in a country you want to block. geo blocking dumps should dump to the event log like content filtering and malware so it can easily be identified. The ability to sync geo rules / firewall rules throughout the organization with Configuration sync would be nice. Maybe 3 can be done through the API's but I haven't played with that yet.
... View more
09-24-2021
06:56 AM
4 Kudos
Just a suggestion or "making a wish". If we could add something to the whitelist that overrides the geo filtering that would be a super useful feature. Block a country but allow this website would be a huge enhancement for security too.
... View more
08-06-2021
05:59 AM
2 Kudos
One other suggestion. This isn't the first time there has been a backend cloud issue and when you call in and wait on hold forever it doesn't help anyone's patience. It might go a long way to announce an issue like this before putting the call into the support que. Being able to call Meraki support easily is one of the best features, but being on hold for 45 minutes waiting to talk to someone while back end issues are being worked on by engineers is extremely frustrating.
... View more
04-09-2019
07:30 PM
It's a better design to use Azure DNS anyways because of cloud availability vs. relying on and old server onsite so that makes sense. If you remove the DNS from powershell, the windows PC should just follow normal networking rules and grab the DNS from whatever you specify on the vMX100. There must be something up with your powershell script if it keeps assigning the onsite DNS server or maybe you have it defined and or hard-coded on the NIC? The vMX100 should be assigning the onsite one, maybe try setting up the VPN client manually instead of using powershell as a test and see if you get different behavior.
... View more
04-09-2019
07:04 PM
Are you using Azure Server DNS or back to your onsite DNS server? The internal Azure DNS should just work. If it isn't can you ping that address? If you can ping it then you might be looking at the issue I had originally with the regedit. If you can't ping it maybe it's the Azure routing tables. If you're using your onsite DNS server you need to also allow that local traffic back to the meraki when you're split tunneling. On powershelll I think you'd need to add another destination. In this scenario lets just say 192.168.128.0/24 is Azure and 192.168.100.0/24 is your old network with your onsite DNS server. You'd need to route both private networks back to the vMX100. Hope that makes sense. $Destination = "192.168.128.0/24" Add-Vpnconnectionroute -Connectionname $ConnectionName -DestinationPrefix $Destination $Destination = "192.168.100.0/24" Add-Vpnconnectionroute -Connectionname $ConnectionName -DestinationPrefix $Destination
... View more
04-09-2019
06:44 PM
@PhilipDAth that's what's worked for me in the past. Just let the vMX100 assign it vs. the poweshell script.
... View more
04-09-2019
06:02 PM
Can you specify on the vMX100? Security & SD-WAN > Client VPN > "Custom nameservers" and enter IP of local DNS server?
... View more
04-09-2019
05:30 PM
Just a though - why not put a DNS server in Azure and assign it dynamically under "Custom nameservers" instead of trying to distribute DNS via powershell? Alternatively you could just use an existing internal DNS server and dynamically assign it as long as your client can get from the Meraki back to that internal DNS server that already exists. That should work assuming you have an MX or something in-front of the non-cloud internal DNS server onsite and it's reachable over VPN. The first option is probably better because it wouldn't require that link to be up but I think either would work.
... View more
04-09-2019
05:24 PM
You're right about Azure, based on what I've seen they currently don't want you sending the internet traffic back over the link so it doesn't NAT outbound for remote traffic. They might have allowed it in the early days with the vMX when there was more than one interface but it doesn't look like an option now.
... View more
03-28-2019
06:50 PM
This has worked pretty well for us, maybe someone will jump in and offer more options. You need to use your server address for public IP, connection name VPN whatever you want, the pre-shared key from the MX setup and the local network is the destination. I am not sure why more people haven't shared, maybe they're holding out for Meraki to make an SSL VPN client or something more simple to deploy. If anyone has any good group policy deployment guides with powerhsell scripts specific to the Meraki VPN and would share that would be great.... You need to copy and paste this as admin in poweshell after you've adjusted for your own network Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\PolicyAgent AssumeUDPEncapsulationContextOnSendRule -Type DWord -Value 2 -Force $ServerAddress = "x.x.x.x" $ConnectionName = "VPN" $PresharedKey = "presharedkey" $Destination = "192.168.128.0/24" Add-VpnConnection -Name "$ConnectionName" -ServerAddress "$ServerAddress" -TunnelType L2tp -L2tpPsk "$PresharedKey" -AuthenticationMethod Pap -Force Set-VpnConnection -Name $ConnectionName -SplitTunneling $True Add-Vpnconnectionroute -Connectionname $ConnectionName -DestinationPrefix $Destination
... View more
12-17-2018
06:20 PM
11 Kudos
We've found it useful to just allow certain countries rather than deny a huge list.
... View more
11-12-2018
06:26 AM
Progress, I can now connect! I can also connect locally to hosts on the Azure environment, but my internet is not working. A trace reveals second hop to be a public IP but can't get past it. I think I read something about Azure not allowing outbound internet traffic from VPN clients, so I'll manually add routes to bypass the default behavior of full tunnel and see if that works...will update after testing is complete.
... View more
11-07-2018
06:53 PM
I have a vMX100 setup in Azure and have site to site VPN's successfully working. We have a number of MX64's passing auto VPN traffic just fine. The Windows VPN client just doesn't work. I get prompted for a username and password but it is almost as if UDP 500 or UDP 4500 is being blocked on the Azure side. I've seen a bunch of posts saying that VPN can connect but can't pass traffic but I can't even seem to get that far. Anyone have any advice? Does anything need to be opened on the Azure side? I routed traffic back to the next hop for the VPN traffic, but like I said we aren't even getting that far. I get prompted for a username and password but it is almost like the local authentication on the Meraki is failing. This is the error I get from a windows 10 PC. Running a packet sniffer while trying to connect I see 192.168.128.4.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E] In the event logs I am seeing something like this which seems pretty odd. msg: received broken Microsoft ID: MS NT5 ISAKMPOAKLEY If anyone has any ideas it would be greatly appreciated!
... View more
07-23-2018
07:35 PM
Thanks for this info, I noticed you referenced your case below. I gave that to support since they haven't been of much help. What I've noticed (Site to Site to vShield VMware firewall) with third party VPN - Internet on both sides up - Third party firewall is in a private cloud with multiple carriers - Meraki Auto-VPN's don't drop - I can kick the tunnel off by booting the Meraki - It recovers on its own after about 8 minutes - Event logs always have "Non-Meraki / Client VPN negotiation msg: phase1 negotiation failed due to time up" but nothing really useful. Thanks for referencing your case I hope that helps and they dig something up
... View more
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 11 | 26612 | |
| 7 | 27300 | |
| 4 | 29661 | |
| 3 | 1035 | |
| 2 | 1476 |
