About PhilipDAth

Flexl75

Hi Phil, thanks will check this out and let you know

MichelRueger

Hi, If you want a technical Deep-dive to it have a look at https://www.youtube.com/watch?v=pl6wpkv_GlQ Regards Michel

AjitKumar

Hi, I understand MX do not offer DNS Services Adding MX Local IP in DHCP NS List shall not be of any help. Hope your AD DNS server is working good to resolve domains. You may follow @PhilipDAth instructions on this. Also consider verifying L3 L7 Content Filtering Traffic Shaping rules and Firmware version.

NolanHerring

@jdsilva What the heck lol. Well thanks for finding that for me.

PhilipDAth

For Gig1/1/2 and 2/1/2 you wont need to configure anything on the ports themselves. You just need to aggregate that. Follow this guide: https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Switch_Ports#Selecting_Aggregate_ports

matt12345

oops, talk about a brain fart. Goosechase was already deployed to another group of apps, which is why it was greyed out. Found this finally and adjusted the groups and all good. thanks for checking your install to confirm it wasn't just mine. cheers M

PhilipDAth

Good discovery @NolanHerring - thanks for letting everyone know.

PhilipDAth

Stop it, I'll get a big head.:-)

PhilipDAth

I just had a thought. Because you are plugging in a new "default gateway" (aka it is moving from the Dell to the Meraki) the MAC address of that gateway is changing. Perhaps this might just require someone to clear the ARP table on the remote end. Did you try doing some pings from the MS250 to the indivudual hosts during the last cut over? I guess you should do some pings now before the next cut over - to verify that the devices will respond to a ping.

Jos_HS

Thank you very much to all for the information and the tips sent, analyzing in depth I chose to place in the option of Block/white URL's of the policy: APPEND. With this when the client requests a massive change I use an API that adds the URL (block / white) in the general content filtering and with this applies to the group policy that has been created in each Meraki. Of course in this time I have to enter one by one on each device to add the config however for the future it will no longer be necessary.

BrechtSchamp

No but you can get the last seen time (epoch/unix time) from the client details: GET Return the client associated with the given identifier {{baseUrl}}/networks/{{networkId}}/clients/{{clientMac}} { "id" : "k1af98e" , "mac" : "8c:85:90:aa:aa:aa" , "ip" : "192.168.0.113" , "ip6" : "" , "description" : "Miles-MacBook-Pro" , "firstSeen" : 1520683433 , "lastSeen" : 1527370304 , "manufacturer" : "Apple" , "os" : "Mac OS X 10.13" , "user" : null , "vlan" : "1" , "ssid" : "viaPostman" , "wirelessCapabilities" : "802.11ac - 2.4 and 5 GHz" , "smInstalled" : false , "recentDeviceMac" : "88:15:44:bb:bb:bb" , "clientVpnConnections" : null , "lldp" : null , "cdp" : null }

jffortier

For anyone (like me) who read this to find out how to do it, there's a new payload available in the profile section named "Lock Screen" and you can use variable. Start type with "$" and it will list you all available variable you can set.

wey2go

@GeorgeB what distances would you recommend to consider an external illuminator?

mat1458

I did not yet know about the well-behaved part of the FW. But looking at it it makes a lot of sense in terms of economizing ports. Thanks for your endurance in answering my questions. Mat

PhilipDAth

I don't know for certain. I believe that when the user logins their MAC address becomes "authorised" on the Meraki side. That MAC address authorisation will remain in affect for the configured period. The ongoing authorisation has nothing fuether to do with AD until it expires.

PhilipDAth

Hmm, that is interesting. I was just looking at a clients MX, and they have manual port forward configured and have dual WAN circuits. We are using SD-WAN - and the WAN ports are running AutoVPN active/active - and it is working. One thing of note though is that their WAN2 has a public IP directly on it - so no NAT is required for AutoVPN to WAN2.

PhilipDAth

ps. I gave up on using Powershell for scripting. One of the issues with it is that when you start powershell running for a one off job (such as a triggered event or task scheduler (for example)) it has to instantiate the whole .Net engine. This can take a couple of seconds. If you are trying to run a lot of single fire operations this creates big problems. The .Net instantiation is a really slow process, and inherent in the powershell architecture - so can not be fixed. .Net apps suffer the same issue when you recycle their application pools in IIS. I have clients with apps where IIS can't process any requests for 5 minutes after a pool recycle. You may find moving off to other scripting languages like Python will be your best fix.

SDMAOps

Nolan, Thank you for your suggestion and link. I did look at Groups, but was not sure if that was the correct way to go; I will check out your advice.

RSindhu

Hey all, I am Rajesh Sindhu working as an IT Analyst with an education management company. I am here to learn about community' experience with Meraki products.

DunJer622

It is possible that my testing was compromised. I'll be doing more testing this Saturday. In our environment, MaaS360 uses ActiveSync to access our Exchange environment. For this question, we have 3 impacted solutions. We have a physical secure remote access (SRA) appliance and a virtual Exchange Server environment. The Exchange environment is used for MaaS360 and OWA (Outlook Web Access). As SRA and Exchange are public facing, we use NAT to access the private IP of the devices. In my current environment, I have reflexive policies in place. This is necessary, as the static public IP of the destination is actually already on the WAN environment of the same firewall managing the Wi-Fi (which causes traffic to stop without a return policy). I generally have the Wi-Fi network completely isolated from the LAN environment. I have at times made exceptions DNS and RDP. Anyhow, I tried using the L3 Outbound rules to create a reflexive policy of the associated NAT policy. No effect. However, I was having other issues with my test environment that may have been coming into play. I'll confirm on Saturday. Oh, along that line, I need an internal device to leave with a specific public IP address. In SonicWALL, this is also addressed by NAT. Is it safe to assume that L3 outbound rules can accommodate that, too? Thanks, Jeremy

PhilipDAth

@jdsilva only a single policy can have a schedule. So if the Morning policy has a schedule, you can not attach a second schedule to the Afternoon policy.

PhilipDAth

You should be able to just put: play.google.com In the block list. Note that it doesn't take affect immediately. And if has recently been accessed then the existing flow will be cached. Once that flow expires the rule will take affect. Having to wait 10 minutes is common.

PhilipDAth

If it was me, I would just expand your pool of IP address space for the devices that are attaching. Note that you do expose yourself to a possible DHCP exhaustion attack using the approach you are using (and you are in a school ...). With a DHCP exhaustion attach you can download existing attack tools, and all they do is send DHCP requests using different MAC addresses until the DHCP server has no IP address space left to give out to real clients. The second approach I would use is to just use a NAT mode SSID. With 16 million IP addresses it makes a DHCP starvation attack improbable. With the hashing method that Meraki uses with a NAT mode SSID to generate DHCP client addresses - it is probably impossible.

PhilipDAth

@Dan that will work fine. When the Z3's talk out to wherever your VPN concentrator is they will punch unique ports in the NAT of the ISP router. These unique ports will be used to send traffic from the VPN concentrator to each unique Z3. This document describes how it works. https://documentation.meraki.com/MX/Site-to-site_VPN/Automatic_NAT_Traversal_for_IPsec_Tunneling_between_Cisco_Meraki_Peers#How_does_Automatic_NAT_Traversal_Work.3F

Nash

Having to do it for every shard makes sense. Propagation can be fussy. I hope you all get it resolved soon - if it's frustrating for me, it must be worse for the support staff at Meraki who are trying to fix.

PhilipDAth

Community Record

Badges