Hi @Stallone,   I will share my understanding:   "Could you please explain why traffic that goes through the VPN tunnel from on-premises resources is not blocked by the vMX instance's security group" It is not blocked by the Security Group because of the very nature of VPN. The vMX is a software that acts as the encryption termination point for your VPN tunnel, inside the EC2 instance; this means the ENI of the EC2 instance only sees encrypted traffic (in this case, Auto VPN traffic, which uses UDP encapsulation, choosing UDP ports in high ranges, 32768-61000 last I checked).   Try this: - Setup VPC Flow logs for the vMX ENI. Pick the destination you prefer (CloudWatch Logs or an S3 bucket, depending what the type of permissions you have in AWS). Now ping through the tunnel (for example, from on-prem to an EC2 instance behind the vMX inside the VPC - or anything through the tunnel, in whichever direction). Check your VPC Flog logs, you won't see any of those ICMP packets (except the vMX itself pinging 8.8.8.8 for connectivity checks, which happens outside the tunnel, so you will see those), you will only see the outer encapsulation, meaning UDP packets on high port ranges which are for the tunnel between the vMX and the on-prem MX, as well as packets towards the Meraki VPN Registry on UDP 9350-9381.   As an analogy, it's a bit like you establishing a VPN from your laptop (representing the vMX) towards somewhere on the internet (representing your on-prem MX), your network firewall (representing the EC2 ENI) won't see what you do inside the tunnel, will only see the outer encapsulation.   "while traffic going from AWS to the on-premises resources is blocked?" Can you share what test led you to this conclusion? Are you actually referring to this: "yes traffic from the another EC2 instance was blocked"? Because if that's the case, the traffic is blocked because once the vMX decrypts it, it sends it to the other EC2 instance unencrypted, so the ENI will see the ICMP packets. If you mean traffic from AWS to on-prem is blocked when you block all outbound traffic on the vMX ENI, that is because if you do so (block all outbound), then the result is you are actually causing the tunnel to drop eventually (I say eventually because the tunnel may stay up for some time, but soon will drop. Or if you reboot the vMX you will see the tunnel won't come back up), because you are effectively blocking the vMX connectivity to the Meraki cloud and to your MX on-prem.   Let me know if your tests tell you otherwise. ... View more

Hi @Stallone,   Are you pinging the public IP or the private IP of the vMX? Are you pinging from a host across the VPN tunnel?   If you are pinging the private IP of the vMX through the VPN tunnel, then look into the VPN firewall rules as shared by Philip in one of the replies, you can block ICMP there. After you add the rule in the dashboard, give the MX a few moments to ensure the config is updated ('Up to date' status) on the device.   "I am still able to ping my resources in the AWS VPC from my on-premises network." My understanding is that this is expected as you are tunneling traffic into the EC2 (effectively a software VPN termination inside the EC2 instance).   Try this: - ping the private IP of the vMX from another EC2 instance in the VPC (i.e. not a host not across the VPN tunnel), your Security Group should work.  - ping the public IP of the vMX from your on-prem, your Security Group should work.   Remember that if you are testing with a running ping (i.e. the ping is already running and only after that you block traffic, stop and restart the ping to validate traffic is blocked, else the ping will continue because of the active flow).   "if I try to execute a ping from my 10.56.33.0/24 subnet to an AWS resource located in the same subnet as the vMX instance, I can reach it, and it responds." "However, the responses can only reach my host if the outbound rule from the screenshot is applied." My understanding is that this is also expected as if you block the outbound traffic, the EC2 instance hosting the vMX  cannot send those packets out. You mention "it can reach it, and it responds" but have you checked that the ICMP request actually reaches such resource? For example, if that other resource is an EC2 instance, run a tcpdump on it, you should not see the ICMP Requests at all (because they would be blocked outbound from the vMX EC2 - if you remove the outbound rules).   Let me know how it goes. ... View more

Hi @Squuiid,   You can find this information at the very end of the document linked above.   "Are MX devices with wireless capabilities affected? No. MX devices do not support 802.11r and are not affected by the vulnerability."   Regards, Marco ... View more

Hi @scrapiron,    The use case of having any MR connected to the PoE port on an MR30H would not be a supported topology; DHCP from other MRs are not forwarded in order to prevent weird mesh topologies from forming. Other devices, such as laptops, would work just fine because DHCP packets are forwarded. ... View more