Wireless Access

Hi,

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).

Here:http://community.arubanetworks.com/t5/Wireless-Access/Cannot-ping-access-points/td-p/221668 the firmware is mentioned, however, the installed firmware is 6.4.2.12, so a later version than in the thread.

There is no modified wired ap profile. All is standard.

Any ideas what could be the cause of this?

Thx

Peter

from what i remember from other threads about this question the reason is that once the tunnel is setup the AP picks up the traffic and sends it back via the tunnel. so if your routing is all setup correctly and there are no firewalls or such you might even be able to get the reply via that other route. but as far as im aware this is expected behaviour. the question is also why you want to ping to APs, if it is for monitoring then it is quite limited. sure the AP might reply but that says nothing further about its state.

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)?

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 .

 

1. Ping Request

 

PC(subnet B) ---ping req---> AP(subnet A) ===>Does not go through Controller

 

1. 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.

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)?

 

 

 

 

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.

Hi

 

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?

 

Thx

Peter

Hi,

 

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.

Hi,

 

Please use Esc+Ctrl+K  keys to get in to full access mode on AP.

 

Then netstat command shd work fine.

Hi

 

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.

 

thx

Peter

 

Hi

 

I have attached the shell and netstat output. This seems 'normal'.

 

I still have to do the captures.

 

BR

Peter

 

 

Sometimes the solution can be very simple...

 

'IP routing'  has to be enabled on the mgmt IP interface for this to work.

In cmd: under the vlan interface, type 'ip routing'.

In GUI: check the 'Enable Inter-VLAN Routing' checkbox, on the IP interface page.

 

Thx to Manish from TAC!

 

Peter