Meraki

alemabrahao

MR doesn’t have per AP tag bandwidth limits for a single SSID. If you must keep a single subnet and apply different per client caps based on AP tag, you’d need a policy engine that can evaluate AP location and apply per client limits accordingly. MR supports per user bandwidth via RADIUS attributes. If your guest flow uses RADIUS, you can return a bandwidth profile per user. That’s not per AP tag, but you could combine AP group logic in the RADIUS policy to assign different caps based on where they associate.

alemabrahao

Unfortunately, it is not possible to change the fields in Meraki's alert emails. Another way I see it is to send these messages to a syslog server, and on that server you can customize the alerts you want to receive.

alemabrahao

I advise you to conduct a site survey of your Wi-Fi network. You can also check if 802.1r and client load balancing are enabled and disable them to see the result.

alemabrahao

Your mistake is that you're limiting it by both client and SSID, and the rule only ignores what is configured per client.; try adjusting the SSID parameter.

alemabrahao

How did you test this?

alemabrahao

The availability of the 6 GHz band depends on your country/regulatory domain. If set to a region where it's not permitted, 6E options won't appear. Also, ensure your CW9166I is running a firmware version that supports 6E. Although the device is capable by design, very early versions might not expose the 6 GHz settings in the Dashboard.

alemabrahao

Could you please explain what the solution was, so that future members can refer to the resolution?

alemabrahao

These tunnels themselves don't require public IPs; they require bidirectional connectivity for IKE/IPsec (UDP 500/4500, ESP) between the MX and the peer. However, if I understand correctly, you're going to use the link from your main website for all the MXs. In my understanding, due to Meraki's limitations, this scenario won't work. What I suggest is that you try to simulate this, but I'm almost 100% certain that this scenario won't work. If you add an MX within the same network and try to connect via Client VPN, this already doesn't work and proves enough to understand that it won't work with an IPsec VPN.

alemabrahao

Unfortunately, this will not work.

alemabrahao

I'm not familiar with Sophos firewalls.

alemabrahao

You can use a link with a private IP address as long as you know the ISP's public IP address, because in the peering process you need to use the ISP's public IP address. In short, I assume you're saying the ISP provides you with CGNAT, correct? Yes, if the MX loses internet connection, the tunnels will go down, since the MX will lose communication with the Meraki cloud. I apologize if I'm misunderstanding what you're trying to do. If possible, please draw a simple topology for better understanding.

alemabrahao

I believe the block is in Sophos, since by default everything is allowed in Meraki.

alemabrahao

But I'll give you a better idea. If you have spare public addresses at the site where your HUB will be located, you can connect it in parallel to your network and make all the necessary configurations (routing, firewall, etc.). And as you replace the firewalls at the remote sites, you can add them to the auto VPN. In my view, this strategy is the smartest thing to do.

alemabrahao

You can use private addresses to configure the tunnels without any problem, as long as you have internet access. If the MX recorder loses internet access, the tunnels will consequently go down. It is possible to access the local status page via a private IP address.

alemabrahao

Probably you have some rule on the sophos that is not allowing the communication.

alemabrahao

Take a look at this article. https://austintcrider.wordpress.com/2019/03/06/sophos-utm-to-meraki-mx-site-to-site-vpn/

alemabrahao

I'd recommend rolling back one AP to see if the issue is isolate to the beta firmware.

alemabrahao

Meraki does not provide an option to manually adjust the beacon interval on their Wi-Fi access points, the beacon interval is fixed.

alemabrahao

Do you have any bandwidth control rules enabled on your network? Please provide us with any information that may be useful for a better analysis. For example, a simple network topology.

alemabrahao

Or instead of to use sponsored guest account use this configuration and configure the option for administration approvement. https://documentation.meraki.com/Wireless/Operate_and_Maintain/How_Tos/Splash_Page/Self-registration_for_Splash_User_Accounts#:~:text=Using%20a%20Sign%2Don%20Splash,deleted%20out%20of%20the%20Dashboard.

alemabrahao

If the administrators want only specific emails to have the authority, then the specified domain has to be a different domain for example "@merakiguestsponsor.net" with only a few emails on that domain like username@merakiguestsponsor.net that can be specified by guests to grant access to them.

alemabrahao

Try performing a factory reset please.

alemabrahao

It's very likely that this isn't connecting to the internet. Can you verify the IP address configured on the dashboard when it's set up as a repeater? Try performing a factory reset

alemabrahao

Do you have any other admins in the organization who can reset the password? It's advisable to always have at least two administrators in the organization. Good luck.

alemabrahao

@PhilipDAth , I was thinking, it's fine to work that way, but in this case, he's opening a security vulnerability. Exposing your host to the internet these days opens a very large vulnerability for a potential attacker. He's taking the risk, but I personally have to disagree with that approach. This business of working at any cost isn't my style; I prefer to assess the viability first and look at other options that offer less security risk. This kind of thing bothers me a bit in the community—giving a solution, but it's not always the best or safest one. I also make mistakes, but security is not something to be ignored.

About alemabrahao

alemabrahao

Alessandro Abrahao

Community Record

Badges