We've had some rumblings of Windows changing their transform sets off what we default to - a Support case can help you diagnose it further, and update it accordingly without needing to roll back any security patches on the client side. ... View more

FYI, Z1's cannot run firmware never than 14.x, so if you're having a problem on a Z1, it's not related to firmware most likely ... View more

If you're having issues, I would contact support and tell them you suspect it's an ID issue - there is logging we have access to when the tunnel is built that will determine if the root cause of this is an ID mismatch, and it should tell us what AWS is trying to present that's incorrect if so. ... View more

There's only three things it can be:   An FQDN you've set on that end A User FQDN (e.g. you@example.fake) A public or private IP Which one it needs depends wholly on your setup. If you haven't explicitly set 1 or 2 on the AWS side somewhere, then you'd use 3, but that should only be needed if the actual endpoint you're connecting to is behind a NAT. ... View more

FYI - this isn't a thing on MX 15 firmware ... View more

Yeah, this was the very problem I was hoping to resolve. It's rather disappointing that Cisco still hasn't fixed it in 3+ years considering how easier a single SA for everything makes it to troubleshoot (not to mention how much better it scales), but if nobody else knows of ways to get that to work, and if nobody else is going to chime in with other vendors that seemingly also fail to do multiple TS's per SA, I think I need to take some feedback about this with regards for IKEv2 and see if we can make the argument that it needs re-implementing. ... View more

Unfortunately, no you cannot source an exit VLAN for autoVPN beyond just tagging whatever traffic is egressing out the WAN port. ... View more

15.42.2 should be available as a patch release to correct this issue - this is indeed a known bug, and that release is intended solely to fix it. ... View more

Yes, you can use both modes concurrently. It's not possible to tunnel Z3 or Wireless MX SSIDs the way you described in your other post, but an autoVPN tunnel will still function more or less identically. Incidentally, internally-speaking, SSID tunneling and autoVPN function identically. ... View more

No net difference from what I can tell 😞   MX-to-ASA-ikev2-testing(config)# sho access-list 110 access-list 110; 2 elements; name hash: 0xe9cd5715 access-list 110 line 1 remark - this should allow for multiple traffic selectors in IKEv2 access-list 110 line 2 extended permit ip 10.99.99.0 255.255.255.0 192.168.0.0 255.255.255.0 (hitcnt=0) 0x6693a7e5 access-list 110 line 3 extended permit ip 10.100.100.0 255.255.255.0 192.168.0.0 255.255.255.0 (hitcnt=0) 0x4c2f28d1   The net result is the same in the debugging as well ... View more

I've been labbing this, and I can't seem to get it to behave differently - perhaps you can point out what I'm doing wrong here.   Here's my object group:   MX-to-ASA-ikev2-testing# sho object-group id IKEv2 object-group network IKEv2 description: Local Subnets for IKEv2 VPN network-object 10.99.99.0 255.255.255.0 network-object 10.100.100.0 255.255.255.0   From there, I bound it to an extended ACL    MX-to-ASA-ikev2-testing# sho run | b access-list access-list 90 extended permit ip 172.24.6.0 255.255.255.0 172.24.0.0 255.255.255.0 access-list 110 remark - this should allow for multiple traffic selectors in IKEv2 access-list 110 extended permit ip object-group IKEv2 192.168.0.0 255.255.255.0 # 192.168.0.0/24 is the remote on the MX   And then finally the crypto map:   MX-to-ASA-ikev2-testing# sho run | b crypto crypto ipsec ikev2 ipsec-proposal SECURE protocol esp encryption aes-256 aes-192 3des protocol esp integrity sha-1 md5 crypto ipsec security-association pmtu-aging infinite crypto map MXMap 20 match address 110 crypto map MXMap 20 set peer 172.24.0.13 crypto map MXMap 20 set ikev2 ipsec-proposal SECURE crypto map MXMap 20 set security-association lifetime seconds 28800 crypto map MXMap 20 set security-association lifetime kilobytes unlimited crypto map MXMap interface outside crypto ca trustpool policy crypto ikev2 policy 1 encryption 3des integrity sha group 2 prf sha lifetime seconds 28800 crypto ikev2 enable outside   The tunnel is coming up between them, but with the ASA as the responder, it's still only using one of the two proposed traffic selectors: MX-to-ASA-ikev2-testing# sho crypto ikev2 sa IKEv2 SAs: Session-id:3, Status:UP-ACTIVE, IKE count:1, CHILD count:1 Tunnel-id Local Remote Status Role 20632227 172.24.6.129/4500 172.24.0.13/4500 READY RESPONDER Encr: 3DES, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK Life/Active Time: 28800/818 sec Child sa: local selector 10.99.99.0/0 - 10.99.99.255/65535 remote selector 192.168.0.0/0 - 192.168.0.255/65535 ESP spi in/out: 0x828dcbf7/0xc1d5d2dc This, in spite of the fact that debugging shows it received selectors for both of its local subnets (don't mind the fact that NTP isn't working): Jan 02 2003 19:38:32: %ASA-7-711001: (4): Num of TSs: 2, reserved 0x0, reserved 0x0 Jan 02 2003 19:38:32: %ASA-7-711001: (4): TS type: TS_IPV4_ADDR_RANGE, proto id: 1, length: 16 Jan 02 2003 19:38:32: %ASA-7-711001: (4): start port: 2048, end port: 2048 Jan 02 2003 19:38:32: %ASA-7-711001: (4): start addr: 192.168.0.1, end addr: 192.168.0.1 Jan 02 2003 19:38:32: %ASA-7-711001: (4): TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16 Jan 02 2003 19:38:32: %ASA-7-711001: (4): start port: 0, end port: 65535 Jan 02 2003 19:38:32: %ASA-7-711001: (4): start addr: 192.168.0.0, end addr: 192.168.0.255 Jan 02 2003 19:38:32: %ASA-7-711001: (4): TSrJan 02 2003 19:38:32: %ASA-7-711001: (4): Next payload: NOTIFY, reserved: 0x0, length: 56 Jan 02 2003 19:38:32: %ASA-7-711001: (4): Num of TSs: 3, reserved 0x0, reserved 0x0 Jan 02 2003 19:38:32: %ASA-7-711001: (4): TS type: TS_IPV4_ADDR_RANGE, proto id: 1, length: 16 Jan 02 2003 19:38:32: %ASA-7-711001: (4): start port: 2048, end port: 2048 Jan 02 2003 19:38:32: %ASA-7-711001: (4): start addr: 10.99.99.2, end addr: 10.99.99.2 Jan 02 2003 19:38:32: %ASA-7-711001: (4): TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16 Jan 02 2003 19:38:32: %ASA-7-711001: (4): start port: 0, end port: 65535 Jan 02 2003 19:38:32: %ASA-7-711001: (4): start addr: 10.99.99.0, end addr: 10.99.99.255 Jan 02 2003 19:38:32: %ASA-7-711001: (4): TS type: TS_IPV4_ADDR_RANGE, proto id: 0, length: 16 Jan 02 2003 19:38:32: %ASA-7-711001: (4): start port: 0, end port: 65535 Jan 02 2003 19:38:32: %ASA-7-711001: (4): start addr: 10.100.100.0, end addr: 10.100.100.255 ... View more

That would be the sort of thing you should open a Support case over then; ideally try to demonstrate the problem as it happens to them, so that logging can be collected as it occurs to determine the cause of the conflict. ... View more

Yes, that'll work ... View more

We have to close existing tunnels when non-Meraki VPN is reconfigured on Dashboard because of how the ipsec process we use needs to be reconfigured internally. This is likely going to be hard to make work however, because non-Meraki VPN is policy-based; if we get a packet bound to 192.168.20.0/24 when a tunnel to the remote with 192.168.0.0/16 as a subnet is defined, it will match on the existing policy; there aren't considerations for longest-prefix matching in this context. ... View more

Are the alerts in question being thrown by traffic directed to the MX's WAN/Public IP? If so, you're going to see "Allowed" as a decision, because the IDS sees and processes packets before the inbound firewall does. If there are no port forwards, or other static NAT rules in place that permit that traffic, the IDS will alert that it's seen a payload matching a signature, and start waiting for additional traffic to drop. If no more comes - in this case, because the packet in question never gets a response because the inbound firewall dropped it - the IDS effectively cannot block any further traffic, so it notes it as Allowed. ... View more

@PhilipDAth wrote: In Cisco Enterprise space, like on an ASA, you can configure it to request all the subnets at once in the encryption domain in a single SA, or to request them using multiple SAs.   You use a single access-list entry to request them all at once (using object groups). You use multiple access-list entries to request them one at a time.   When you get it to use multiple SAs to a Meraki, Meraki sees the attempts to add additional SAs as a request to REPLACE the original SA, rather than add.  So that approach doesn't work. This is correct, and at the root of the problem; the daemon we use bundles all the traffic selectors under a single child SA, so if a peer does selector narrowing, we'll build a policy with just those narrowed selectors, and reject any further attempts to build additional SAs because they match to what is technically an existing one.   I appreciate the tip about access lists though, and will do some following up on that end of things. ... View more

msg: phase1 negotiation failed due to time up. 655a6651df312eb6:0000000000000000"     This means the MX is trying to build an IKE peering with your SRX, and not getting a response. Specifically, that string of hex values you see - before the colon - is the initiator cookie of the first message we're trying to send to the SRX, and the fact that the responder cookie is all zeroes means we didn't get any response from it at all. ... View more

With MX's it gets a little funky admittedly; vap0 is indeed normally what MR's use for their first SSID, but for wireless MX's and Z1s and Z3s, the first SSID is actually vap1.   So what is vap0 used for on MX? Without getting too deep into the weeds, it's reserved specifically as a mechanism to apply things like content filtering, L7 firewall, and other settings to devices and VLANs that don't otherwise already have a group policy applied to them, which is why you sometimes see it referred to as the MX reserved SSID in errors. ... View more

For what it's worth, the site-to-site VPN is stateless, so it will block the return traffic if you set up two outbound rules on the MX that only permit what you want to that host, and then deny all else. E.g. something like permit TCP 10.2.2.2/32:80 10.1.1.0/24:any and deny any 10.2.2.2/32:any any:any should do what your example asks for ... View more

This one's a popular internal question with newer people on our support team, so just for some additional context here: the pre-loaded categories contain hundreds of thousands, up to millions of URLs. Unless you're really determined, you're not likely to ever be able to outpace any of those 🙂 ... View more

Hello,   That information you cited is out of date - IKEv2 is now freely selectable on the site-to-site VPN page without Support involvement   ... View more

If anyone's confused at why this happened, please refer to the following KB: https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Product_Firmware_Version_Restrictions#MX   Quoting the relevant detail here:   "Z1s, MX60/Ws, MX80s and MX90s cannot upgrade to MX 15 firmware, or any newer major release versions. If networks containing these devices are configured to run newer firmware revisions, they will run the newest MX 14 maintenance release instead." ... View more

The 14.2 update will only fix the duplicate IP alert issue - it will not change anything else as far as we're aware ... View more

Fair warning too, that devices with policies do not age out after 30 days continual of inactivity like those without them do either, so you may end up having to deal with cleaning up old policy entries as a result of this. ... View more