About Mr_IT_Guy

Mr_IT_Guy

I know this isn't adding anything to the conversation, but this is probably my favorite thread on the forums thus far.

Mr_IT_Guy

@PhilipDAth , not sure how it's a wide use case or require changing anything in the GUI in terms of loss and latency. You already get that information in the MX. Should be just as simple as adding it as an option under Network-wide > Configure > Alerts. If we can get an option to say "Send e-mail when a port has been down for 5 minutes", you should be able to add something similar for loss and latency (i.e. if you detect 5% loss for 10 minutes). Network saturation on the other hand, that's a heavier lift and I do agree with you there @PhilipDAth, that is a much wider use case.

Mr_IT_Guy

Hi @Nick , The setup is reasonably easy. One thing to keep in mind is that if you are using your work email address to access the dashboard and also intend to use it in SAML, you will have to do one or the other. One way to do it is using a service account not attached to SAML and have all admins in the SAML group. A couple pointers from the documentation: Limited Single Logout (SLO) is available. Dashboard will use the SLO URL to redirect users after they logout of Dashboard, and then can be used to link into SLO with the IdP if supported, but Dashboard does not support receiving SAML LogoutRequests from the IdP. Only SAML 2.0 is supported. Dashboard only supports IdP-Init. Users must first authenticate with the IdP and then be passed to Dashboard with a valid token. While IdP platforms may have a variety of other fields, in most cases they can be left blank or at default settings. Only the above information is critical for Dashboard compatibility. SAML SSO for MSPs SAML does support the use of multiple organizations. Similarly to traditional logins, it needs to determine that the user is identical across the affected organizations. Thus, for this to occur, the following must be identical across the designed organizations: X.509 cert fingerprint for the organization SAML administrator role (as only one role attribute can be used in the token) The permissions granted can be different in each Organization, but the role name must be identical When this occurs, the user will be directed to the MSP portal and receive the desired permissions in each organization. The Consumer URL for any of the MSP organizations can be used, as they will all direct the user to the MSP portal.

Mr_IT_Guy

If you are not using SAML, I believe you have to delete the admin in each organization in your MSP portal. Could be a bit time consuming if you're looking at 100s of organizations. SAML is the best way to handle this. You can easily add/remove users with various permission levels based on group membership. Here's Meraki's support documentation on SAML integration: Configuring SAML Single Sign-on for Dashboard

Mr_IT_Guy

"Port forwarding, 1:1 NAT and 1:M NAT traffic are not inspected by layer 7 rules. So, any external traffic coming from one of the blocked countries will still be seen in your network; traffic will not go out to those countries though." This is a response from the ticket I have had in with Meraki for quite sometime as we are seeing traffic from blocked countries inside of our network. I have brought this up with Meraki in the past and have been told that this is expected behavior. So while theoretically it should block the countries in question, in practice you may still see traffic from those countries coming into your network, but not going out.

Mr_IT_Guy · ‎08-26-2019

Well since the 8-port Switch has already been brought up, I would design an MX that has the capability to tell me what's plugged into the ports (similar to that of current switch ports).

Mr_IT_Guy · ‎08-07-2019

Funny enough, we just got another rep today!

Mr_IT_Guy · ‎08-07-2019

I feel like we get a new sales rep every 6 months. in the 3 years we've had Meraki in our environment, we've probably have had 6 different reps. Most of our changes have been b/c of promotions so great for those reps, but it is tough having a really good rep who knows your environment to then go back to starting at square one.

Mr_IT_Guy · ‎07-16-2019

A couple of things to try that always work for me: When setting up allow/deny rules, put allow rules up top and deny at the bottom When granting access to a single host, use a /32 on the host versus the /24 Doing these two things usually allow me to make my exceptions with zero issues.

Mr_IT_Guy · ‎07-10-2019

Congrats to all of our All Stars!!

Mr_IT_Guy · ‎07-10-2019

@NFL0NR deserves all the credit.

Mr_IT_Guy · ‎07-10-2019

@Raj66 , it's a MX65W. We made sure that power cable was unplugged. @NFL0NR can verify! MX65W with no Power. Notice link light activity on Port 11

Mr_IT_Guy · ‎07-10-2019

Looks like it's time to start posting 🙂

Mr_IT_Guy · ‎07-10-2019

So @NFL0NR found out something very random this morning: a number of our MX devices were able to be powered via PoE from our Meraki Switch. When plugged into the PoE port (11/12) on the MX device from the PoE on the switch, the MX powered on. We had an Internet uplink in Port 1 and the device was able to completely boot up, grab its config, and be a functioning device in our organization. Not seeing anywhere in the documentation where this was a feature, but we testing it on a number of our devices. Has anyone else seen this before?

Mr_IT_Guy · ‎05-13-2019

You should have no troubles trying to accomplish this. I am currently using the same summarized subnet across 4 templates. @PhilipDAth is correct in that the AutoVPN routing table is consulted to see if the subnet is available.

Mr_IT_Guy · ‎04-11-2019

Good morning @Vincent , First question I have to ask, under Security & SD-WAN>Configure>Site-to-site VPN, you should see a list of your local networks attacked to the MX64. On your Client VPN, do you have YES selected under the Use VPN column?

Mr_IT_Guy · ‎03-25-2019

My company moved from WatchGuard XTM 820 to MX600. What would you like to know?

Mr_IT_Guy · ‎03-07-2019

A bit about yourself & your work I've been in networking for going on 7 years now. Currently I help design and maintain the network infrastructure for my company, as well as take on special projects to help improve our business. Your experience with Cisco Meraki I've been using Cisco Meraki for roughly four years all together. I introduced Meraki to my former company and another tech helped bring in Meraki in my current employer A fun fact about yourself I'm the proud owner of @Maui_Meraki_Dog

Mr_IT_Guy · ‎03-06-2019

I typically use 1812 as that's the default, but if you used 1645 you would want to match that in the Meraki. As for the vLAN, vLAN 4 would be correct.

Mr_IT_Guy · ‎03-05-2019

This is a great step towards the more in-depth training that many of us have been asking for! Hopefully the ECMS2 comes to my area soon as I don't think the company will fly me out to Meraki HQ as much as I would love to go!

Mr_IT_Guy · ‎03-01-2019

That is correct.

Mr_IT_Guy · ‎02-28-2019

Correct, you use AD logins even if using RADIUS. RADIUS is used ALONG WITH AD. AD will be where it looks for the users you assign to the policy, but RADIUS is the one that enforces it. Think of it like this: RADIUS is the bouncer outside the VIP room of a club. It has to look at the exclusive list (AD) to see who gets in and who doesn't (i.e. your policy). Just because you can get into the club (i.e you have AD credentials) doesn't mean you can get into the VIP room (you don't match the policy) As for the Meraki IP you put as the RADIUS client, you would use the private IP. Keep in mind that if you have to go through a VPN tunnel to reach the RADIUS server, your MX IP would be the gateway of your HIGHEST numbered vLAN participating in site-to-site. For example, i f you have vLAN setup: vLAN 10 - gateway 192.168.10.1 vLAN 17 - gateway 192.168.17.1 vLAN 20 - gateway 192.168.20.1 vLAN 35 - gateway 192.168.35.1 vLAN 52 - gateway 192.168.52.1 and all vLANs are participating in site-to-site, the MX IP would be 192.168.52.1 as that is the highest numbered vLAN. IF vLANs 35 and 52 were NOT participating in site-to-site, then the MX IP would be 192.168.20.1 as vLAN 20 is the highest numbered vLAN.

Mr_IT_Guy · ‎02-28-2019

Hi @tantony , With AD authentication, you will point to one of your DCs for authentication purposes. As long as there is an AD account, the user will be able to connect to the VPN. (Active Directory Integration) With RADIUS, you will point to a RADIUS server for authentication, which allows you to provide a bit more security. You can setup a policy so that only people belonging to a certain AD group (which RADIUS will be pointed to) will be able to connect to VPN. (Configuring RADIUS Authentication with Client VPN) As far as 2FA is concerned, you can use RSA and DUO with the built-in Windows client, although it is limited to the Push or Biometric authentication methods as there is no way to input a code at this time. If you are using Meraki Cloud authentication, you can create multiple accounts for users to use with the VPN. (Managing User Accounts using Meraki Authentication)They do not have to have dashboard access in order to be setup as a VPN user. You should absolutely have individual accounts for each user accessing VPN.

Mr_IT_Guy · ‎02-26-2019

Glad to help out! I believe you are correct about the Auth Proxy checking the AD group membership, though I think that's based on what level of DUO you have. Your AD groups will sync with the DUO admin console You can keep RADIUS for the wifi and as a backup. We demo'd DUO and I really like the product. Ultimately we ended up going with RSA.

Mr_IT_Guy · ‎02-26-2019

Hey @DSchn , The DUO Access Gateway (DAG) and the Duo Authentication Proxy (DAP) are two different tools. The DAG acts as a kind of application portal for SSO. Users can log into the DAG and then click on company applications that you have protected using DUO. The DAG has 2FA enabled for login purposes. Additionally, you can have redirects happen on those websites you are protecting so that if someone were to navigate straight to the website without first going through the DAG, they would be redirected to the DAG for sign-in. The Authentication Proxy is what actually makes the 2FA happen. Instead of pointing your pointing to your VPN to the RADIUS server, you would instead point to the DAP. When a user attempts to connect to the VPN, they will hit the DAP which contacts AD to verify username and password. If that part is correct, they will then receive a PUSH notification to their DUO app. You will have to contact Meraki to adjust the time out on the back end for the push notification so that users don't experience a timeout. As of right now, the only way you can use 2FA with the Windows VPN Connection is with the PUSH notification or Biometrics as there is not place to put in an authentication code. This part is very frustrating. I wish support for Cisco AnyConnect would come soon!!

Mr_IT_Guy

Community Record

Badges