Wireless Access

Reply
Contributor II

Unable to ping access points from a different vlan

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

Re: Unable to ping access points from a different vlan

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.
Contributor II

Re: Unable to ping access points from a different vlan

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

Aruba Employee

Re: Unable to ping access points from a different vlan

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.

Contributor II

Re: Unable to ping access points from a different vlan

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

 

 

 

 

Aruba Employee

Re: Unable to ping access points from a different vlan

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.

Contributor II

Re: Unable to ping access points from a different vlan

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

Aruba Employee

Re: Unable to ping access points from a different vlan

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.

Aruba Employee

Re: Unable to ping access points from a different vlan

Hi,

 

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

 

Then netstat command shd work fine.

Contributor II

Re: Unable to ping access points from a different vlan

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

 

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: