Community Tribal Knowledge Base

Remote AP Setup and Troubleshooting

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 10.1.1.25 address and his initial default gateway is 10.1.1.1 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 96.224.241.12/24 with the upstream router being 96.224.241.1, I would do this:

config t <-----Enter Config Mode
vlan 1000 "Uplink to Internet" <------- Create and Name Your VLAN
interface Vlan 1000
ip address 96.224.241.12 255.255.255.0 <------Assign a Public Address to that interface
exit
ip route 10.0.0.0 255.0.0.0 10.1.1.1 <------- Make sure traffic headed to the private networks go in the right direction
ip default-gateway 96.224.241.1 <------- 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 96.224.241.20. If we do see traffic, the output should look like below:

(3600.arubanetworks.com) #show datapath session table 96.224.241.20

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
-------------- -------------- ---- ----- ----- ---- ---- --- --- ----------- ---- -----
10.69.68.16 96.224.241.20 1 4 0 0/0 0 0 1 tunnel 18 10 FI
10.69.68.16 96.224.241.20 1 5 0 0/0 0 0 1 tunnel 18 f FI
10.69.68.16 96.224.241.20 1 6 0 0/0 0 0 1 tunnel 18 e FI
10.69.68.16 96.224.241.20 1 7 0 0/0 0 0 1 tunnel 18 d FI
10.69.68.16 96.224.241.20 1 3 0 0/0 0 0 1 tunnel 18 11 FI
10.69.68.16 96.224.241.20 1 20 0 0/0 0 0 0 tunnel 18 1 FI
10.69.68.16 96.224.241.20 1 16 0 0/0 0 0 1 tunnel 18 5 FI
10.69.68.16 96.224.241.20 1 17 0 0/0 0 0 1 tunnel 18 4 FI
10.69.68.16 96.224.241.20 1 18 0 0/0 0 0 1 tunnel 18 3 FI
10.69.68.16 96.224.241.20 1 19 0 0/0 0 0 1 tunnel 18 2 FI
96.224.241.20 10.69.68.16 1 10 2048 0/0 0 0 0 tunnel 18 a FCI
96.224.241.20 10.69.68.16 1 11 2048 0/0 0 0 0 tunnel 18 9 FCI
96.224.241.20 10.69.68.16 1 8 2048 0/0 0 0 0 tunnel 18 c FCI
96.224.241.20 10.69.68.16 1 9 2048 0/0 0 0 0 tunnel 18 b FCI
96.224.241.20 10.69.68.16 1 14 2048 0/0 0 0 0 tunnel 18 7 FCI
96.224.241.20 10.69.68.16 1 15 2048 0/0 0 0 0 tunnel 18 6 FCI
96.224.241.20 10.69.68.16 1 12 2048 0/0 0 0 0 tunnel 18 9 FCI
96.224.241.20 10.69.68.16 1 13 2048 0/0 0 0 0 tunnel 18 8 FCI
96.224.241.20 10.69.68.16 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
exit
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:

(3600.arubanetworks.com) (config) #show interface gigabitethernet 0/1 access-group 

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




Version History
Revision #:
2 of 2
Last update:
‎11-15-2011 08:38 AM
Updated by:
 
Labels (1)
Contributors
Comments
tecniq

I'm assuming this is for the Main (HQ) site to set up the firewall. Can I also assume that we can mirror the same configuration at the Remote Site that has a firewall?


ozwifi wrote:

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 10.1.1.25 address and his initial default gateway is 10.1.1.1 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 96.224.241.12/24 with the upstream router being 96.224.241.1, I would do this:

config t <-----Enter Config Mode
vlan 1000 "Uplink to Internet" <------- Create and Name Your VLAN
interface Vlan 1000
ip address 96.224.241.12 255.255.255.0 <------Assign a Public Address to that interface
exit
ip route 10.0.0.0 255.0.0.0 10.1.1.1 <------- Make sure traffic headed to the private networks go in the right direction
ip default-gateway 96.224.241.1 <------- 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 96.224.241.20. If we do see traffic, the output should look like below:

(3600.arubanetworks.com) #show datapath session table 96.224.241.20

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
-------------- -------------- ---- ----- ----- ---- ---- --- --- ----------- ---- -----
10.69.68.16 96.224.241.20 1 4 0 0/0 0 0 1 tunnel 18 10 FI
10.69.68.16 96.224.241.20 1 5 0 0/0 0 0 1 tunnel 18 f FI
10.69.68.16 96.224.241.20 1 6 0 0/0 0 0 1 tunnel 18 e FI
10.69.68.16 96.224.241.20 1 7 0 0/0 0 0 1 tunnel 18 d FI
10.69.68.16 96.224.241.20 1 3 0 0/0 0 0 1 tunnel 18 11 FI
10.69.68.16 96.224.241.20 1 20 0 0/0 0 0 0 tunnel 18 1 FI
10.69.68.16 96.224.241.20 1 16 0 0/0 0 0 1 tunnel 18 5 FI
10.69.68.16 96.224.241.20 1 17 0 0/0 0 0 1 tunnel 18 4 FI
10.69.68.16 96.224.241.20 1 18 0 0/0 0 0 1 tunnel 18 3 FI
10.69.68.16 96.224.241.20 1 19 0 0/0 0 0 1 tunnel 18 2 FI
96.224.241.20 10.69.68.16 1 10 2048 0/0 0 0 0 tunnel 18 a FCI
96.224.241.20 10.69.68.16 1 11 2048 0/0 0 0 0 tunnel 18 9 FCI
96.224.241.20 10.69.68.16 1 8 2048 0/0 0 0 0 tunnel 18 c FCI
96.224.241.20 10.69.68.16 1 9 2048 0/0 0 0 0 tunnel 18 b FCI
96.224.241.20 10.69.68.16 1 14 2048 0/0 0 0 0 tunnel 18 7 FCI
96.224.241.20 10.69.68.16 1 15 2048 0/0 0 0 0 tunnel 18 6 FCI
96.224.241.20 10.69.68.16 1 12 2048 0/0 0 0 0 tunnel 18 9 FCI
96.224.241.20 10.69.68.16 1 13 2048 0/0 0 0 0 tunnel 18 8 FCI
96.224.241.20 10.69.68.16 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
exit
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:

(3600.arubanetworks.com) (config) #show interface gigabitethernet 0/1 access-group 

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





 

Search Airheads
Showing results for 
Search instead for 
Did you mean: 
Is this a frequent problem?

Request an official Aruba knowledge base article to be written by our experts.