Meraki

BrechtSchamp · ‎Jan 22 2019

Good! Might want to remove the more sensitive pieces in the source code though. Not that big of an issue but remove the network-auth.com links. Just in case.

BrechtSchamp · ‎Jan 22 2019

That shouldn't be an issue.

BrechtSchamp · ‎Jan 22 2019

@Yostie Can you post the source code of the splash page that needs the tweaking? Then we can what the id of the checkbox is.

BrechtSchamp · ‎Jan 22 2019

Teamviewer uses hole-punching for it's standard mechanism. Basically everything is outgoing connections. The connection can fall back to port 80 so it will be difficult to block all these connections without blocking other stuff. There are two options: You can configure black and whitelisting in the teamviewer instance running on your senser equipment. See this link: https://community.teamviewer.com/t5/Knowledge-Base/How-can-I-restrict-access-for-TeamViewer-connections-to-my/ta-p/4594 But it's not IP-address based, it's TeamviewerID based. That might be an option. Another solution would be to only use teamviewers "LAN-based" option. To do that you could setup port forwarding like this: And block the "normal" teamviewer by denying connections to DST IP teamviewer.com with the L3 firewall. Note that this will also block access to the teamviewer website. But from a security standpoint I really don't stand behind any of this. You should think about a VPN solution to allow remote access to machinery.

BrechtSchamp · ‎Jan 22 2019

It's a note two lines down from the bullet points you copy pasted. I had copy pasted it in my previous post. I guess it needs the IP and the DNS access for the other bullet: Blocked Splash Page will be displayed when user tries to load a web page Using a big enough pool for your DHCP and lowering the lease time should mitigate the DHCP issue. Adding to that taking a look at other high density tricks might also be relevant. Segmenting the traffic per floor to avoid having floods all over the place might help. Another thing you could do is to use a dedicated 3d party DHCP server and having MAC blacklists on that. This way both problems would also be solved. But like you I like KISS, so I'd only consider these if I'm really experiencing issues.

BrechtSchamp · ‎Jan 22 2019

In that case there will not be a link down. So that would count as a soft link failure. So 5 minutes.

BrechtSchamp · ‎Jan 22 2019

It is normal behavior, and documented. See here: https://documentation.meraki.com/MR/Group_Policies_and_Blacklisting/Blocking_and_Whitelisting_Clients Note: The device will still receive an IP address and will be able to resolve DNS names. Perhaps you should think about other ways of blocking them if that is an issue? RADIUS accounting maybe? That way access will be blocked on a L2 level during the connection phase. Edit: Forgot to specify... WPA2-Enterprise with RADIUS is what I mean, not splash page with RADIUS accounting.

BrechtSchamp · ‎Jan 22 2019

The details of the tests can be found here (see the section connectivity tests): https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Connection_Monitoring_for_WAN_Failover But the short version is: It will take approximately 5 minutes for failover to occur in the event of a soft failure (link is still up, but provides no upstream access). Falling back to the primary link goes as follows: If the MX is using the non-preferred uplink as the primary and the preferred uplink comes back online, the MX will wait about 15 seconds before switching the primary uplink to the preferred one. This is to prevent the primary connection from flapping in the event of intermittent failure or an unreliable link. Edit: Ajit was quickest.

BrechtSchamp · ‎Jan 21 2019

You mean it's not in the style sheet I suppose? Indeed it isn't, you need to add it. If you don't find gdpr_checkbox in the html code of the splash page then please let us know. Maybe it's a European thing (seeing as it has GDPR in its name)

BrechtSchamp · ‎Jan 21 2019

In most deployments trunk makes most sense. Imagine you need clients to be bridged to multiple VLANs (f.e. by having multiple SSIDs dropping them on different VLANs or by having RADIUS return a VLAN ID or even by linking VLANs to AP tags) in that case you need a trunk. If you're using a flat network configuring it as an access port will probably work too. More info here: https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/VLAN_Tagging_on_MR_Access_Points

BrechtSchamp · ‎Jan 21 2019

Thanks for sharing! Haven't tested it, but it's good to know it's here if I ever need it.

BrechtSchamp · ‎Jan 21 2019

Good question. Haven't seen it documented. Perhaps @GeorgeB will chime in.

BrechtSchamp · ‎Jan 21 2019

Enable "Location analytics" for the network.

BrechtSchamp · ‎Jan 21 2019

Yeah, a well-behaving NAT should use the same port for all outgoing connections originating from a source tuple that it already chose a port for. The referenced white-paper goes through everything in great detail and is an interesting read too: http://bford.info/pub/net/p2pnat.pdf Specifically section 3.4 describes the process I also described.

BrechtSchamp · ‎Jan 21 2019

Is this the one you mean?

BrechtSchamp · ‎Jan 21 2019

Hey Mat, You should check the "Figure 3. Connection phase: Peers use UDP hole punching to establish an IPsec tunnel." part in the link you posted in your opening post: https://documentation.meraki.com/MX/Site-to-site_VPN/Automatic_NAT_Traversal_for_IPsec_Tunneling_between_Cisco_Meraki_Peers Basically you're right, when the AP first tries to make the connection it will get blocked by the firewall. But thanks to that try it will have punched the hole in the firewall on the AP side. Meanwhile, the MX also tries to make an outgoing connection to the AP. It too, at this point, will punch a hole, this time in the firewall on the MX side. Both holes have now been punched and the connection can be established. It doesn't always work though. See this concentrator deployment guide for more info: https://documentation.meraki.com/MX/Deployment_Guides/VPN_Concentrator_Deployment_Guide Use manual NAT traversal when: There is an unfriendly NAT upstream Stringent firewall rules are in place to control what traffic is allowed to ingress or egress the datacenter It is important to know which port remote sites will use to communicate with the VPN concentrator There's also this link to troubleshoot packet streams: https://documentation.meraki.com/MX/Site-to-site_VPN/Troubleshooting_Automatic_NAT_Traversal_for_Meraki_Auto_VPN

BrechtSchamp · ‎Jan 21 2019

I doubt you'll get a response to that question here. If I were you I'd get in contact with my Meraki rep and see if I can get any roadmap information that way. I suppose you've already sent in a make-a-wish as well?

BrechtSchamp · ‎Jan 21 2019

I think he's talking about devices that are enrolled in G Suite's own device management, not SM? There's these two ways to use the G Suite/Apps credentials to connect to the network if you don't want to or can't go the Systems Manager way (which would still be better). The splash page way: https://documentation.meraki.com/MR/Splash_Page/Google_Sign-In The WPA2-Enterprise way: https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_WPA2-Enterprise_with_Google_Auth

BrechtSchamp · ‎Jan 20 2019

Yeah indeed, removing it would probably be a bad idea. Unfortunately I haven't got a mac myself, so I'm a bit in the dark here. I'd guess something went wrong with one of the steps. Because as far as I understood from the docs the pyenv global command should make the mac use the version you specify as default from then on. So the output of the python --version command surprises me, it shouldn't be outputting python 2.7.1 anymore. What's the output of: pyenv versions

BrechtSchamp · ‎Jan 20 2019

I have a feeling it's using a pre-installed version of python on your Mac. Try issuing the following command: pyenv global 3.6.5

BrechtSchamp · ‎Jan 20 2019

What about "python --version"?

BrechtSchamp · ‎Jan 20 2019

Pip3 is part of the python install. Was that succesful? What is the output for: python --version Perhaps try restarting the terminal or the laptop as a whole.

BrechtSchamp · ‎Jan 18 2019

Sounds pretty severe. Do you have a workaround? If not, are the withdrawal symptoms of not having the dashboard to play around in showing yet?

BrechtSchamp · ‎Jan 18 2019

@HodyCrouch wrote: I am not seeing this issue. I do have 2-factor authentication enabled for my account. +1 No issues so far.

BrechtSchamp · ‎Jan 18 2019

If you select the switch in the list of switches and remove it from your central network you'll be able to put it in a new network from the inventory. Go to the inventory, select it, and use the "Add to..." button to add it to a new network.

About BrechtSchamp

BrechtSchamp

Community Record

Badges