Wireless clients cannot RDP or SSH

[NIGEL PAYNE]

I have a customer that is reporting the above issue from a single site

Wired clients at this site can RDP and SSH

Clients at other sites, supported by the same WLC, can connect via RDP & SSH via WiFi

There are no access lists on the WLC

Is this far more likely to be a LAN/WAN/FW issue

Is there any debug I can run on the WLC that might identify the issue or is this the realm of sniffing the LAN/monitoring the Firewall

[pieterh]

the clients cannot start RDP or SSH? is the application installed on these clients?

is the connection refused? then check if the subnet used on this site is allowed at the destination.

if other do basic steps like

- ping default gateway from client

- ping remote gateway from client

- ping  ssh/rrdp destination

- traceroute to destination

[tech_gubby]

Can you please check, SSH is blocked by access point/ wireless controller? by ACL.

[NIGEL PAYNE]

There are no ACLs on the WLC

[NIGEL PAYNE]

Interesting development, client has statically assigned himself an IP address in the second half of the /23 subnet and now he can RDP & SSH OK ie a 10.108.157.X address rather than a 10.108.156.X DHCP assigned address

[pieterh]

interesting lead

is the AP involved in local mode (date delivered to lan centrally by WLC)?

or flexconnect mode (data delivered by AP to local vlan)?

in second case, then the subnet mask retrieved from the dhcp scope may not be correct, so it cannot reach the central site through the gateway

[NIGEL PAYNE]

It turns out the fault description is not entirely accurate

The issue is not just for 10.108.156.xx addresses but affects the whole subnet due to a Cisco bug CSCvb78700 affecting the 4500 core switch

Image 03.09.00.E is vulnerable to the following.....

　

Symptom:

4500X unable to forward packets when they need to be unknown unicast flooded

　

Conditions:

Destination device's mac is NOT present on the switch mac table, but the ARP is resolved

　

Workaround:

There are 3 possible workarounds.

　

Workaround 1: Set the mac address aging timer to the same as the ARP timer. The default would be 14400 seconds for the arp timer. This forces the CPU to punt the traffic to cpu which uses software to forward the first packet to learn the mac.

　

Workaround 2: Set static entry for particular MAC address.

　

Workaround 3: This corrects the actual unicast floodset

　

Any event which triggers the review,

1) like adding or removing a port from the affected VLAN

2) shut/no shut of the port

3) removing and adding the affected VLAN.

4) System reload.

　

Further Problem Description:

"show platform software floodset vlan <>" and "show platform hardware floodset vlan <>" will be out of sync for the Unicast floodset.

　

The software unicast floodset will have all the required ports in specified vlan under it.

The hardware floodset may have no ports mapped or may have some ports missing.