- About Adam2104
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Adam2104
Getting noticed
Member since Apr 13, 2019
2 weeks ago
Community Record
25
Posts
8
Kudos
1
Solution
Badges
08-27-2019
05:58 PM
I ran MR26.4 for a while (I recently downgraded for other issues) with many echo devices, mostly newer ones, without too much trouble. They're all connected to 5ghz, no issue. MR42s here, bridge mode, wpa2 psk, single ssid broadcasting on 2.4 and 5. Echos are all up on 5ghz.
... View more
06-26-2019
01:40 PM
I tried the 0.0.0.0/0 and it works. I tested it by creating a rule and setting an abitrary DSCP value and then running a pcap on the outside interface to confirm that DSCP value was being set. Thanks!
... View more
06-26-2019
11:25 AM
I'd like to create a traffic shaping rule on my MX67 that matches all traffic not matched by the higher priority rules. Is there a particular syntax to match everything? I can't seem to figure it out.
... View more
06-14-2019
05:17 PM
1 Kudo
Group policy rules are not stateful. Only the firewall configuration page (Security & SD Wan --> Configured --> Firewall) is stateful rules. Group policy rules are basically ACL entries with no state, if you're used to configuring Cisco routers. You'll need to manually allow return traffic if you're planning to use group policy rules. Note, any rules you apply via group policy will bypass any rules you've got specified in the firewall configuration page. So, if you're using group policy to control internal vlan to vlan traffic, but also want the firewall configuration to apply to vlan to wan traffic you're out of luck. It's a disappointing limitation which has dramatically reduced the usefulness of group policy for me.
... View more
05-24-2019
05:28 AM
I opened the case and it was confirmed that this looks to be broken. Now we're waiting on a fix to which there is no ETA.
... View more
05-24-2019
05:27 AM
1 Kudo
I've seen a similar, but not exactly the same issue. With Apple's new "ScreenTime" feature I have it set to lock devices out at 7pm (here at home). On one of my devices, Safari takes just a second or two to lock out, during which time my kids are able to pull up a video, which will keep playing, even after the lock out. Are you devices older? It seems to happen only on my older/slower devices.
... View more
05-03-2019
06:51 AM
What is everyone doing from a combined/separate network perspective? I just started out with a full Meraki stack, MX, MS, and MR, so I started with a combined network. However, it seems that within a combined network I only have one chance to apply a group policy. For example, I apply a group policy to a wireless client device to block access to a particular internal resource via a L3 firewall rule I also have to completely duplicate all the L3 firewall rules that are configured on the MX, otherwise the device bypasses all the MX firewall rules. So, now I've split the networks. This seems to let me apply a group policy to my wireless clients (say, IoT devices), but also allows the MX L3 firewall rules to still apply because the group policies are only network specific. Is my understanding correct?
... View more
04-26-2019
04:48 PM
Are you using WPA2 Enterprise or PSK? If PSK then 802.11r, in any mode, is not recommended because it is a security issue. Dashboard will warn you if you deploy this type of config.
... View more
04-25-2019
08:41 AM
I have, I'm waiting for a response. I figured I'd reach out to the community to see if anyone else has seen the same thing.
... View more
04-25-2019
07:55 AM
I've done some more testing, this time not with VLAN assignment but with Layer3 firewall rules. The same behavior occurs. It takes over 70 seconds for the group policy to be applied to a client, during which time any L3 firewall rules that are specific to that client ARE NOT ACTIVE. Also, it seems that once the policy actually applies any connections/streams that were up during this period of no firewall enforcement will remain up until terminated (I tested with ping). So, it seems to me, that if you're using group policies with WPA PSK to do any kind of policy enforcement you've got a major security hole every single time your access point reboots. There's a large window of time, over a minute, where the client is not filtered. I guess I will have to completely rework my approach to L3 firewall group policies to try to workaround this.
... View more
04-25-2019
07:25 AM
So I tried again, I created a new group policy that assigns a different VLAN than the SSID's base VLAN tag (50 vs 10). Sadly, traffic from those clients still shows up in the SSID's VLAN tag immediately following a reboot of the access point, they are then later pushed into the group policy VLAN, but only after they've managed to get an IP address from the wrong subnet.
... View more
04-25-2019
06:35 AM
I actually reconfigured it for blank this morning after I factory reset all the APs. They're were griping about a bad IP configuration, even though they were configured for static. I find it odd that that switches require the VLAN to be configured when you set a static IP. The access points do not. edit: I'll have to recreate my group policy configuration to try again with the blank VLAN. I'll do that and report back.
... View more
04-25-2019
06:08 AM
Not sure why that matters? It's in VLAN 1, native VLAN, for management only.
... View more
04-24-2019
09:22 PM
I have several group policies attached to various wireless clients in my network. There's a single SSID that has a VLAN tag of 20. The group policy is tagging certain devices with VLAN10. This works great, until the access point reboots (say a power outage, or software upgrade), then, when the AP is booting back up the group policy isn't applied and devices that should be in VLAN10 are getting IP addresses from VLAN20. This is a problem because eventually the group policy DOES get applied but the clients have already gotten IP addresses from the wrong VLAN and thus cannot communicate out. I'm running an MR42, I've tried both the latest stable and the latest beta release and the results were the same. VLAN tags not applied to group policy clients immediately after reboot. Am I missing something? Is there some "wait until everything is ready before turning on the radios" option that will make the group policy apply after rebooting an access point?
... View more
04-24-2019
03:07 PM
@m_Andrew thanks for the extra info! I was able to confirm a few things: 1. The switch is responding to arp, but not ICMP, as you suggested. 2. The switch is actually doing the relay operation, but the "use the uplink for the mgmt interface" seems to be a fundamentally flawed design. Let me explain: Switch uplink IP - 172.28.0.2 Switch DHCP relay interface IP - 172.28.1.250 DHCP server - 172.28.4.254 So, the switch is relaying from the 172.28.1.x network and sending the relayed packet to the DHCP server at 172.28.4.254 it does this over the uplink interface. The problem is, it's sourcing the packet from the DHCP relay interface IP, 172.28.1.250. But, it's sending it on the uplink interface which is the 172.28.0.0/24 subnet. The MX67 IP spoofing protection eats the packet because the source IP doesn't match the subnet of the incoming interface. I can't see any situation where the MS120 would be able to relay for VLANs other than the management VLAN when the traffic is being handled by an MX with IP spoof protection turned on (it is by default).
... View more
04-24-2019
12:32 PM
I actually upgraded to the latest/newest beta, 11.15. I still can't ping the pseudo interfaces. Maybe there was a regression? It isn't responding to arp, as you said.
... View more
04-22-2019
04:25 PM
Yep, that's exactly how I configured it, but it doesn't work. I've noticed two things about that: 1. I cannot ping the switch on the configured address(es), even though it's sending out IGMP queries using those same addresses. I've verified that with a pcap. 2. Once you enable DHCP relay on an interface in Dashboard you can't turn it off (error message is shown). I have to delete the interface and recreate it.
... View more
04-22-2019
03:28 PM
I have multiple networks: vlan 1 - 172.28.0.0/24 vlan 10 - 172.28.1.0/24 vlan 20 - 172.28.2.0/24 vlan 30 - 172.28.3.0/24 vlan 40 - 172.28.4.0/24 My main switch has an IP in each of those blocks for IGMP querier purposes, the IPs are: vlan 1 - 172.28.0.250 vlan 10 - 172.28.1.250 vlan 20 - 172.28.2.250 vlan 30 - 172.28.3.250 vlan 40 - 172.28.4.250 IGMP querier works fine, i see the switch sending queries on each VLAN, sourced from the IPs listed above. The DHCP server lives in VLAN40 as 172.28.4.254.
... View more
04-22-2019
03:09 PM
Yep, everything on the DHCP server is setup. Relay works fine with my MX67. It doesn't work, at all, on the MS120. It never relays a single DHCP packet. I upgraded the switch to the newest beta and it still doesn't work.
... View more
04-22-2019
10:33 AM
Nope, it's an access port in a different VLAN. The MX has all the required VLANs and DHCP relay works just fine with the MX does it. It just doesn't work when the MS is supposed to be doing it.
... View more
04-22-2019
10:28 AM
DHCP server is running Dnsmasq, running on a Raspberry Pi3, and plugged into the same switch, but in a different VLAN. An MX67 provides intervlan routing.
... View more
04-22-2019
10:11 AM
I have a few MS120 switches in use. According to the Routing & DHCP page these switches should support DHCP relay (but no other L3 functions). I'm currently using my MX67 for DHCP relay but I thought I'd test it out on the MS120 to see what happened. Well, it doesn't work, no DHCP messages are seen at the DHCP server sourced from the switch. I'd expect to see a forwarded DHCP request with the GiAddr set, but nothing shows up. As soon as I enable DHCP relay on the MX67 again, for the same VLAN, the messages start appearing, so I would expect the switch to do the same. Has anyone tried and/or tested this on the MS120? It seems broken to me. My switch is running whatever the current stable release is. I haven't jumped on the beta release yet to see if that changes anything.
... View more
04-14-2019
05:17 AM
If that's the case then the documentation is poorly formatted. A Sentry Enrollment SSID is listed as a separate option from automatic network discovery in the link I posted. If one requires the other why is it listed as a separate option in the list of available enrollment choices? Honestly, the description seems to suggest they are, in fact, two different options.One that forces enrollment (Sentry SSID) and one that simply makes it easier by not having to know the network id (automatic discovery).
... View more
04-13-2019
06:06 PM
1 Kudo
According to this document: https://documentation.meraki.com/SM/Device_Enrollment/Enrolling_Devices If an iOS device is connected to a Meraki wifi network it should be able to enroll without knowing the network ID code or the qr code, etc. I have a full Meraki stack, MS, MR, MX, and when I run the SM app on iOS 12.2 (iphone and ipad), it doesn't detect any Meraki networks. I still have to either scan the qr code, or, punch in the network ID code. Is there something specific I need to configure for this to work? I've been searching for a long while and can't find anything.
... View more
Labels:
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 486 | 06-14-2019 05:17 PM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 5 | 2516 | |
| 1 | 486 | |
| 1 | 411 | |
| 1 | 442 |
