Meraki

DHAnderson · ‎Apr 13 2019

SSL inspection helps solve a problem and I agree the further upstream you can block malware, the better. That said SSL inspection will always be invasive, expensive to do at high speeds, and troublesome with Browsers that are getting better at detecting MITM attacks. A more balanced approach might be to do inspection where one easily can. The Firewall can inspect unencrypted traffic, and the endpoint protection can inspect traffic after it has been unencrypted on the client. This solution also scales nicely.

DHAnderson · ‎Apr 13 2019

I agree that communication has been poor on this issue. There have been statements that early decisions were made about the MX design that need to be rethought because of IPV6. Besides the technical issues related directly to an IPV6 stack, there likely is the issue of a schema design change in the MX. This would mean potential complex transition steps from old MX to IPV6 MX. One would want to preserve any IPV4 settings on an existing production MX after such an upgrade for IPV6, and that schema change requires careful planning and execution on Meraki's part.

DHAnderson · ‎Apr 13 2019

Unfortunately, it sounds like the issue is the design of the MX that is the complicating factor. The good news is that in the April Quarterly, they did not directly answer a question about IPV6, but they did say that they are working on it.

DHAnderson · ‎Apr 13 2019

Unfortunately, it sounds like the issue is the design of the MX that is the complicating factor. The good news is that in the April Quarterly, they did not directly answer a question about IPV6, but they did say that they are working on it.

DHAnderson · ‎Apr 10 2019

Assume for the time being that the public IP of the access point is 10.128.128.128. Also assume Client A gets the same 10.128.128.128. If we also assume the access point acts like a switch with NAT capability, there will be two entries in a MAC to IP table for 10.128.128.128. This should cause an IP conflict and traffic to that IP address may get dropped.

DHAnderson · ‎Apr 9 2019

That is exactly what I am thinking, and I agree it is highly unlikely. Did Meraki test that? Great question! Going back to Murphy, I think I should avoid the issue until I can change the Lan to something not 10.x.x.x. The client can get by on a 172 address or even a 192 address. In the mean time I can use bridge mode, use Layer 2 isolation and block all access to the Lan in the firewall. Thanks to all who have chimed in! - Dave

DHAnderson · ‎Apr 9 2019

If Murphy (author or many laws) decided to give a Nat address to a client that is the same address the the AP has, NAT will get confused. At the very least, no packets will ever get to the NAT client. At the very worse, nobody tested this and the access point will tip over. I agree that given how the Guest Network works, this is very unlikely to happen, but Murphy likes those kind of challenges.

DHAnderson · ‎Apr 9 2019

You could try removing the devices from your network using the Meraki web page. After that, check to see the SSID (wired) issue another other issues have cleared up. Then put the devices back in the proper network.

DHAnderson · ‎Apr 9 2019

Make sure the ports are enabled. On my MX65, the ports supply two MR33 without issue. It is my understanding that the ports are dynamically powered. If they don't sense a power draw, they will not supply power.

DHAnderson · ‎Apr 9 2019

Thanks for your response. So then it is possible, but perhaps unlikely that an address of a device could be that same as that of the MR if the MR address is in the 10.0.0.0/8 range. Correct?

DHAnderson · ‎Apr 9 2019

I have a client where the previous network engineer put all the devices on a 10.63.145.0/24 subnet. I want to use the Guest Network on a MR series access point, but that uses a 10.0.0.0/8 subnet. I am guessing that there will be potential clashes if I try this, but does anyone know if MR Access Point is smart enough that it will not allocate its own IP address in its DHCP pool for the Guest Network?

DHAnderson · ‎Mar 22 2019

I have System Manager and when it setups the VPN connection it selects all 3 options: PAP, CHAP and CHAP V2, and I have no problem connecting to any Meraki VPN setup this way. I do know that sometimes Windows 10 will not connect properly until one does a reboot. That always fixes the issue for myself and my clients.

DHAnderson · ‎Mar 20 2019

Basement drying after melting snow vacationed there. But the Meraki gear is high and dry Blowers and giant dehumidifiers Meraki humming along above the fray

DHAnderson · ‎Mar 13 2019

I got a Lift Off Badge! Can I peel it off and stick it on to my MX65?

DHAnderson · ‎Feb 14 2019

I created a VLAN for all the network devices and blocked access from the LAN to that VLAN. NMap is still showing open ports on the MX65.

DHAnderson · ‎Feb 11 2019

I have local device status pages disabled, yet when I run a NMAP scan of my LAN, my MX65 shows 8090 and 8181 open. The service shown is HTTP. When I try to get to those IP address in a browser I get message that mx.meraki.com is taking too long to respond. One of my access points is showing ports 53 (domain) and 81 (http) open. Are these ports open by design? If not, is there a way to close them, or should I move the local IP addresses to a management LAN that is not accessible from the LAN. - Dave

DHAnderson · ‎Feb 11 2019

I have a client with many users on a Meraki VPN, all with Windows 10. I have noticed that time from time Windows 10 will not connect to any Windows based VPN, until after a reboot. I also noticed the VPN is much more reliable if it does not have saved credentials. I have more times that I care to count where the connection appeared to hang (requiring a reboot to get any VPN to work again). I would then clear the credentials and the connection would work there after, every time.

DHAnderson · ‎Feb 4 2019

Before getting my MX65, I was using Sonicwall TZ300. I have Charter service and my TZ300 was getting a /62 subnet from them. The TZ300 used Router Advertisement which passed through my MS220-8P and MR33 without any problem, so both wired and wireless clients were able to get IPV6 address. The MS220-8P and MR33 also received IPV6 addresses. In short, you have an IPV6 network by replacing your MX64 with something roughly equivalent, like a TZ300.

DHAnderson · ‎Jan 8 2019

I have verified that my MS220-8P and MR33 all respond properly to IPV6 router announcements and can get a /64 address. I would be more than happy to to try beta MX IPV6 code to further the cause.

DHAnderson · ‎Jan 7 2019

There are a number of YouTube videos on it. Google LDAP with your version of Windows server. You will need a certificate, but can generate one on your server.

DHAnderson · ‎Jan 7 2019

When you setup the server, did you enable LDAP? If so, is it using the default port?

DHAnderson · ‎Jan 7 2019

Under the Firewall section of Security & SD WAN, there is a Bonjiur Forwarding setting. Add a rule where the Service VLANs (in your case) is 1, and the Client VLANs is 3 or 50.

DHAnderson · ‎Jan 6 2019

JumpCloud is a cloud based directory replacement for AD. It works well for distributed and or small companies where a typical AD environment would not work well. It has user management (that can sync with GSuite), machine management, and some some group policies. It supports SSO with GSuite, AD, and many sites. Support is excellent. They have a RADIUS implementation that is a breeze to setup. You can learn more about them at JumpCloud.com

DHAnderson · ‎Jan 6 2019

I have one client using RADIUS authentication with JumpCloud, and it works nicely. If you have AD, then secure LDAP should suffice. If you don't want to use a certificate for LDAP, then shared secret with RADIUS is good, but a bit more work to setup.

DHAnderson · ‎Jan 5 2019

On the Client VPN page, when the authentication is set to Active Directory, the ActiveAdiectory server settings has 4 fields. The first fiield is titled "Short domain". Are we talking about two different things?

About DHAnderson

DHAnderson

Dave Anderson

Community Record

Badges