Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- About Coupe2112
About Coupe2112
Community Record
23
Posts
14
Kudos
1
Solution
Badges
Nov 15 2022
12:59 PM
6 Kudos
Our department Christmas tree is made from old PC components (and a string of lights)!
... View more
Sep 7 2022
5:55 AM
1 Kudo
+ us too
... View more
May 25 2022
6:09 AM
2 Kudos
This morning I created a new vlan on the hub MX for one of it's two WAN connections then created a static default route and added it to the VPN routing table. The hub MX seemed fine and I was still able to ping the gateway address of the network in question via the non-Meraki vpn I'm trying to run as full tunnel. I had no way to test from a client given that I was remote from that network during the test. When I checked the routing table of a Meraki vpn peer, I saw both it's local default route as well as the injected statically created default route from the hub MX. Question, when I look at the new route table view, are the routes listed in order of priority? I saw them both and the vpn learned route was listed above the local default route. When I did a traceroute from the remote site's MX to the internet (from it's 'internet' port) it went directly out the local internet connection (meaning it did not use the vpn tunnel). However, devices downstream from the MX (i.e. the switch) lost connection to the Meraki cloud and a traceroute from a client device at a Meraki vpn site to the internet failed at it's network gateway address. Meaning once the traffic hit the MX it died, I suspect because it was trying to route via the hub MX and failing. As soon as I removed the hub MX static default route everything returned to normal. I did not troubleshoot the switch (and downstream device) routing failure because it isn't really what I wanted. I expect I could add static default routes (excluded from the vpn) on each remote MX but that's an undesirable answer. I think it boils down to the less than full ability to weight and manipulate routes as you would have in a full function network device due to the nature of the cloud managed solution. I still have a couple of alternatives for my particular use case but not having this ability is disappointing.
... View more
May 24 2022
7:02 AM
I've got a similar situation to this but am landing the non-Meraki vpn tunnel on an MX that has an additional non-Meraki tunnel as well as about 40 auto-vpn tunnels. I only want the full tunnel on the new non-Meraki tunnel and am wondering how, in particular, the auto-vpns will act if I add a static default route and add it to the vpn. Will the prefer their local default route (what I'd want) or the learned? It seems logical to me that the local default route would be preferred over one learned via vpn. I'm planning on doing a test tomorrow. I'll update with my results.
... View more
Oct 31 2018
11:58 AM
Thanks. If you read through my conversation with PhillipDAth you'll see that I did just that both on the radius server and the MX. I was getting ACCEPT packets and they were being seen by the MX. In the end, radius *was* failing between the client (MX) and server (M$ NPS) because the PSK was too complex and I needed to remove non-alphanumeric characters. It doesn't explain why I was getting the ACCEPT which was seen by the MX and was failing between the LAN interface and the Client VPN.
... View more
Oct 31 2018
9:13 AM
So I was finally able to get this working. Upon the suggestion of Meraki's support, I simplified the PSK for radius authentication between radius client and server by removing any non-alphanumeric characters. I made it extremely long to try to keep it secure (24 characters) but at least it's working now. It seems like a shortcoming to me but at the very least I think it should be documented to not use non-alphanumeric in that PSK. Anyway, there it is. Thanks for reading.
... View more
Oct 29 2018
12:47 PM
LOL This is the same thing Meraki support sent me to. I am using M$ NPS, I used the guide to configure it and I've reviewed the settings about a dozen times in the last two and half days. I appreciate the feedback because sometimes just talking it through leads to the 'A-HAH!' moment (and I definitely could have missed something). I'm looking for something a bit deeper than the basics though. I'm using radius authentication all over the place for access to my ASA firewalls, Cisco IOS and Nexus devices (with multiple levels of access), ASA and Firepower remote access vpns, and my open source IPAM server so I'm definitely familiar with configuring it. 🙂
... View more
Oct 29 2018
12:41 PM
Those are in the request, not the accept.
... View more
Oct 29 2018
11:31 AM
It is a domain account. Good call on adding the domain. I'll give that a shot. Yes, I am seeing an 'ACCESS_ACCEPT' message. I opened a ticket with Meraki support who said back end logs were showing authentication failure. Obviously that doesn't make a lot of sense given that radius is confirming the password. I've done a second capture on the MX lan port and confirmed that the MX is also receiving the 'ACCESS_ACCEPT' packet. UPDATE: I had been using my email account but I tested with 'username', 'public_domain\username', and 'private_domain\username' with no luck. In all three cases, the radius 'ACCESS_REQUEST' shows the correct value and radius completes the authentication.
... View more
Oct 29 2018
9:11 AM
I have configured a Client VPN on this MX device. When using Meraki Cloud authentication it works without issue. When I enable radius authentication it fails. I have performed a packet capture on the radius server and see successful authentication requests validating that radius is functioning correctly. This is failing for both an Android client (ver. 9 build PPR2.181005.003) and Windows10 Enterprise (ver. 1709 build 16299.611) Below are log entries. It looks to me like it's simply timing out. Oct 29 08:28:15 Non-Meraki / Client VPN negotiation msg: ISAKMP-SA established x.x.x.x[4500]-y.y.y.y[4500] spi:f7576fb374b0f3a5:75cfbc1463066f9b Oct 29 08:28:16 Non-Meraki / Client VPN negotiation msg: IPsec-SA established: ESP/Transport x.x.x.x[4500]->y.y.y.y[4500] spi=68336299(0x412baab) Oct 29 08:28:16 Non-Meraki / Client VPN negotiation msg: IPsec-SA established: ESP/Transport x.x.x.x[4500]->y.y.y.y[4500] spi=125451427(0x77a3ca3) Oct 29 08:28:21 Non-Meraki / Client VPN negotiation msg: purged IPsec-SA proto_id=ESP spi=125451427. Oct 29 08:28:21 Non-Meraki / Client VPN negotiation msg: ISAKMP-SA expired x.x.x.x[4500]-y.y.y.y[4500] spi:f7576fb374b0f3a5:75cfbc1463066f9b Oct 29 08:28:21 Non-Meraki / Client VPN negotiation msg: ISAKMP-SA deleted x.x.x.x[4500]-y.y.y.y[4500] spi:f7576fb374b0f3a5:75cfbc1463066f9b My confusion is why the different behavior going from cloud auth to radius when I can confirm that radius is working. Has anyone seen this before? Any suggestions?
... View more
Labels:
- Labels:
-
Client VPN
Oct 29 2018
9:10 AM
I have configured a Client VPN on this MX device. When using Meraki Cloud authentication it works without issue. When I enable radius authentication it fails. I have performed a packet capture on the radius server and see successful authentication requests validating that radius is functioning correctly. This is failing for both an Android client (ver. 9 build PPR2.181005.003) and Windows10 Enterprise (ver. 1709 build 16299.611) Below are log entries. It looks to me like it's simply timing out. Oct 29 08:28:15 Non-Meraki / Client VPN negotiation msg: ISAKMP-SA established x.x.x.x[4500]-y.y.y.y[4500] spi:f7576fb374b0f3a5:75cfbc1463066f9b Oct 29 08:28:16 Non-Meraki / Client VPN negotiation msg: IPsec-SA established: ESP/Transport x.x.x.x[4500]->y.y.y.y[4500] spi=68336299(0x412baab) Oct 29 08:28:16 Non-Meraki / Client VPN negotiation msg: IPsec-SA established: ESP/Transport x.x.x.x[4500]->y.y.y.y[4500] spi=125451427(0x77a3ca3) Oct 29 08:28:21 Non-Meraki / Client VPN negotiation msg: purged IPsec-SA proto_id=ESP spi=125451427. Oct 29 08:28:21 Non-Meraki / Client VPN negotiation msg: ISAKMP-SA expired x.x.x.x[4500]-y.y.y.y[4500] spi:f7576fb374b0f3a5:75cfbc1463066f9b Oct 29 08:28:21 Non-Meraki / Client VPN negotiation msg: ISAKMP-SA deleted x.x.x.x[4500]-y.y.y.y[4500] spi:f7576fb374b0f3a5:75cfbc1463066f9b My confusion is why the different behavior going from cloud auth to radius when I can confirm that radius is working. Has anyone seen this before? Any suggestions?
... View more
Oct 24 2018
7:11 AM
So here's an update. As expected, it finally checked in shortly after I left for the day. We tried something seen elsewhere, un-claiming, resetting, re-claiming then adding the MX to the desired network. It came online within a few minutes. While I understand and agree with the replies regarding the need to upgrade code, these MXes haven't been offline that long (no more than a week or so) so they shouldn't be badly out of date and it doesn't explain the trickle of data I see on a link that otherwise runs at expected speeds. I'm not convinced that there isn't something else going on.
... View more
Oct 23 2018
1:55 PM
I've run into this problem now for the second time in two weeks. The Sunday before last I was called because the MX64 at that location was taking an extended amount of time to check into the Dashboard. Multiple reboots and resets were attempted to no avail. It was using a 4G gateway as it's WAN link and a laptop directly connected to that gateway worked without issue. A call to Meraki led to an RMA being processed for the MX however when I got to work on Monday morning the MX had checked in. We decided to proceed with the replacement to be safe. No outbound traffic is blocked so the rules detailed in the MX Help>Firewall menu shouldn't come into play because access to those IPs on those ports is allowed. Today I was trying to provision a couple of full stacks and ran into the same issue. The connection was attempted using three different MXes and 4 different network links including two different 4G gateways. Again a connected laptop worked without issue. Currently I have the MX connected on an access port normally used for my test set. When I watch traffic on that port I see a trickle (4-7 packets per second). This is on a 100Mb connection so speed shouldn't be an issue. In all cases, I'm getting the rainbow of lights as the device attempts to register. My plan is to leave the MX running overnight and hope it has checked in by the morning. I'm wondering if anyone else has run into this because we provision our gear before shipping but at this rate I better start on my January networks now. This particular hardware is being re-used (it's not new out of the box) but was removed from the old network which was then deleted returning it to inventory from where it was then added to the new destination network. Pings to the LAN facing IP address of the MX, even sourced from the gateway address fail despite being arp'ed, the port being up and it passing the small amount of traffic it is.
... View more
Jun 19 2018
2:11 PM
I'm going through the same thing now, in particular with Facebook (what a PIA) and had to whitelist the following to finally get it to work fully (for now)... facebook.com doubleclick.net fbcdn.net l.facebook.com external-ams3-1.xx.fbcdn.net static.xx.fbcnd.net scontent-ams3-1.xx.fbcdn.net
... View more
Mar 20 2018
7:47 AM
4 Kudos
My spring cleaning project began with a basement flood and ended with additional shelving, an organized workshop and a large box of water soaked cardboard heading to recycling...
... View more
Mar 14 2018
7:04 AM
It's possible but not probable. The device is used as a mobile PoS terminal and is carried around the location. We've only got two waps so it's possible that it stays associated to just the one but as I look through log entries I see historically it and other devices moving between the two or re-associating after having been turned off or going to sleep.
... View more
Mar 13 2018
1:32 PM
I have an iPad which was in use and showing connected to my wireless network however the last logged association to a WAP was two days previous. I get that if it remained on and connected to that particular WAP there shouldn't be another event but given that it was two full days (let's even call it a day and a half) and there is no way the device was on for the entire period (the location would have shut down for the night twice) it seems odd to me that I don't see a fresh association message being logged. Thoughts?
... View more
Dec 5 2017
8:53 AM
1 Kudo
I'm so happy to have received the email about the Community page! This is something I was asking about from the first when we decided to deploy Meraki. We're a fashion company with about 70 retail locations. Installing Meraki has been an absolute life saver as we get into the holiday season! -Coupe2112
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 7437 | Oct 31 2018 9:13 AM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 6 | 6711 | |
| 4 | 20414 | |
| 2 | 3144 | |
| 1 | 14409 | |
| 1 | 81723 |
© 2024 Cisco Systems, Inc.
