About alemabrahao

alemabrahao · ‎10-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 · ‎10-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 · ‎10-16-2022

Do you know the maximum power the catalyst switch can provide? Run show power inline to check how much power is being consumed.

alemabrahao · ‎10-15-2022

SNMP. https://www.zabbix.com/br/integrations/meraki

alemabrahao · ‎10-15-2022

HI @ShellyKEO, I think that you can use Zabbix. https://www.zabbix.com/features#data_sources

alemabrahao · ‎10-15-2022

It's true, I agree with@ww .

alemabrahao · ‎10-14-2022

Key Concepts Before deploying BGP, it is important to understand several key concepts. Concentrator Mode All MXs can be configured in either NAT or VPN concentrator mode. There are important considerations for both modes. For more detailed information on concentrator modes, click here. One-Armed Concentrator In this mode, the MX is configured with a single Ethernet connection to the upstream network. All traffic will be sent and received on this interface. This is the recommended configuration for MX appliances serving as VPN termination points into the datacenter. NAT Mode iBGP establishes relationships over AutoVPN and will establish and exchange routes between: A BGP peer acting as a One-Armed Concentrator in the DC and- A NAT mode MX. eBGP peer relationships are not supported on NAT Mode MX devices. eBGP is only supported on one-armed (pass-through) concentrators. VPN Topology There are several options available for the structure of the VPN deployment. Hub and Spoke In a hub and spoke configuration, the MX security appliances at the branches and remote offices connect directly to specific MX appliances and will not form tunnels to other MX or Z-series devices in the organization. Communication between branch sites or remote offices is available through the configured VPN hubs. This is the recommended VPN topology for most deployments. https://documentation.meraki.com/MX/Networks_and_Routing/BGP

alemabrahao · ‎10-14-2022

I'm not sure, I have never used It for this purpose. 😅 But I'm pretty sure not. Flow Preferences By default (without load balancing), internet-bound traffic will flow out of the MX's primary uplink. The MX can also be configured to send traffic out of a specific interface based on the traffic type (policy-based routing), or based on the link quality of each uplink (performance-based routing). Flow preferences can be configured to define which uplink a given flow should use. Flow preferences will also supersede load balancing decisions. Internet Traffic Flow preferences for internet-bound traffic can be configured to force traffic over a specific uplink based on its source and/or destination. These preferences can be used if a specific uplink should be designated for a particular type of traffic, such as traffic bound for a cloud-hosted service.

alemabrahao · ‎10-14-2022

One more thing, if for some reason Wan 2 loses connectivity, you will need to manually configure the client to work on Wan 1, so I don't know if it's a good option.

alemabrahao · ‎10-14-2022

In this case either you configure the IP or you can configure an external DDNS (like noip.com) for the Wan2 IP.

alemabrahao · ‎10-14-2022

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

alemabrahao · ‎10-14-2022

Sorry, my bad. You need to configure the IP address of secondary link in your L2TP connection.

alemabrahao · ‎10-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 · ‎10-14-2022

I will perform a Lab.

alemabrahao · ‎10-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 · ‎10-14-2022

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

alemabrahao · ‎10-14-2022

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

alemabrahao · ‎10-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 · ‎10-14-2022

So try to find the different interfaces with the same source MAC address.

alemabrahao · ‎10-14-2022

A MAC Flap is caused when a switch receives packets from two different interfaces with the same source MAC address. If you are getting the behavior for a lot of other MACs, that most likely is a layer 2 loop.

alemabrahao · ‎10-14-2022

If I'm right it's normal when clients roam. It means the client roamed from one AP to another and then back to the first within a fairly short time. That's all. It's just a warning that the clients mac address is moving around, which is normal if the person moves the device

alemabrahao · ‎10-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 · ‎10-14-2022

Perfect, Is it a dedicated link? If yes, you just need to configure the secondary link IP address in your connection configuration, It's not necessary to create a rule.

alemabrahao · ‎10-14-2022

@johnplance try It: *googleadservices.com* googleadservices.com www.google.com:443/HTTPS accounts.google.com:443/HTTPS googledrive.com:443/HTTPS drive.google.com:443/HTTPS *.drive.google.com:443/HTTPS docs.google.com:443/HTTPS *.docs.google.com:443/HTTPS *.c.docs.google.com:443/HTTPS sheets.google.com:443/HTTPS slides.google.com:443/HTTPS talk.google.com:5222/XMPP (needed only for Backup and Sync) takeout.google.com:443/HTTPS gg.google.com:443/HTTPS script.google.com:443/HTTPS ssl.google-analytics.com:443/HTTPS video.google.com:443/HTTPS s.ytimg.com:443/HTTPS apis.google.com:443/HTTPS *.clients[N].google.com:443/HTTPS *.googleapis.com:443/HTTPS *.googleusercontent.com:443/HTTPS *.gstatic.com:443/HTTPS *.gvt1.com:443/HTTPS lh[N].google.com:443/HTTPS [N].client-channel.google.com:443/HTTPS clients[N].google.com:443/HTTPS inputtools.google.com:443/HTTPS sites.google.com:443/HTTPS sites.google.com:80/HTTP sites.google.com:443/HTTPS *.sites.google.com:443/HTTPS *.googlegroups.com:443/HTTPS ipv4.google.com:443/HTTPS ipv4.google.com:80/HTTP

alemabrahao · ‎10-14-2022

Are you talking about VPN S2S? If yes, Is it a Meraki VPN or Non-Meraki VPN?

alemabrahao

Alessandro Abrahao

Community Record

Badges