Command of the Day

Guru Elite

COTD: Remote AP Setup and Troubleshooting Part 1 - The Transport

Setting up Remote AP is very straightforward if you make a checklist of what you need to do and procedures to ensure that those items are configured correctly. "Set and Confirm" is a good way to be successful at anything and Remote AP is no different. This post assumes that you already have at least one Campus AP doing exactly what you want it to do, and Remote AP is just extending that Campus AP functionality to anywhere on the internet.

- The Transport
Remote AP requires that the controller can respond to a public IP address to transport traffic and instructions for the Remote AP. That public IP address can be on one of the controller's physical interfaces, or via static NAT that is done by a device functioning as a firewall, so that traffic that hits a public address can be answered by the controller.

- Controller with a physical Public IP address
If a controller is setup the first way, where it has a public address on one of its physical interfaces, you should create a static route for all your private subnets and point it to the private default gateway on the controller. You must then make the controller's new default-gateway the next hop on the public internet upstream from the controller. As an example, I have a controller that has a address and his initial default gateway is All of my private networks begin with a 10.x.x.x address. If I then want to give my controller a physical IP address on the internet of with the upstream router being, I would do this:

config t <-----Enter Config Mode
vlan 1000 "Uplink to Internet" <------- Create and Name Your VLAN
interface Vlan 1000
ip address <------Assign a Public Address to that interface
ip route <------- Make sure traffic headed to the private networks go in the right direction
ip default-gateway <------- Change the default gateway so that all of the remaining traffic on the internet can be answered
interface gigabitethernet 0/1 <--------Pick a physical interface for public internet connectivity
switchport access vlan 1000 <--------Assign that public address to the physical interface

You can confirm your ip addressing by typing "show vlan status". You can check your routing by typing "show ip route"

- Firewall doing Static NAT
If you have a firewall doing a static 1:1 nat, you would not need the configuration above. You would just need to do the static NAT with the firewall and allow UDP4500 inbound.

A common troubleshooting procedure is to also allow ICMP (Ping) inbound so that the controller can be pinged from the internet. If you are allowing Ping inbound, have someone on the public internet, whether via broadband or 3g card attempt to ping the controller and then you can see if it answers. You can confirm that the controller is answering by doing the following on the commandline while the ping is occurring:

show datapath session table

In the example below we are looking on the controller to see if we have traffic from If we do see traffic, the output should look like below:

( #show datapath session table

Datapath Session Table Entries

Flags: F - fast age, S - src NAT, N - dest NAT
D - deny, R - redirect, Y - no syn
H - high prio, P - set prio, T - set ToS
C - client, M - mirror, V - VOIP
I - Deep inspect, U - Locally destined

Source IP Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge Flags
-------------- -------------- ---- ----- ----- ---- ---- --- --- ----------- ---- ----- 1 4 0 0/0 0 0 1 tunnel 18 10 FI 1 5 0 0/0 0 0 1 tunnel 18 f FI 1 6 0 0/0 0 0 1 tunnel 18 e FI 1 7 0 0/0 0 0 1 tunnel 18 d FI 1 3 0 0/0 0 0 1 tunnel 18 11 FI 1 20 0 0/0 0 0 0 tunnel 18 1 FI 1 16 0 0/0 0 0 1 tunnel 18 5 FI 1 17 0 0/0 0 0 1 tunnel 18 4 FI 1 18 0 0/0 0 0 1 tunnel 18 3 FI 1 19 0 0/0 0 0 1 tunnel 18 2 FI 1 10 2048 0/0 0 0 0 tunnel 18 a FCI 1 11 2048 0/0 0 0 0 tunnel 18 9 FCI 1 8 2048 0/0 0 0 0 tunnel 18 c FCI 1 9 2048 0/0 0 0 0 tunnel 18 b FCI 1 14 2048 0/0 0 0 0 tunnel 18 7 FCI 1 15 2048 0/0 0 0 0 tunnel 18 6 FCI 1 12 2048 0/0 0 0 0 tunnel 18 9 FCI 1 13 2048 0/0 0 0 0 tunnel 18 8 FCI 1 3 2048 0/0 0 0 1 tunnel 18 11 FCI

After the transport is confirmed, we can stop allowing ping inbound on the firewall, if you are using static NAT. If the controller has a physical public interface you might want to protect it by creating a firewall policy that allows only UDP 4500, and then applying it to that physical interface:

config t <-----------Enter Config Mode
ip access-list session UDP4500-only <---------Name my firewall policy
any any udp 4500 4500 permit <------- Only allow UDP 4500 around this parts
any any any deny <-------- Drop everything else
interface gigabitethernet 0/1 <-------Choose my uplink interface
ip access-group UDP4500only session<----------------Apply my firewall policy to that interface

If you ever want to see if a session firewall policy is applied to an interface, do the following:

( (config) #show interface gigabitethernet 0/1 access-group 

GE 1/0:
session access list UDP4500-only is applied

That is all for now. Part 2 soon to come..

Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Frequent Contributor I

Internet access Interface


You assumed that the Internet interface is protected by a firewall outside of the controller. According to Aruba, you can place the controller directly on the Internet, but you should use an ACL to protect the interface. Here is an example I got from Aruba.

ip access-list session internet
any any svc-ike permit
any any svc-icmp permit
alias corp-addresses any any permit
any any svc-ssh permit log
any any svc-dhcp permit
any any svc-natt permit
any any any deny log

interface fastethernet 1/7
description "Uplink"
trusted vlan 1-4094
ip access-group internet session
switchport access vlan 18

Bruce Osborne
Liberty University
Bruce Osborne - Wireless Engineer

RAP connectivity with Controller on Internet

Thanks Bruce.

I see/have deployed many more controllers behind corporate DMZ firewalls than 'directly on the internet', however either configuration will work.

That being said, had a quick glance at the policy you included in the last note. I would recommend some optimizations to suit the application..although I do understand this originated via a recommendation from support. The policy will work, just IMO could be 'tightened' or optimized a bit from my standpoint.

For instance:

- For REMOTE AP operation only you can allow IPSEC (UDP 4500... aka NAT-T) and the RAPs should connect in:out of that interface just fine.

- For VPN client operation IKE should be allowed in addition to NAT-T. To cover all bases HTTPS/SSL should be allowed for our VIA client.(SSL fallback is being built into the client)

- I would not allow SSH from an external source such as the policy allows. You will have your logs filling up with admin:admin, admin:test, bob:sally, sally:bob all day long as kiddie scripts try to SSH to the controller's external interface.

- The other protocols, such as ICMP (in particular) and DHCP are not required. Can't think of a use case for normal deployments really.

- And lastly... the 'deny log' at the end is going to generate __a lot__ of traffic on an internet facing controller !
Search Airheads
Showing results for 
Search instead for 
Did you mean: