Meraki

BrechtSchamp · ‎Dec 5 2019

Wow time has flown! We'll be cleaning the couches before the new all-stars com in.

BrechtSchamp · ‎Dec 5 2019

Hi Tim. Where did you configure the rules? You need to configure them in the Security & SD-WAN > Site-to-site VPN page. There's a section called Site-to-site outbound firewall there. More info here: https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-site_VPN_Firewall_Rule_Behavior

BrechtSchamp · ‎Dec 4 2019

Glad I could help.

BrechtSchamp · ‎Dec 4 2019

MR45 uses MA-MNT-MR-14 so it's different.

BrechtSchamp · ‎Dec 4 2019

Probably not. They have always been different so far: https://meraki.cisco.com/products/wireless/mount-kits They're always included though.

BrechtSchamp · ‎Dec 4 2019

Disclaimer, I have no experience with the Yamaha devices so all of the below may not work at all. I think however that you'll have most luck if you explicitly configure the hashing, encryption and lifetime values of both phases in the Yamaha router. Something like this: tunnel select 1 description tunnel MERAKI-TUNNEL ipsec tunnel 101 ipsec sa policy 101 1 esp aes-cbc sha-hmac ipsec ike duration ipsec-sa 1 28800 ipsec ike duration isakmp-sa 1 28800 ipsec ike encryption 1 aes-cbc ipsec ike group 1 modp1024 ipsec ike hash 1 sha ipsec ike keepalive log 1 off ipsec ike keepalive use 1 on dpd 5 4 ipsec ike local address 1 172.31.8.254 ipsec ike local id 1 172.31.8.0/24 ipsec ike nat-traversal 1 on ipsec ike pfs 1 on ipsec ike pre-shared-key 1 text [A-removed] ipsec ike remote address 1 [B-removed] ipsec ike remote id 1 172.31.2.0/24 ip tunnel tcp mss limit auto tunnel enable 1 With on the Meraki end this: I hope this will work.

BrechtSchamp · ‎Dec 2 2019

Very well deserved @DexterLaBora , you could've gotten this one a long time ago. @kuni , I'm glad that this time someone asking the questions got recognized. If not for that, we wouldn't be able to help! Thanks! Congrats to the rest of the gang. Again our scores were so close! I mean 117, 118, 119... Really?

BrechtSchamp · ‎Dec 2 2019

Yes, or maybe something like this: https://www.network-cabs.co.uk/acatalog/1u-and-2u-Recessed-Brackets.html

BrechtSchamp · ‎Dec 2 2019

That's unfortunate. I think the MS390 will offer more flexible brackets like the traditional Cisco line. But that doesn't help you either I suppose?

BrechtSchamp · ‎Dec 2 2019

Would these help you (MA-MNT-MID-1): https://documentation.meraki.com/MS/Installation_Guides/MS_Mid-Mount_Mounting_Brackets I believe they're also compatible with at least the MS225 switches, even though that page doesn't mention them.

BrechtSchamp · ‎Dec 2 2019

According to this it does, sort of: https://jackofallit.wordpress.com/2016/03/02/meraki-ap-syslog-user-id-to-palo-alto-firewall/ Apparently the IP address is 0.0.0.0 on the first authentication, but filled in in consecutive tries. Note: I haven't tried this. Also, kudos to Jack, whoever he is.

BrechtSchamp · ‎Dec 1 2019

The latest news I have seen was: All of our 802.11ac Wave 2 Access Point customers will receive the latest WPA3 functionality via a seamless cloud update. Source: https://meraki.cisco.com/blog/2018/03/wi-fi-standards-on-the-move-again/ No word on timing.

BrechtSchamp · ‎Nov 27 2019

If I understand correctly you have both the draytek as well as the MX connected to the old and new VLANs? I think this will cause issues, as both may be doing DHCP and may be routing for the networks. Imo it's better to have one router dedicated to each subnet and interconnect the routers for the communication in between the two VLANs.

BrechtSchamp · ‎Nov 27 2019

You haven't specified much about your Meraki network. Do you have a Meraki MX? I'm going to assume you do, as you're posting this in the Security & SD-WAN subforum. Ideally you could give your MX it's own internet connection independent of the Draytek one. What I would do in that case is connect the Draytek's LAN port to the Meraki MX LAN port. I'd create a separate /30 subnet specifically for this link. Then you setup a route on the MX pointing with you Draytek subnet (172.31.109.0/24) with the next hop the Draytek address on this /30 subnet. Also a route to the Wireless subnet (192.168.65.0/24) with the next hop the Draytek address on this /30 subnet. Inversely, on the Draytek you'll need a route pointing to the Meraki subnet (192.168.48.0/22) with as next hop the Meraki MX's address on the /30 subnet. Make sure you also open up all firewalls accordingly. That means, the draytek, the MX, but also the endpoints (servers sometimes restrict pinging to their own subnet).

BrechtSchamp · ‎Nov 26 2019

All right, thanks for the feedback, that makes sense! I'll refer to the official docs for the full information.

BrechtSchamp · ‎Nov 26 2019

You are fast sir! I'm sorry if I may have come across as negative in my post. That was definitely not the intention. That does seem like a lot of progress. I love the fact that it's built dynamically instead of manually. I had noticed that the API key had moved to these temporary headers. Basically the collection variables are an alternative to setting up an environment, correct? How about the documentation for the body though? In the example I gave of the createOrganizationNetworks endpoint, the bulk of the interesting payload is in there rather, than in the params. Questions I have are for example, what name/value pairs can be put in, which ones are obligatory, which ones are optional, what's the syntax of the value? The specific issue we had in the other topic was that the postman collection didn't mention the copyFromNetworkId anywhere.

BrechtSchamp · ‎Nov 26 2019

Does anyone know what's up with the postman collection. I've installed the new version a while ago and it seems like some things changed... for the worse. I was confronted with this fact thanks to this topic and the discussion with @Raphael_M : https://community.meraki.com/t5/Developers-APIs/Clone-existing-network-configuration-while-creating-a-new/td-p/68706/jump-to/first-unread-message Here's some screenshots: Old: New: As you can see the new version gives a lot less information. You can deduce a lot from the body in the lower part, but still, why was the top information deleted? It seems like the url doesn't use the {{organizationId}} placeholder anymore. It does still seem to work, so this may just be another syntax for the same thing. What gives? The copyFromNetworkId parameter isn't mentioned anywhere in the new version. Maybe it was omitted for a reason, maybe not? @DexterLaBora , is this something you can help out with?

BrechtSchamp · ‎Nov 25 2019

Well if you're using requests you can do it using, just as it says in the example I posted earlier: response.headers["Retry-After"]

BrechtSchamp · ‎Nov 24 2019

A bit higher on the same page, it would be something like this:

BrechtSchamp · ‎Nov 24 2019

All right. Why don't you use the L3 firewall rules?

BrechtSchamp · ‎Nov 24 2019

Is this range in your network or on the internet?

BrechtSchamp · ‎Nov 24 2019

Can you share some details about the firewall rules you've defined? I can try to reproduce it on my MX64.

BrechtSchamp · ‎Nov 24 2019

Good point @Uberseehandel . Here in Belgium our providers use a router-modem-combo to terminate the connections, so that isn't so much an issue. V4 or v6 doesn't matter anymore then. My MX just has a private v4 IP on its WAN side and I have the MX defined as "DmZ host" in the provider router, which basically forwards all traffic to the MX. But this all depends on how the providers work I guess.

BrechtSchamp · ‎Nov 23 2019

I think MX67 didn't exist back when @jdsilva got his MX64, but I agree. MX67 may be the better choice.

BrechtSchamp · ‎Nov 23 2019

So what turned out to be the issue?

About BrechtSchamp

BrechtSchamp

Community Record

Badges