Meraki

alemabrahao · ‎Oct 16 2022

It should work this way. I also have two DCs but I don't remember having route asymmetry. https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior Route Priority Each type of route configured on the MX has a specific priority in comparison with other types of routes. The priority is as follows: Directly Connected Client VPN Static Routes AutoVPN Routes Non-Meraki VPN Peers BGP learned Routes NAT* NOTE: For BGP route selection please refer to: https://documentation.meraki.com/MX/Networks_and_Routing/BGP *If no routes are defined, then the traffic is NATed and sent out an active Internet interface. This only occurs while the MX is configured in Routed mode.

alemabrahao · ‎Oct 16 2022

Hi @DennisS, This might solve it, but it's looking more like a configuration issue on BGP, check if Route Prioritization has been configured.

alemabrahao · ‎Oct 14 2022

Good news, I tested again changing my IPsec policies and my password greater than 14 characters and worked

alemabrahao · ‎Oct 14 2022

I just test It, and I have some considerations: In beginning I had same issue (My MX is behind a NAT too), so I did a search about FIPS and I found IT: https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Meraki_Device_to_Cloud_Connectivity_-_FIPS Then I changed my IPsec policies configurations like this: And guess you ? It worked. I don't like to use 3DES and MD5, but .... OK 😐

alemabrahao · ‎Oct 14 2022

I will perform a Lab.

alemabrahao · ‎Oct 14 2022

Well, I have never configure Non-Meraki VPN peers with MX behind a NAT, so I'm not sure if It will work. Maybe you should have to open a case with Meraki.

alemabrahao · ‎Oct 14 2022

By the way, is your link dedicated? Is your ISP using CG-NAT?

alemabrahao · ‎Oct 14 2022

Do you have access on remote peer? Try to generate some traffic (ICMP for exemple).

alemabrahao · ‎Oct 14 2022

Hello guys, This is a guide I created about how to perform FreeRadius integration with OpenLDAP and Dynamic Vlan Assignment with Meraki Wifi(CentOS v7). I hope it helps you. OpenLDAP installation and configuration Install OpenLDAP with the installation packages: yum -y install openldap compat-openldap openldap-clients openldap-servers openldap-servers-sql openldap-devel Start and enable the SLAPD service: service slapd start systemctl enable slapd.service Generating the LDAP administrative password: slappasswd We will have something like the following after the password is generated: {SSHA}w2XBxT9foe5cfJz11SZiwaXaNwRmrCSG Note: Copy the generated hash as it will be necessary for the following configurations. The configuration that we must change is located in the following file /etc/openldap/slapd.d/cn=config/cn\=config/olcDatabase\={2}hdb.ldif, however it is not recommended to edit this file directly, to this lets create the database.ldif file and insert the following parameters as in the example: cd /etc/openldap/slapd.d/ vi database.ldif dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcSuffix olcSuffix: dc=local,dc=br dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootDN olcRootDN: cn=Manager,dc=local,dc=br dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcRootPW olcRootPW: {SSHA}w2XBxT9foe5cfJz11SZiwaXaNwRmrCSG //Senha gerada no passo anterior Change the LDAP database using the following command: ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/openldap/slapd.d/database.ldif We should have an output similar to the example: ASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={2}hdb,cn=config" modifying entry "olcDatabase={2}hdb,cn=config" modifying entry "olcDatabase={2}hdb,cn=config" Next we have to change the /etc/openldap/slapd.d/cn=config/olcDatabase={1}monitor.ldif file, as in the previous step it is not recommended to edit this file directly, for that we will create the file monitor.ldif and enter the following parameters: dn: olcDatabase={1}monitor,cn=config changetype: modify replace: olcAccess olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external, cn=auth" read by dn.base="cn=Manager,dc=local,dc=br" read by * none Make the changes using the following command: ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/openldap/slapd.d/monitor.ldif We should have an output similar to the example: SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={1}monitor,cn=config" Create a self-signed SSL certificate, which will be used by our LDAP server. Use the following command: openssl req -new -sha256 -nodes -out /etc/openldap/certs/local-cert.pem -keyout /etc/openldap/certs/local-key.pem -days 365 We must fill in the information as in the example below: After generating the certificate, we will adjust the user and group permissions with the following command: chown ldap: /etc/openldap/certs/*.pem Then we must insert the certificate information in the following file /etc/openldap/spad.d/cn=config.ldif, which also must not be directly edited, so let's create the certificates.ldif file with the following information: dn: cn=config changetype: modify replace: olcTLSCertificateFile olcTLSCertificateFile: /etc/openldap/certs/local-cert.pem dn: cn=config changetype: modify replace: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/openldap/certs/local-key.pem Make the changes using the following command: ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/openldap/slapd.d/certificates.ldif Check current settings with the command: slaptest -u We should have the output like the example below: config file testing succeeded Now we will copy the example database provided by OpenLDAP to /var/lib/ldap and change the user and group permissions: cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG chown ldap: /var/lib/ldap/* Once this is done, we will add the following LDAP schemas: ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif Now let's create the base.ldif file in /etc/openldap/spapd.d and insert the following parameters: dn: dc=local,dc=br dc: local objectClass: top objectClass: domain dn: cn=Manager,dc=local,dc=br objectClass: organizationalRole cn: Manager description: LDAP Administrator dn: ou=People,dc=local,dc=br objectClass: organizationalUnit ou: People dn: ou=Group,dc=local,dc=br objectClass: organizationalUnit ou: Group Make the changes with the following command: ldapadd -x -W -D "cn=Manager,dc=local,dc=br" -f /etc/openldap/slapd.d/base.ldif Note that you will be prompted for the previously generated root password (in our case, the "Manager" user, which we used in our examples and which we generated at the beginning with slappasswd): If everything is correct, we will have output similar to the following example: Enter LDAP Password: adding new entry "dc=local,dc=br" adding new entry "cn=Manager,dc=local,dc=br" adding new entry "ou=People,dc=local,dc=br" adding new entry "ou=Group,dc=local,dc=br" Now we will add the following services to the Firewall configuration, for that we will execute the following commands: firewall-cmd --permanent --add-service=ldap firewall-cmd --permanent --add-service=radius firewall-cmd --permanent --add-service=http firewall-cmd --reload Install and configure the OpenLDAP Client: yum install -y openldap-clients nss-pam-ldapd Add the client IP (in this case our server IP) and restart nslcd with the following commands: authconfig --enableldap --enableldapauth --ldapserver= Server IP --ldapbasedn="dc=local,dc=br" --enablemkhomedir –update systemctl restart nslcd FreeRadius Integration with OpenLDAP and Dynamic Vlan Assignment The following settings are a complement to the FreeRadius v3 file and Dynamic Vlan Assignment with Meraki v1.0. Create a symbolic link from the LDAP module to the active modules: ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ Enable LDAP support in /etc/raddb/sites-available/default and /etc/raddb/sites-available/inner-tunnel files, for that we must leave both files configured as follows: authorize { ldap //Uncomment } authenticate { Auth-Type LDAP { //Uncomment Ldap //Uncomment } //Uncomment } Now we must configure the /etc/raddb/mods-enabled/ldap file as follows: ldap { server = 'Ip_Servidor' port = 389 identity = 'cn=Manager,dc=local,dc=br' password = senha_usuário_ldap base_dn = 'dc=local,dc=br' group { name_attribute = cn //Uncomment membership_filter = "(|(member=%{control:Ldap-UserDn})(memberUid=%{%{Stripped-User-Name}:-%{User-Name}}))" // Uncomment Change the following configuration in the /etc/raddb/mods-enabled/eap file: #default_eap_type = md5 //Comment default_eap_type = peap // Insert below Change the following line from no to yes so that the RADIUS server injects the information into the end client: use_tunneled_reply = yes Edit the /etc/raddb/users file, comment out all lines and insert the following lines: DEFAULT Ldap-Group == "cn=ti,ou=Group,dc=local,dc=br" Tunnel-Medium-Type = 6, Tunnel-Private-Group-ID = "VLAN ID", Tunnel-Type = VLAN After that restart the OpenLDAP and FreeRadius services: service slapd restart service radiusd restart With the services running and integrated, we can test the user with the following command: radtest -x username password localhost 0 testing123 If everything is correct, we should have the result as shown below: Note: First we need to create the group and after that create the user linking it to the created group so that we can run the test. Commands for Log: tail -f /var/log/radius/radius.log tail -f /var/log/ldap.log Last but not least, configure on Meraki's Dashboard, so that APs accept VLAN attributes sent by RADIUS server. On Wireless > Configure > Access Control, select the WLAN and in "Radius Override" enable the option "RADIUS Response Can Override VLAN tag". Note: It is necessary to configure the ports on the switch where the APs are connected in trunk mode, specifying the VLANs that will be used.

alemabrahao · ‎Oct 14 2022

Client VPN The client VPN service uses the L2TP tunneling protocol, and can be deployed without any additional software on PCs, Macs, iOS devices, and Android devices, since all of these operating systems natively support L2TP VPN connections. Note: TLS (SSL) client VPN is supported on the MX with AnyConnect. To learn more, see AnyConnect on the MX Appliance Note: Linux-based operating systems can support client VPN connections as well, although third-party packages may be necessary to support L2TP/IP. Note: Establishing a client VPN connection when the client is located on the LAN of the MX is unsupported. Encryption Method Client VPN uses the L2TP/IP protocol with the following encryption and hashing algorithms: 3DES and SHA1 for Phase1; AES128/3DES and SHA1 for Phase2. As a best practice, the shared secret should not contain any special characters at the beginning or end. Owing to changes in the PCI-DSS Standard version 3.2.1, some auditors are now enforcing requirements for stronger encryption than the Meraki Client VPN default settings provide. Please contact Meraki Support if you need these values adjusted, but please be aware that some client devices may not support these more stringent requirements (AES128 encryption with DH group 14 - Required by PCI-DSS 3.2.1).

alemabrahao · ‎Oct 14 2022

Confirm that all Phase 1, Phase 2 and PSK settings are the same on both sites. Non-Meraki VPN peers You can create Site-to-site VPN tunnels between a Security Appliance or a Teleworker Gateway and a Non-Meraki VPN endpoint device under the Non-Meraki VPN peers section on the Security & SD-WAN > Configure > Site-to-site VPN page. Simply click "Add a peer" and enter the following information: A name for the remote device or VPN tunnel. What IKE version to use (IKEv1 or IKEv2)* The public IP address of the remote device. The Remote ID of the remote peer. This is an optional configuration and can be configured to the remote peer’s UserFQDN (e.g. user@domain.com), FQDN (e.g. www.example.com) or IPv4 address as needed. Which of these values you use is dependent upon your remote device. Please consult its documentation to learn what values it is capable of specifying as its remote ID, and how to configure them (e.g. crypto isakmp identity for ASA firewalls The subnets behind the third-party device that you wish to connect to over the VPN. 0.0.0.0/0 can also be specified to define a default route to this peer. Note that if an MX-Z device is configured with a default route (0.0.0.0/0) to a Non-Meraki VPN peer, traffic will not fail over to the WAN, even if the connection goes down. The IPsec policy to use. The preshared secret key (PSK). Availability settings to determine which appliances in your Dashboard Organization will connect to the peer. *IKEv2 requires firmware version 15.12 or greater When configuring NMVPN connections between 2 MXs in different organizations that are running MX15 code and above that are not using a UserFQDN and are NATed behind an upstream device, please ensure that the remote ID field of the NMVPN peer is filled out with the private IP address of the remote NATed MX. Non-Meraki VPN Peering with FQDN This feature enables the use of FQDN instead of an IP address while configuring a Non-Meraki VPN peer. Using IP addresses can be tedious because with a dynamic IP address, a customer has to manually modify the Non-Meraki VPN settings on the Site-to-Site VPN page when there is an IP address change. With FQDN configuration, the hostname of the remote peer would automatically get resolved each time a connection is initiated. “FQDN” differs from “User FQDN”. The MX resolves the FQDN to an IP address of the remote peer, whereas, “User FQDN” is used in conjunction with the IP address of the remote peer. “FQDN” identifies the remote peer and is configured in the “Public IP/Hostname” field. “User FQDN” identifies the local peer and is configured in the “Local ID” field. Supported Products: MX running firmware 18.1 or higher Requires IKEv2 Configuration The FQDN of the Non-Meraki VPN peer can be configured in the Public IP/Hostname field when IKEv2 is the selected IKE version. The default behavior of the MX is to set remote_id to FQDN if it is not explicitly added in the dashboard "Non-Meraki VPN peers" settings. Please note, the remote id on one peer needs to match the local id on the other peer for the tunnel to be established. If the configured FQDN fails to resolve, an event will be reported in Network-wide > Eventlog on Dashboard NOTE For IKEv2 Meraki Appliances build IPsec tunnels by sending out a request with a single traffic selector that contains all of the expected local and remote subnets. Certain vendors may not support allowing more than one local and remote selector in a given IPsec tunnel (e.g. ASA 5500-X series firewalls running certain firmware releases); for such cases, please use IKEv1 instead. An MX-Z device will not try to form a VPN tunnel to a non-Meraki peer if it does not have any local networks advertised. IPsec policies There are three preset IPsec policies available. Default: Uses the Meraki default IPsec settings for connection to a non-Meraki device AWS: Uses default settings for connecting to an Amazon VPC Azure: Uses default settings for connecting to a Microsoft Azure instance If none of these presets are appropriate, the Custom option allows you to manually configure the IPsec policy parameters. These parameters are divided into Phase 1 and Phase 2. Phase 1 Encryption: Select between AES-128, AES-192, AES-256, and 3DES encryption Authentication: Select MD5, SHA1 or SHA256* authentication Diffie-Hellman group: Select between Diffie-Hellman (DH) groups 1, 2, 5 or 14* Lifetime (seconds): Enter the phase 1 lifetime in seconds * These settings require firmware version 15.12 or greater Phase 2 Encryption: Select between AES-128, AES-192, AES-256, and 3DES encryption (multiple options can be selected) Authentication: Select between MD5 and SHA1 authentication (both options can be selected) PFS group: Select the Off option to disable Perfect Forward Secrecy (PFS). Select group 1, 2, or 5 to enable PFS using that Diffie Hellman group. Lifetime (seconds): Enter the phase 2 lifetime in seconds On May 8th 2018, changes were introduced to deprecate DES for encryption. Click here for more information. NOTE: Please ensure the phase 2 lifetimes are equal on both ends of the tunnel whenever possible. While MX's can sometimes honor a shorter phase 2 lifetime if they're acting in response to build a tunnel, they cannot while serving as the initiator of the tunnel. Peer availability By default, a non-Meraki peer configuration applies to all MX-Z appliances in your Dashboard Organization. Since it is not always desirable for every appliance you control to form tunnels to a particular non-Meraki peer, the Availability column allows you to control which appliances within your Organization will connect to each peer. This control is based on network tags, which are labels you can apply to your Dashboard networks. When "All networks" is selected for a peer, all MX-Z appliances in the organization will connect to that peer. When a specific network tag or set of tags is selected, only networks that have one or more of the specified tags will connect to that peer.

alemabrahao · ‎Oct 13 2022

If I understood correct you need access this camera via Internet, so you need to create a NAT. Take a look on Meraki documentation. https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX#1:1_NAT

alemabrahao · ‎Oct 13 2022

Open a case with Meraki team support.

alemabrahao · ‎Oct 13 2022

Well, I suggest you try putting the machine on the allowed group policy and test again, It's not a route problem and probably a rule on your group policies are blocking the connection.

alemabrahao · ‎Oct 12 2022

Well, like meraki team support said, they have a issue with their Radius server. Is it possible to use a external Radius server (like NPS, freeradius, etc)? Have you tried to performe a packet capture to see more details?

alemabrahao · ‎Oct 12 2022

Access points intended to form a wireless link or mesh together must be within direct line of sight of each other. Wireless bridges running version 27.X or below only support a single VLAN. If support for multiple subnets is a requirement for the deployment, a layer 3-capable device will be required. MR repeaters will only send/receive untagged traffic on its wired interface regardless of the configuration of the SSID in use. Starting 28.1, Multi-vlan support was added. By extension, wired clients across the mesh link do not support the use of VLANs applied by Group Policies. https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Extending_the_LAN_with_a_Wireless_Mesh_Link

alemabrahao · ‎Oct 12 2022

Look, I'm pretty sure that's not possible. Is it not possible to connect these switches to your infrastructure via an Ethernet cable?

alemabrahao · ‎Oct 12 2022

@Vincent61 I didn't understand your question. Do you want to connect Meraki Switches via Wireless?

alemabrahao · ‎Oct 12 2022

One more information. The IPv6 neighbor discovery process uses Internet Control Message Protocol (ICMP) messages and solicited-node multicast addresses to determine the link-layer address of a neighbor on the same network (local link), verify the reachability of a neighbor, and track neighboring devices. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configuration/xe-3se/3850/ip6-neighb-disc-xe.html#GUID-A09BEBD3-2E2B-464A-89C2-025BD6D7660D

alemabrahao · ‎Oct 12 2022

It's under Monitor Appliance Status

alemabrahao · ‎Oct 12 2022

I don't think that is the case.

alemabrahao · ‎Oct 12 2022

There is not a specific log to know It was restarted, but you can configure an alert to it when goes offline or you can check the connectivity history on Appliance status page. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Alerts_and_Notifications

alemabrahao · ‎Oct 12 2022

I think it's only possible to GET information about a specific profile: https://developer.cisco.com/meraki/api-v1/#!get-network-sm-profiles

alemabrahao · ‎Oct 12 2022

Take a look on this recommendations: https://hcsonline.com/images/PDFs/Wi-FI_Apple_Devices.pdf For Apple devices I really recommend a 5GHz only coverage design. https://www.cisco.com/c/dam/en/us/td/docs/wireless/controller/technotes/8-6/Enterprise_Best_Practices_for_iOS_devices_and_Mac_computers_on_Cisco_Wireless_LAN.pdf

alemabrahao · ‎Oct 12 2022

Is it a non-Meraki VPN point or Meraki VPN? If it is a non-Meraki VPN point, does the point on the other end need to allow its local networks? There is an example of the configuration between a Cisco ASA and an MX Meraki ( It's Just a example OK?). https://documentation.meraki.com/MX/Site-to-site_VPN/MX_to_Cisco_ASA_Site-to-site_VPN_Setup

About alemabrahao

alemabrahao

Alessandro Abrahao

Community Record

Badges