Meraki

PhilipDAth

This is working as designed, and it is not considered a vulnerability. 1:1 NAT mapping allows any host on any internal VLAN to access the mapped address. You might be able to restricy this by applying a group policy to the VLAN of the MX, and applyinging firewall rules in the group policy to prevent access.

PhilipDAth

Well done everyone. Always a big effort to make it onto this list.

PhilipDAth

Thanks for joining @Rolitto . The more the merrier.

PhilipDAth

>MX can 'monitor' eachother if they are up and still have route to Internet. They don't monitor each other when active/active. They are simply two standalone units. They need to be in seperate Meraki networks, and you need to use some kind of layer 3 device (such as a layer 3 switch) to manage the failover between each other.

PhilipDAth

Add the Windows Role "Microsoft NPS Server". It is a RADIUS server that comes with Windows Server. Use that for authentication.

PhilipDAth

If you have the Cisco Security Client on every machine, you can apply Umbrella policies inside of Umbrella to whatever users and groups you like. The bonus of this method is it works even when they are out of the office.

PhilipDAth

Well done everyone. What a lot of effort.

PhilipDAth

Configured a standard 1:1 NAT. The secret is this actually works between all interfaces, internal and external. The uplink isn't really a used field. https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/MX_Firewall_Settings#1:1_NAT

PhilipDAth

Attacking this using AnyConnect profiles is the wrong way to go. Instead have everyone else the same profile, but have the MX enforce different sets of firewall rules. If you are using RADIUS authentication, then use the Filter-Id atttribute to apply a group policy. https://documentation.meraki.com/MX/Client_VPN/AnyConnect_on_the_MX_Appliance#Group_Policies_with_RADIUS_Filter-ID If you are using SAML authentication (such as Entra ID) then push a SAML attribute. https://community.meraki.com/t5/Security-SD-WAN/AnyConnect-SAML-Group-Policy-assignment/m-p/247512/highlight/true#M55205 Then just create a group policy with layer 3 firewall rules for each group saying that they can access.

PhilipDAth

There are multiple ways to do this. If you are happy to manage this in Umbrella (rather than the Meraki Dashboard) , the way I would do this is to: * Deploy the Cisco Security Client (with the umbrella module) onto every machine. https://docs.umbrella.com/deployment-umbrella/docs/5-connect-active-directory-to-umbrella * Sync Umbrella with Active Directory. https://docs.umbrella.com/deployment-umbrella/docs/5-connect-active-directory-to-umbrella

PhilipDAth

It does not mean there has been a successful connection to your network.

PhilipDAth

This is a "normal" HTTPS scan you are seeing. It could be an attacker. It could be a search engine. It could even be Shodan. https://www.shodan.io/

PhilipDAth

Haha, Hello Disha! Thanks for joining the community.

PhilipDAth

789 is often caused by a bad ipsec key. Not all characters are valid for the IPSec key. Try making it simpler and work from there. Try using my client VPN script to configure the VPN. it adds some extra registry keys that overcomes some of the problems. https://ifm.net.nz/cookbooks/meraki-client-vpn.html

PhilipDAth

I've spent quite a bit of time trying to get BGP over IPSec working to both Amazon AWS VPN Gateway and a transit gateway. Both fail. IKEv2 comes up nicely. I can ping the tunnel at the AWS end from the MX, so I know all the crypto and tunnel is working. I opened a support case with Meraki, 12506739. But this new feature is beyond what they can diagnose. I don't suppose we could get developerment to look at getting this feature to work with Amazon AWS? I would guess there would be 100,000 Meraki customers with Amazon AWS to every 1 customer using Catalyst SD-WAN.

PhilipDAth

Try checking the upstream firewall to see if anything is reported as being blocked.

PhilipDAth

You can, but if the single L2 link fails, both will go master/master, so there is little redundancy. You might have to manually intervene during a failure and turn off one of the MXs (which is also an acceptable DR method if it is part of your plan). You could consider getting a pair of L2 circuits (ideally channelled together) for redundancy.

PhilipDAth

I guess you should also consider that VRRP is optional. A minimum of 2 IP addresses is mandatory (one of each MX). Also of note is that if you don't use VRRP that the IP addresses don't have to be from the same ISP circuit. You could use the primary circuit on the primary MX, and a cheap consumer grade Internet circuit for the secondary MX. ps. I only enable VRRP on about 25% of the installs tat I do.

PhilipDAth

You have both identified the issue. THere is only one way to remove this cosmetic issue, and it involves spending money. 🙂

PhilipDAth

Very interesting.

PhilipDAth

Yes.

PhilipDAth

This is an interesting new feature you have found. I suspect you'll need to be running the latest MX 19.x code for this to work.

PhilipDAth

What does your RADIUS server log say? Usually it will give a reason for a failure.

PhilipDAth

I *think* I have had my MX75 reboot once. It's hard to tell apart from jut a short Internet disruption.

PhilipDAth

If you have fewer than 50 sites you could consider running more of the sites as hubs to work around the issue.

About PhilipDAth

PhilipDAth

Philip D'Ath

Community Record

Badges