Meraki

Dunky · ‎Feb 14 2022

I too would love to be able to apply inbound rules on 3rd party S2S VPN. At present I have to permit all traffic in when in reality all I want is to permit http/https traffic to specific IP addresses

Dunky · ‎Feb 8 2022

Thanks for the replies chaps. So, to permit this one out, I have to remove the entire Peer-to-Peer category from my L7 rules and hence permit all the nasty stuff too. Doesn't this defeat the point of a firewall? Oh well, it is what it is, not very well thought out in my opinion, we should be able to whitelist specific traffic flows.

Dunky · ‎Feb 7 2022

Our MX has begun blocking outbound traffic as per below: In my L7 firewall rules we block All Peer-to-peer. How do I retain the L7 rule but permit this specific traffic as as exception. This is what I see against the client: Thanks an advance.

Dunky · ‎Feb 4 2022

I have an MX67 in the US connected to a 50Mbps Crown Castle circuit. I am seeing traffic spikes in excess of 300Mbps: The WAN1 Uplink is set to 50Mbps on the MX Uplink Configuration. This generates a number of queries: 1. How can this be? 2. How is traffic above the 50Mbps handled? 3. Should I shape the traffic to 50Mbps in the Traffic Shaping rules on the MX? 4. Is there a means of identifying the src of the spikes? Am experiencing drops on MS Teams calls and I am wondering if this is the culprit, more to the point how do I stop it? They are quick bursts and hence not picked up by any of the latency or utilization alerts I have setup in Meraki Insight. I am hoping someone has seen this before, or has experience of Crown Castle or any other ISP that exhibits this behaviour. TIA

Dunky · ‎Jan 21 2022

I'm not sure how it's resolving the FQDN then and then giving the error. When I add the dst IP to the L3 rule it works. Will have to do some reading up on Winscp but I'm using the exact same command and script - works if IP is added to L3 dst, does not work if only have FQDN in L3 dst.

Dunky · ‎Jan 21 2022

Hi CaptnCrnch Thanks for taking the time to reply. 1. Does MX also see your DNS request for your internal SFTP URL? It's kinda natural it's seeing a request for google.com, but how does your internal DNS setup look like? Is your MX standing "between" endpoint and its DNS resolver? Answer: it's an external SFTP server and the client is using the MX for DNS. 2. Have you cleared the DNS cache on your endpoint machine when testing? Answer: Yes, flushed cache beforehand and after the SFTP failed it had cached the correct public IP Address for it. So DNS resolves correctly for both examples, it's only the SFTP rule where the dst FQDN isn't getting matched. If I put the IP in the dst it works.

Dunky · ‎Jan 21 2022

This is in an MX84 running 15.44 I have an issue related to permitting traffic through the MX based on the L3 rule dst being defined as a domain name. The client points to the MX for its DNS. This works perfectly: L3 rule> Allow ICMPv4 src:Any dst:google.com A ping google.com on the client works, proving that the DNS snooping is working and the traffic is matching the name in the rule dst I have another example of using a domain name as the dst which DOES NOT work: Allow TCP src:<client IP addr> dst: <domainname> dst_port:22 We then have a scheduled job which executes this command file: C:\winscp\winscp.com /script=c:\winscp\scripts\getrecipe.txt /log="c:\winscp\scripts\getrecipe.log" /loglevel=0 /logsize=2*10K Exit The getrecipe.txt file contains the following command: OPEN SFTP://<username>:<password>@<domainname.com> -hostkey="ssh-rsa 1024 MKA*********************WelyJtFd **********" Which fails with an error unable to open <domainname.com> It resolves the name ok in DNS as we see it in the clients ipconfig /displaydns – for some reason the SFTP traffic is not matching the rule that permits it out. If I put the public IP address of the dst <domainname.com> in the dst then it works, proving the MX is not matching the name it looked up. So why does the PING L3 rule match using the dst domainname but the SFTP does not? Any ideas anyone as its driving me mad 🙂

Dunky · ‎Dec 23 2021

But it will show the VLAN and you can tell what port the VLAN is on - unless you have setup the MX ports as access ports?

Dunky · ‎Dec 23 2021

You can go to 'Tools' on the Appliance Status page and cick 'Run' next to ARP table. This will tell you what VLAN the MAC's are in which you can hopefully map to a port on the MX. It will obviously only have those that have not aged out, so maybe worth doing a ping across the entire subnet beforehand to populate the cache. HTH Steve

Dunky · ‎Dec 16 2021

I have endpoints yes but the handsets are not CIsco

Dunky · ‎Dec 16 2021

Luckily I don't have that issue, I have RSTP enabled and BPDU Guard enabled, and am running 14.32 🙂

Dunky · ‎Dec 16 2021

@mcvosi What's the problem with the Voice VLAN then? I am using it at a couple of sites with issues.

Dunky · ‎Dec 16 2021

I add my vote to this functionality. The supplier of our factory hardware is constantly connecting cheap unmanaged to our switches and hence a Meraki switchport allocated to support one particular device (e.g. a PLC) suddenly had lots of devices on it and we have no knowledge. What I would like is to either: a) Specify maximum concurrent MAC's on a switch port or; b) Using sticky MAC, for the MAC to be erased when the device is disconnected (hence allowing another client to be connected - i.e. on Hot Desks).

Dunky · ‎Dec 9 2021

Thanks, that's down to the guys that look after the Azure end. Just wanted to ensure that I am not somehow bridging those subnets via the vMX.

Dunky · ‎Dec 9 2021

If I don't want the Azure subnets to see each other though, can I use the firewall rules on the vMX to block inter-subnet traffic?

Dunky · ‎Dec 9 2021

Hi @PhilipDAth Sorry for replying to an old thread. If I add multiple subnets to the VMX LAN side,(ie in Azure), would the VMX bridge between the two? Would I use the L3 firewall on the VMX to prevent this behaviour? TIA

Dunky · ‎Nov 14 2021

@ospsms have you opened a case with Meraki? Would be good to get some confirmation of a firmware related issue as the number of alerts is just crazy.

Dunky · ‎Nov 14 2021

I have had alerts now from a subnet that has all static IPs on it so its deffo not related to duplicate addresses issued by DHCP

Dunky · ‎Nov 11 2021

@mcgruff MS210-24P 14.32

Dunky · ‎Nov 11 2021

There has got to be another cause to be generating literally hundreds of alerts across all sites. Any ideas anyone?

Dunky · ‎Nov 11 2021

I'm not convinced its related to duplicate IPs due to the volume and geographic spread I am seeing,. Could it be where a client has both a Wifi and ether connection?

Dunky · ‎Nov 10 2021

If you click on the new layout top right you will find the info in there. It's just no longer shown on the old page.

Dunky · ‎Nov 9 2021

Is there any documentation available on this yet? I've had over 600 alerts today across a dozen sites so it can't be related to duplicate IP addresses. My DHCP server is an MX at each site.

Dunky · ‎Oct 29 2021

Ahh yes, its in the switch section of the alerts, I had forgotten that this particular network was running later switch firmware to my others.

Dunky · ‎Oct 29 2021

I noticed a new alarm type in Network-wide>Alerts that appears to relate to this: Its appeared on my MX85 running 16.8. If enabled, options are ASAP, daily or weekly. Or you could disable - I cannot recall whether or not it was enable by default.

About Dunky

Dunky

Community Record

Badges