Meraki

alemabrahao

What Radius server are you using?

alemabrahao

This prefix is typically added by the server during the authentication process, not by the Meraki dashboard itself.

alemabrahao

The logs that MX provides are very limited, the best no-cost option is to send the logs to a Syslog server. https://documentation.meraki.com/General_Administration/Monitoring_and_Reporting/Syslog_Server_Overview_and_Configuration https://documentation.meraki.com/General_Administration/Monitoring_and_Reporting/Meraki_Device_Reporting_-_Syslog%2C_SNMP%2C_and_API

alemabrahao

For you to be able to delete via API, as far as I remember, the user has to be active, so you can delete it. So in your script you will first have to enable the user and then be able to delete it.

alemabrahao

And how are you so sure that the APs that don't have the TAG are transmitting the SSID? Did you go to the location and see the SSID being transitioned? Do you go to the AP status page?

alemabrahao

Additionally, you need to create a link VLAN on the switch and configure two switch ports for access mode in this VLAN (one for each MX). And then select a port from each MX and configure it in access mode on that same VLAN and connect to the switch. Now you have a link network.

alemabrahao

This is the basics of routing. You don't need to use source based route. For example, let's assume you have the 192.168.10.0/24 network on MX1 and the 192.168.20.0/24 network on MX2. The first thing is to create a link vlan on both MXs, for example the 10.10.10.0/30 network (VLAN 99) where MX1 will have IP 10.10.10.1 and MX2 will have IP 10.10.10.2. If MX1 wants to reach MX2's network, just create a route pointing to the link IP of MX2 as the next hop. So it would look like this, to reach the network 192.168.20.0/24 the next hop is IP 10.10.10.2 Very simple, for the MX2 just do it in reverse, to get to the 192.168.10.0/24 network the next hop is 10.10.10.1

alemabrahao

Any application exposed to the internet is a risk, I can say that it is a little better, but at least ensure that all system patches are up to date. And think about investing in a WAF solution in the near future. One option is to host your website on AWS and use their WAF solution.

alemabrahao

Allow access only via client VPN or only allow IPs from a specific origin.

alemabrahao

Honestly, this is a huge security flaw, especially since you are allowing any origin. To expose your website you should have at least one WAF solution.

alemabrahao

Theoretically, that should be enough.

alemabrahao

You need to configure the switch port in trunk mode by tagging VLAN 20 instead of access mode.

alemabrahao

See the ports and addresses you need to allow to communicate with the cloud. https://documentation.meraki.com/General_Administration/Other_Topics/Upstream_Firewall_Rules_for_Cloud_Connectivity

alemabrahao

To use VLAN 20, did you configure the port to which the AP is connected in Trunk mode? Can you share the switch port settings and SSID settings?

alemabrahao

The VPN tunnel is established. The Cisco Meraki cloud already knows VLAN and subnet information for each MX, and now, the IP addresses to use for tunnel creation. The dashboard and MXs establish two 16-character pre-shared keys (one per direction) and create a 128- bit AES-CBC tunnel. Meraki Auto VPN leverages elements of modern IPSec (IKEv2, DiffeHellman and SHA256) to ensure tunnel confidentiality and integrity. Local subnets specified in the dashboard by admins are exported across the VPN meraki_whitepaper_autovpn.pdf (cisco.com)

alemabrahao

Auto VPN vs Non-Meraki Site-to-Site VPN Auto VPN is a VPN connection between/among the WAN Appliances in different networks of the same Meraki dashboard organization. Non-Meraki site-to-site VPN is used when you form a VPN tunnel with a third-party/non-Meraki device or when you establish a VPN connection with a Meraki WAN Appliance in a different dashboard organization. Like Non-Meraki Site-to-Site VPN, Auto VPN has encryption, authentication and a key. The traffic is encrypted using an AES cipher. However, all of this is transparent to users and does not need to be (and cannot be) modified. Meraki Auto VPN - Configuration and Troubleshooting - Cisco Meraki Documentation

alemabrahao

LACP & Link Aggregation The MX does not run LACP or any link aggregation protocols. Connecting aggregated ports to the LAN of the MX is not supported; all connected ports should be un-aggregated. If multiple ports are connected to the MX from a single switch for redundancy, it is highly recommended that you run STP on that switch, to ensure that one of the redundant ports is safely put into a blocking state. https://documentation.meraki.com/MX/Networks_and_Routing/MX_Layer_2_Functionality

alemabrahao

I know that Brazil is not an eligible country but I will respond to help improve the community more and more. 😄

alemabrahao

Are you Cisco Meraki partner? No there is no specifc trainig for it, but you can check the documentation. https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair

alemabrahao

Yes, it's correct.

alemabrahao

You can create a link network (transit network) between the two MXes and then create static routes to the target networks on each MX

alemabrahao

I suggest you open a support case.

alemabrahao

You have the option to remove and keep the settings, but it is highly recommended to perform this operation within a maintenance window.

alemabrahao

As far as I know there is no specific API for this.

alemabrahao

Can you show your configuration? Both the TAGs applied to the APs and the SSID availability configuration. It's a relatively simple setup, so you're probably forgetting something.

About alemabrahao

alemabrahao

Alessandro Abrahao

Community Record

Badges