Meraki

Brash · ‎Aug 3 2022

Not that I'm aware of. What is the use case of blocking it based on IP address? DHCP works on layer 2 and therefore the responses to DHCP requests will be sent via MAC address.

Brash · ‎Aug 3 2022

I believe there's still no direct integration. Your options are to use Radius auth and have the radius server do the AAD lookup, or integrating with a vmx https://apicli.com/2021/12/13/meraki-mr-802-1x-with-azure-active-directory/

Brash · ‎Aug 2 2022

You're right - the ports I was seeing was devices connected to a switch. Weird that it would be different between website and app.

Brash · ‎Aug 2 2022

You can see this for clients in the dashboard if you hit the spanner button on the right hand side and add the "port" column.

Brash · ‎Jul 31 2022

Haven't had to raise a case lately, but normally that's how I would do it.

Brash · ‎Jul 31 2022

With no additional context, the routing logic seems fine. The only change I'd consider making is using a different vlan for AP management at the remote site and just trunking the transit vlan but that's more of a personal choice. You're getting successful pings because of the default route. The 350 will send unknown destination traffic to the 425, and the 425 has a 172.20.10.1 directly connected. Can't help you on the third one

Brash · ‎Jul 28 2022

There's some basic documentation on webhooks. Not sure if it's all syslog events or some dashboard alerts though: https://documentation.meraki.com/General_Administration/Other_Topics/Webhooks

Brash · ‎Jul 27 2022

You can definitely apply multiple one day licenses as that's how they're designed to be used. However Meraki explicitly notes that they're to be used to true up expirations for PDL, not to extend overall licensing expiration. As it's one device for 90 days, it will probably be fine if your licensing is set to PDL That said, I've never tried it myself.

Brash · ‎Jul 27 2022

I doubt there will be an 8 port Meraki mgig switch for a while as i can't imagine there's enough appetite for one just yet in SME. And as @KarstenI mentioned, now that Catalyst switches can be dashboard managed, it's more likely that an 8 port mgig cat9200 will fill the gap.

Brash · ‎Jul 27 2022

I could be wrong but I think the link above is for MS Azure SAML auth for dashboard. This seems to be one specifically for anyconnect: https://documentation.meraki.com/MX/Client_VPN/AnyConnect_on_the_MX_Appliance/AnyConnect_Azure_AD_SAML_Configuration

Brash · ‎Jul 22 2022

Congratulations and welcome @RaphaelL !! Very much deserved.

Brash · ‎Jul 20 2022

Welcome @AmyReyes and @Christopher_S !

Brash · ‎Jul 19 2022

That I'm not too sure as I've never tested it. I suspect there will be at least some reprogramming of the switch and therefore likely a halt in processing packets.

Brash · ‎Jul 19 2022

Deleting a device from the dashboard doesn't remove configuration from it. It would need to be factory reset in order for that to occur. If you're moving switches between networks in the same organisation, it's easier to simply use the move functionality. https://documentation.meraki.com/General_Administration/Inventory_and_Devices/Moving_Devices_between_Networks#MS_Switches

Brash · ‎Jul 17 2022

TFTP is not a great protocol for over-the-internet transfers. You're much better off using FTP (or even better, SFTP) TFTP uses port UDP 69 for initial contact. However, the transfer itself takes place completely on ephemeral ports. From the packet flows provided, we see the initial communication from LAN client to WAN server with destination port UDP 69, and source port of 57357. We then see the TFTP server respond with an ephemeral source port of its choosing (in this case 40000) and destination port 57357 for the initial communication and transfer setup. This is expected as per the RFC. As this flow from server to client does not match the stateful flow that the MX has seen (as its expecting to see a source port of 69), the packets are dropped as expected. If you want to do some advanced reading, check out RFC 1350: The TFTP Protocol (Revision 2) (rfc-editor.org) Specifically, section 4 - Initial Connection Protocol.

Brash · ‎Jul 16 2022

I've never had the need to implement it but I've heard people have had success using unifi AirMax devices to work as point-to-point layer 2 bridges that support multiple vlans. There's also a number of other companies that offer higher cost enterprise grade devices which will perform point to point bridging. Meraki WAPs don't do layer 2 bridging. The closest they have is wireless mesh but that will only extend out SSID's, not form a full layer 2 trunk.

Brash · ‎Jul 13 2022

The Meraki firewall rules can't take effect because the user's traffic is being tunneled through the VPN. All the MX would see is traffic destined for the VPN provider. You'd be better off blocking the 3rd party VPN providers to prevent users from using them.

Brash · ‎Jul 13 2022

Welcome. To start off mate, your English is fine. For time limits of guests, the closest you can get to this is the guest ambassador feature. Other than that, there are 3rd party add on's / services which connect to Meraki and can provide additional guest management features

Brash · ‎Jul 11 2022

Yes, this seems to be a known issue at the moment. https://community.meraki.com/t5/Dashboard-Administration/Check-your-licenses/m-p/154075#M5693 Those on PDL have also recently been seeing erroneous expiry errors. https://community.meraki.com/t5/Dashboard-Administration/Your-Dashboard-organization-is-in-a-state-of-license-non/m-p/154362#M5717

Brash · ‎Jul 8 2022

Congratulations everyone.

Brash · ‎Jul 7 2022

The link should come up automatically. It sounds like you have a layer 1 issue. Are you sure you have the correct transceiver for the cable? And have you tried crossing the fibers to ensure that you don't have Tx to Tx and Rx to Rx?

Brash · ‎Jul 6 2022

It really depends what you mean by support. An MX will handle TLS encrypted traffic going through it like any other type of network traffic. In terms of Meraki device to cloud communication, it uses TLS1.2 https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Meraki_Device_to_Cloud_Connectivity_-_FIPS#Encryption

Brash · ‎Jul 6 2022

@ww was suggesting using the native vlan of 511 on the trunk port (as you specified in scenario one). Really, either will work. Scenario one is just slightly easier from a configuration management perspective.

Brash · ‎Jul 3 2022

I'm not aware of any way to disable ipv6 on the wan interface through the dashboard. Meraki support can probably disable it on the backend. Otherwise you should be able to ask your ISP to disable ipv6 on your service.

Brash · ‎Jun 30 2022

Permissions and privileges in the dashboard aren't that fine grained. Generally speaking, your options are read-only or full admin access. You can do some slightly more fine grained controls for individual networks within an org, or management of certain switch ports but that's about it. https://documentation.meraki.com/General_Administration/Managing_Dashboard_Access/Managing_Dashboard_Administrators_and_Permissions#Permissions_by_Network_Tag

About Brash

Brash

Community Record

Badges