About NolanHerring

NolanHerring

@jdsilva What the heck lol. Well thanks for finding that for me.

RobertDitusa

I know. I will not get rid of the old firewall till i know everything is working correctly with this MX65.

PhilipDAth

Good discovery @NolanHerring - thanks for letting everyone know.

Jos_HS

Thank you very much to all for the information and the tips sent, analyzing in depth I chose to place in the option of Block/white URL's of the policy: APPEND. With this when the client requests a massive change I use an API that adds the URL (block / white) in the general content filtering and with this applies to the group policy that has been created in each Meraki. Of course in this time I have to enter one by one on each device to add the config however for the future it will no longer be necessary.

jdsilva

@HCAD If your SFP is supported it should show up on the switch port details page.

jdsilva

I'm interpreting this the same as @ww , and the best answer there I think is the API. https://api.meraki.com/api_docs#update-the-l3-firewall-rules-of-an-mx-network

Oskar

@MOT Don´t worry, this has happened to me too. Kudos to @BrechtSchamp for being fastest.

PhilipDAth

Hmm, that is interesting. I was just looking at a clients MX, and they have manual port forward configured and have dual WAN circuits. We are using SD-WAN - and the WAN ports are running AutoVPN active/active - and it is working. One thing of note though is that their WAN2 has a public IP directly on it - so no NAT is required for AutoVPN to WAN2.

SDMAOps

Nolan, Thank you for your suggestion and link. I did look at Groups, but was not sure if that was the correct way to go; I will check out your advice.

greaper

Yes, Wi-Fi calling using the regular phone mechanism on the cell phones. This specific location is located in a basement that has very poor cell phone service. I am being told that it is both IOS and Android devices but I will confirm that. I can't specifically say right now if it applies to all providers but I will investigate that.

PhilipDAth

If it was me, I would just expand your pool of IP address space for the devices that are attaching. Note that you do expose yourself to a possible DHCP exhaustion attack using the approach you are using (and you are in a school ...). With a DHCP exhaustion attach you can download existing attack tools, and all they do is send DHCP requests using different MAC addresses until the DHCP server has no IP address space left to give out to real clients. The second approach I would use is to just use a NAT mode SSID. With 16 million IP addresses it makes a DHCP starvation attack improbable. With the hashing method that Meraki uses with a NAT mode SSID to generate DHCP client addresses - it is probably impossible.

Nash

Having to do it for every shard makes sense. Propagation can be fussy. I hope you all get it resolved soon - if it's frustrating for me, it must be worse for the support staff at Meraki who are trying to fix.

jdsilva

Oooooh! I misunderstood. You're asking if Meraki has DNSSEC available on their own domains. Gotcha. It doesn't look like they support it.

PhilipDAth

I typically find changes happen within 30s, but very ocassionally you get issues like this where it takes ages for the changes to take affect.

NolanHerring

MX would be per-network You 'could' tunnel everything to one but depending on your setup, might not be the best option.

Raigan21

what a pain in the ass, thanks any way i will try with the EAP- TLS

GreenMan

If your MX84 is using AutoVPN (Meraki to Meraki site-to-site VPN), you might need to turn it back on again, but the underlying config will still be there; under Security & SD-WAN > Configure > Site-to-site VPN make a note, on the MX84 setup, as to whether it's set Hub or Spoke, then re-apply this after you put the replacement MX in.

CarlosAlmeida

Esse era comercializado pela Vivo para consumidor final CPF.

Cmiller

It happens to the best of us.... Glad you got it fixed!

JQ

On the Meraki side, there are no firewalls rules. There are firewall rules on the broadband modems (I assume), but the Z3 are able to established VPN to other MX68. So the broadband modems does allow UDP traffic for MX68 VPN connections. So the three locations experienced issue are using 192.168.0.0 and NATed on the modem. The corporate networks are using 10.0.0.0. Where on AWS vMX security policy that control the peer WAN uplink private IPs?

NolanHerring

If you want to do this via API I believe this command will do it. curl -L -H 'X-Cisco-Meraki-API-Key: <key>' -X GET -H 'Content-Type: application/json' 'https://api.meraki.com/api/v0/organizations/[organizationId]/deviceStatuses' Successful HTTP Status: 200 [ { "name":"My AP", "serial":"Q2XX-XXXX-XXXX", "mac":"00:11:22:33:44:55:66", "status":"online", "lanIp:"1.2.3.4", "publicIp":"4.3.2.1", "networkId":"N_1234" } ] Or possibly this one here curl -L -H 'X-Cisco-Meraki-API-Key: <key>' -X GET -H 'Content-Type: application/json' 'https://api.meraki.com/api/v0/organizations/[id]/inventory' [ { "mac": "00:18:0a:12:2d:da", "serial": "Q2AT-Z8Q8-7TPH", "networkId": "L_646829496481095660", "model": "MC74", "claimedAt": "1483748363.47231", "publicIp": "198.27.198.2" } ]

Nash

For this problem, the best solution is to install the 14.x beta firmware. It prevents AMP from getting "indigestion" and blocking downloads based on false positives. My procedure is: Restart AMP: disable it, save, wait for MX to update its config, then re-enable it. Enable beta firmware under Network wide->General and schedule an update for maintenance window via Organization->Firmware Updates.

NolanHerring

Feel free to toss into that wish, 'solve world hunger'.

NolanHerring

Air Marshal can email alert you for rogue detection and spoofing. However, the rogue detection portion is a tad broken because if you have a mobile device, say an iPhone on your wireless. If that iPhone for whatever reason leaves your wireless, and decides it wants to spin up its own hotpot. The system will detect this as a rogue for one reason, which is 'seen on LAN'. However this obviously isn't true because its an iPhone, which cannot actually connect to the LAN side. It's a shortcoming with the way the system works in how it 'thinks' it is on the LAN, only because it was previously on your network via using your wireless. I consider those to be false positives, and ignore them. The spoofing part however seems to work rather well in that it will automatically determine if someone is spoofing based on any of your SSID's that you have operating, and alert you as such. As @jdsilva mentioned, you will need to be very cautious because legally (in the USA at least) your not allowed to block/deny anyone because its an unlicensed spectrum and doing so is against FCC regulation. The only time that I'm aware of in which you can 'sort of legally' do it is if they are maliciously spoofing your SSID (man-in-the-middle/honeypot style). Even then I still prefer to play it safe and be alerted and take physical action vs blocking automatically.

NolanHerring

Glad you figure it out. If I were you, I would enable the email alert for DHCP Pool Exhaustion so in the future you know before hand =)

NolanHerring

Nolan Herring

Community Record

Badges