Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About Adam2104
Community Record
104
Posts
54
Kudos
1
Solution
Badges
Apr 25 2020
4:20 AM
@DarrenOC Sadly, just up'ing the spec of the MX isn't really viable. The only MX that meets/exceeds the performance of the Firepower1010 is the MX100 which has a list price of $4995, without a license. The Firepower1010, without a license, lists for $1195. It also has a proper VPN client, IPv6 support, two PoE+ ports, a much smaller footprint, no fan, etc. I'm extremely familiar with Cisco's firewall line, so the configuration differences aren't really a concern.
... View more
Apr 24 2020
10:48 AM
I was hoping I could get some input into what I might loose from a traffic analytics perspective if I remove the MX from my full stack environment. Right now I have an MX67, several MS120-8 switches, and a few MR42 APs. I'm considering dumping the MX67 for a Firepower1010 for the increased performance and IPv6 capabilities. If I remove the MX67, will I be missing out on some traffic analytics? Or, will the MS and MRs fill in the gaps?
... View more
Apr 19 2020
9:31 AM
What IP address do the PCs get when they're directly connected to the 881? I suspect the addressees being given by the 881 overlap with the addresses on the inside of the MX and thus it is not accepting the address.
... View more
I had the same problem with my HP wireless printer on 26.6.1. It was an ARP related issue which was corrected in 26.7.
... View more
Supposedly, in MR26.5. Sadly, I never did test the fix because MR26 had horrible DHCP intermittent failures on bridged mode SSIDs. I finally got so fed up with all the bugs in MR and MX that I ripped it all out and put in Ubiquiti hardware which has been flawless.
... View more
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
Jun 26 2019
1: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
Jun 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
Jun 14 2019
5:17 PM
4 Kudos
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
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
May 24 2019
5: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
May 3 2019
6: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
Apr 26 2019
4: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
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
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
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
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
Not sure why that matters? It's in VLAN 1, native VLAN, for management only.
... View more
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
Apr 24 2019
3: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
Apr 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
Apr 22 2019
4: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
Apr 22 2019
3: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
- « Previous
- Next »
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 10421 | Jun 14 2019 5:17 PM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 5 | 6792 | |
| 5 | 1881 | |
| 5 | 32314 | |
| 4 | 10421 | |
| 3 | 2793 |
© 2025 Cisco Systems, Inc.
