01-20-2016 04:52 AM - edited 01-20-2016 09:44 AM
At a site we have two 7240 controllers in master-local fast-failover setup.
CPSEC is enabled. We are able to ping the access point from a different vlan while they are booting. So routing, dhcp etc are ok.
It seems that as soon as they've build up the IPSEC tunnel to the controller, they stop responding to ping requests from different vlans.
From inside the vlan they do respond. The AP can ping the default gateway (which is the core switch, no ACL's).
There is no modified wired ap profile. All is standard.
Any ideas what could be the cause of this?
01-23-2016 06:51 AM
01-23-2016 07:12 AM
Thx for your reply. I came across this issue and I was wondering what the reason might be. On other installations with CPSEC enabled the APs were always replying to pings, even from other vlans.
Would there be a way to check the internal routing table of an access point (via ssh)?
01-26-2016 06:58 AM
Please find the sequence of events when CPSEC is enabled:
I am assuming we are trying to ping an AP from a client which resides in a different vlan than the AP .
- Ping Request
PC(subnet B) ---ping req---> AP(subnet A) ===>Does not go through Controller
- Ping Reply
AP(subnet A) ---ping reply---> tun0(default route) ---ESP(ipsec)---> Controller ---ping reply---> PC(subnet B)
When we have CPSEC enabled, AP add a default route on themselves (tun 0). This default route points to the IP address of the controller.
Hence, the ping reply goes via the controller. Hence, we should have routing enabled between controller & wired client which is trying to ping CPSEC based AP.
01-26-2016 08:23 AM - edited 01-26-2016 08:26 AM
Ok, thx for the info. So even if the access point routing table (show datapath route ap-name '%ap-name%) is showing 'normal' IP entries, it is not used when the cpsec / ipsec tunnel is build?
The default gateway of the access point is at that point no longer the LAN gateway, but the controller?
So, although the access point is reachable while booting (meaning the routing between vlans is ok) and the controller is reachable from the same testing pc, it seems that something is blocking the replies once it passes through the controller (after the ipsec tunnel is build), am I correct? The request is send via switchport 'a' (access point port) and the reply comes via switchport 'b' (controller port)?
01-26-2016 08:34 AM
That is correct.
Please check the following:
1. Start a continuous ping from the client to the AP.
2. Aruba# show datapath session ap-name <name of AP> | include <ip-address of wired client>
We need to check the output for the above command to make sure ICMP traffic is reaching AP's datapath.
3. Aruba# show datapath session table | include <ip-address of wired client>
We should see ICMP traffic destined to wired client in output of above command . As the AP sends back the ICMP replies inside the IPSEC tunnel , it will eventually hit controller's datapath & then go out to the client.
In addition to above please check the following output:
Aruba #show firewall | include ICMP
Stateful ICMP Processing Disabled --->This is disabled by default
In case it is enabled, controller will drop the ICMP packets destined to wired client as they will be treated
as Unsolicited packets . The reason is that controller never saw the ICMP request coming in but then sees that ICMP responses are going out.
In case you have access to AP's shell, netstat -rn will show the routing table of the AP.
01-27-2016 01:10 AM
This is great info. Thx for that.
I've checked the datapath and attached the results. I've also done a ap system status check that I've attached.
For the datapath session output is seems that the AP receives a ping request, but I'm not sure why it seems to reply with destination port 0.
Stateful ICMP processing is off.
Also, when connected to the console port of an AP, the netstat -rn command returns 'permission denied'.
Would you have a full list of AP shell commands?
01-27-2016 08:47 AM
I have few questions:
1. Are you able to ping AP's default gateway from the wired client?
2. Are you able to ping the wired client from the controller?
3. The ICMP reply packet from the AP will have the source set to IP address of the AP.
We need to ensure that traffic from the AP is seen on controller's uplink & getting routed towards the wired client.
You might have to take a controller uplink pcap to determine the same.
I do not have a list of shell commands. There is another thread on Airheads which list the setenv commands which could be executed from APboot mode.
01-28-2016 01:06 AM
I will be able to check this next week. I'll post the results as soon as I have any.
I can already say that the client can indeed reach the AP's and the controller's gateway (they are in the same 'WLAN' subnet and it's a core switch without ACL). The client can ping the AP while it's booting, so routing should be ok. Also: the controller is in the same subnet, so coming from the AP directly or via the controller makes no difference to the routing.
As soon as the IPSec tunnel is build (I assume that is the trigger), the AP is no longer reachable.