Meraki Community

DensyoV · ‎Mar 7 2021

Hi, for unknown reasons, oftentimes occurs when the device failed to notify the AP before disassociating. https://documentation.meraki.com/MR/Wireless_Troubleshooting/Wireless_Issue_Resolution_Guide#unknown_reason however, a monitor mode packet capture will be required to be able to see the traffic between the client and the AP. from the air marshal page, do you see any spoofs or deauthentication packet floods?

DensyoV · ‎Mar 7 2021

hi, aside from the authentication used, is there any difference between ssid a and ssid b configuration? In particular, the minimum bitrate configuration. also, from the event logs, what are wireless messages you find for the impacted clients? https://documentation.meraki.com/MR/Monitoring_and_Reporting/Common_Wireless_Event_Log_Messages

DensyoV · ‎Mar 7 2021

Hi, Please make sure the port configuration between your MX and D-link switch are both using the same native VLAN. Based on your D-link configuration, the native VLAN is 1. The reason for the alert is that the MX detects that MAC address to be sending traffic using VLAN 2 but its IP 10.0.2.2 is on VLAN 1 from MX's perspective.

DensyoV · ‎Mar 4 2021

Hi, yes, that is the error you get when you add multiple destination subnets separated by commas. You will need to create a separate rule for each destination.

DensyoV · ‎Mar 3 2021

Hi, Are you getting any errors when saving the config? Please note that the FW page in the group policy doesn't allow you to enter multiple destinations subnets in one rule unlike on the main FW configuration page where you can.

DensyoV · ‎Mar 3 2021

Hi, The MX is definitely dropping all inbound traffic by default unless you configure 1:1 NAT, 1:Many NAT or port forwarding. However, it doesn't really have any control of the incoming traffic, it is up to your service provider if they can block certain traffic from reaching your MX.

DensyoV · ‎Mar 1 2021

Hi just to add if you still see those logs, you can take a packet capture on the Internet interface of your MX to see which IP is it coming from, using the Wireshark application, use the filter udp.port==500

DensyoV · ‎Mar 1 2021

Hi It depends on your routing configuration what destination subnets are reachable over the MPLS. It only supports static routing and source-based or policy-based routing is not supported so you cannot define what traffic or type of traffic can pass only over the MPLS link.

DensyoV · ‎Mar 1 2021

Hi, The connectivity between the MS and the ISR, can you make it an access port on VLAN 10? The alert detects the MAC address is sending using VLAN 30 IP 10.10.10.1 but from MX's perspective, this should be VLAN 10 network. Thanks,

DensyoV · ‎Mar 1 2021

Hi, You cannot use the MPLS link as a WAN connection if it doesn't have connectivity to the Internet at all as it relies on the Meraki cloud connectivity for the management traffic and SD-WAN basically requires the link to be connected to the WAN interface. You can integrate the MPLS however using the LAN port of the MX but it will not achieve your requirements: https://documentation.meraki.com/MX/Networks_and_Routing/Integrating_an_MPLS_Connection_on_the_MX_LAN

DensyoV · ‎Jan 6 2021

Hi Alex, If the clients' connection is bouncing between APs although they are stationary, then you may need to tune the transmit power of your APs to ensure they have sufficient signal to avoid these unintended roaming and yes if the client roams from one AP to another before completing the authentication process, the AP will fail to receive to the client's reply and therefore logged it as authentication failure.

DensyoV · ‎Jan 5 2021

hi Alex, kindly ensure your APs are running on the latest stable version. there was an issue before in the 26 and earlier 27 version wherein the wireless health is showing false positive authentication failures.

DensyoV · ‎Jan 4 2021

hi, there is no option to change the speed/duplex setting of the AP port. it auto-negotiates at 1 Gig.

DensyoV · ‎Dec 8 2020

Hi, The event logs indicate authentication failures, in this case with the pre-shared key. make sure the pre-shared key matches with what is configured from the Dashboard. For testing, you can disable the authentication (change it to Open) to see if the client can actually connect proving the issue is related to the pre-shared key. If the client is still unable to connect with authentication disabled, I would suggest raising a case with Meraki with a monitor mode packet capture attached which will be very helpful in troubleshooting. You can refer to the link below for running the monitor mode captures. https://documentation.meraki.com/MR/Monitoring_and_Reporting/Capturing_Wireless_Traffic_from_a_Client_Machine#Monitoring_on_macOS Hope this helps.

DensyoV · ‎Aug 26 2020

Hi, I believe the clients will be authorized only for the duration configured. In this case, after 30 mins the clients will have to re-authenticate unless the group policy is still applied.

DensyoV · ‎Aug 24 2020

Hi, No, the user will only remain authenticated for a duration of 90 days depending on your configuration but after that, the user will be prompted with splash log in again.

DensyoV · ‎Aug 23 2020

Hi, the client will continue to bypass the splash page even after the 90 days as long as the group policy is applied. Basically, there is no splash authentication here if the group policy is applied to the client.

DensyoV · ‎Aug 23 2020

Hi, you can whitelist the device for testing to confirm if there is any security filtering enabled that is blocking the traffic. If it works properly when whitelisted, review your layer 3, content filtering and layer 7 FW rule configuration making sure it is not blocking outlook traffic. Lastly, as suggested you can take the Wireshark packet capture.

DensyoV · ‎Aug 11 2020

Hi, Is there any event in the air marshal page, i.e like packet floods or broadcast deauthentication? If none, I would recommend checking with Meraki Support if they can see anything from the backend logs. Thanks,

DensyoV · ‎Jul 30 2020

Hi, A quick packet captures on the cellular interface of the MX and the WAN interface of the hub should reveal whether the devices are sending UDP packets to build the auto-VPN. A successful connection should show bidirectional or two-way UDP traffic between the peers. If you see unidirectional traffic only on either or both peers, then the traffic is being dropped or filtered upstream. Service providers use CGNAT (carrier-grade NAT) in cellular deployments which is known to cause issues with auto-VPN connection due to how this is implemented.

DensyoV · ‎Jun 11 2020

Hi, I found this Meraki KB https://documentation.meraki.com/MR/MR_Splash_Page/Splash_Page_Traffic_Flow_and_Troubleshooting about Splash Page Traffic Flow but I am not sure if this is exactly what you are after. Thanks,

DensyoV · ‎Jun 9 2020

Hi, Yes, whichever is running as the primary. Thanks,

DensyoV · ‎Jun 7 2020

Hi Band steering is only supported on Meraki APs. The MX with wireless capability or the Z3 don't have this capability. If you want devices to connect to the 5Ghz, set the transmit power of the 2.4Ghz to the minimum. Thanks,

DensyoV · ‎Jun 7 2020

Hi, I suggest verifying the connectivity to the Syslogs servers and they are reachable from the MX and then take packet capture from the MX to see whether it is actually sending traffic to the servers or not. Also, if the Syslog servers are over the VPN, make sure there is no site-to-site VPN firewall rule blocking the traffic. https://documentation.meraki.com/zGeneral_Administration/Monitoring_and_Reporting/Syslog_Server_Overview_and_Configuration#Additional_Considerations Thanks,

DensyoV · ‎May 31 2020

Hi, Is there any SD-WAN policy or traffic shaping enabled on Site A? Also, I suggest taking packet captures to see where those packet drops are. Thanks

About DensyoV

DensyoV

Community Record

Badges