Wireless Access

Trying to get RAPs operational but struggling.

I've read the articles on Flomain and the guide Aruba Remote Access Point Solution Guide for Tele workers and Home Offices, but I just can't get a win here.
Aruba Remote Access Point Solution Guide

Basic RAP Setup with ArubaOS 8 - Flomain Networking

RAP Cluster is 8.10.0.8
The RAP cluster sits under a higher config level as a separate 'RAP' folder, with the 2 hardware nodes in it. (Higher up are 3 Campus AP clusters)

The problem is our internal design - NAT off the border firewall can't work because the network the controllers are on is not routed to the border. Using an NSX load balancer doesn't work for NAT, because although the LB can host the public address and the LB has access to the controller's network, NSX wants to own the VPN endpoint, and we don't seem to be able to work around that.

So I'm going to have to put a public IP on the 2 controllers that I'm going to use for the RAP cluster.
Presently all our controllers only have one IP interface to which the Conductor, the APs, and the admins connect. 

Will the RAP part work if I leave the controllers are they are, but create a new interface on the controllers for the public IP, and leave everything else as it is? Or do I have to zeroise the controllers and start again? The current IP config isn't referred to as 'interface mgmt.'  

controller-ip vlan 628

vlan-name wifiag01-wifimgmt1
vlan wifiag01-wifimgmt1 628

interface vlan 628
    ip address xxx.xxx.xxx.xxx

My thought is to just add a new 'interface vlan xxx' using a public IP,  trunk it in, and specify that in the RAP-IP when I add the controllers to the RAP cluster
Can that work, or am I just smoking crack? 

If it doesn't work, is it a case of zeroise the the controllers, rebuild following the cli wizard, and the Conductor has to talk to the RAP controllers via their public IP, and at some point I set up a management interface?

Are any more ports than UDP 4500 required inbound on the perimeter, as I saw Florian mention 69 and 500, but I didn't spot that in the Aruba guide.

Thanks.

I don't know that using separate interfaces, one privately addressed and the other with a public IP, is a tested or supported configuration.  Expectation is that either the public IP address is used as the controller-ip (this was originally the only supported configuration for AOS 8 clusters and RAPs) or that a public IP address is configured to 1:1 NAT with the controller-ip and the cluster configuration has the "RAP public IP" specified.

UDP 4500 is the only port required to be opened to support RAP operation.

Trying to get RAPs operational but struggling.

I've read the articles on Flomain and the guide Aruba Remote Access Point Solution Guide for Tele workers and Home Offices, but I just can't get a win here.
Aruba Remote Access Point Solution Guide

Basic RAP Setup with ArubaOS 8 - Flomain Networking

RAP Cluster is 8.10.0.8
The RAP cluster sits under a higher config level as a separate 'RAP' folder, with the 2 hardware nodes in it. (Higher up are 3 Campus AP clusters)

The problem is our internal design - NAT off the border firewall can't work because the network the controllers are on is not routed to the border. Using an NSX load balancer doesn't work for NAT, because although the LB can host the public address and the LB has access to the controller's network, NSX wants to own the VPN endpoint, and we don't seem to be able to work around that.

So I'm going to have to put a public IP on the 2 controllers that I'm going to use for the RAP cluster.
Presently all our controllers only have one IP interface to which the Conductor, the APs, and the admins connect. 

Will the RAP part work if I leave the controllers are they are, but create a new interface on the controllers for the public IP, and leave everything else as it is? Or do I have to zeroise the controllers and start again? The current IP config isn't referred to as 'interface mgmt.'  

controller-ip vlan 628

vlan-name wifiag01-wifimgmt1
vlan wifiag01-wifimgmt1 628

interface vlan 628
    ip address xxx.xxx.xxx.xxx

My thought is to just add a new 'interface vlan xxx' using a public IP,  trunk it in, and specify that in the RAP-IP when I add the controllers to the RAP cluster
Can that work, or am I just smoking crack? 

If it doesn't work, is it a case of zeroise the the controllers, rebuild following the cli wizard, and the Conductor has to talk to the RAP controllers via their public IP, and at some point I set up a management interface?

Are any more ports than UDP 4500 required inbound on the perimeter, as I saw Florian mention 69 and 500, but I didn't spot that in the Aruba guide.

Thanks.

Thanks for posting, Carson.

We've got to a point now where the incoming RAP is seen by the controller, but the association isn't getting very far.

My earlier problem was that I was landing the incoming traffic on the LMS VIP - wrong. That's been changed to the controller's internal controller IP (same as the Conductor talks to).

I'm sure I read that I should be provisioning the RAP at the MN level. But the MN level doesn't contain the AP Groups  (only the group the AP is presently in), so I can't select the RAP group.  

So I'm provisioning down a level, and I can see what I need to see

In the Provision dialogue, I'm selecting 'static' and entering the public IP that is specified as the RAP-Public-IP in the cluster config. 

On the Conductor CLI I see the AP now in show whitelist-db rap, but no Remote-IP is specified. Should that be the controller's public IP, as specified during provisioning?
I can see that I can set is explicitly by modifying the whitelist, but doing so hasn't yielded any success.

When I look at the Remote AP Whitelist, should there be a defined entry in the IPv4 address field?

I've tried provisioning with certificate auth and with PSK auth. No joy with either.

I've tried provisioning with a Trust Anchor of none and self-signed. No joy with either.

When looking at the connected controller security log, I just can't get past "IKE SA Deletion: IKE2_delSa peer:...."

Further thoughts?

Thanks

I don't know that using separate interfaces, one privately addressed and the other with a public IP, is a tested or supported configuration.  Expectation is that either the public IP address is used as the controller-ip (this was originally the only supported configuration for AOS 8 clusters and RAPs) or that a public IP address is configured to 1:1 NAT with the controller-ip and the cluster configuration has the "RAP public IP" specified.

UDP 4500 is the only port required to be opened to support RAP operation.

Trying to get RAPs operational but struggling.

I've read the articles on Flomain and the guide Aruba Remote Access Point Solution Guide for Tele workers and Home Offices, but I just can't get a win here.
Aruba Remote Access Point Solution Guide

Basic RAP Setup with ArubaOS 8 - Flomain Networking

RAP Cluster is 8.10.0.8
The RAP cluster sits under a higher config level as a separate 'RAP' folder, with the 2 hardware nodes in it. (Higher up are 3 Campus AP clusters)

The problem is our internal design - NAT off the border firewall can't work because the network the controllers are on is not routed to the border. Using an NSX load balancer doesn't work for NAT, because although the LB can host the public address and the LB has access to the controller's network, NSX wants to own the VPN endpoint, and we don't seem to be able to work around that.

So I'm going to have to put a public IP on the 2 controllers that I'm going to use for the RAP cluster.
Presently all our controllers only have one IP interface to which the Conductor, the APs, and the admins connect. 

Will the RAP part work if I leave the controllers are they are, but create a new interface on the controllers for the public IP, and leave everything else as it is? Or do I have to zeroise the controllers and start again? The current IP config isn't referred to as 'interface mgmt.'  

controller-ip vlan 628

vlan-name wifiag01-wifimgmt1
vlan wifiag01-wifimgmt1 628

interface vlan 628
    ip address xxx.xxx.xxx.xxx

My thought is to just add a new 'interface vlan xxx' using a public IP,  trunk it in, and specify that in the RAP-IP when I add the controllers to the RAP cluster
Can that work, or am I just smoking crack? 

If it doesn't work, is it a case of zeroise the the controllers, rebuild following the cli wizard, and the Conductor has to talk to the RAP controllers via their public IP, and at some point I set up a management interface?

Are any more ports than UDP 4500 required inbound on the perimeter, as I saw Florian mention 69 and 500, but I didn't spot that in the Aruba guide.

Thanks.

The RAP allow-list only requires the MAC address, the RAP name, and AP group to identify the RAP. The RAP must be in the allow-list prior to the RAP being allowed to connect.  You can also use a MAC auth for RAP allowance in place of the static allow-list, and with ClearPass you can integrate with Activate to automatically synchronize the desired APs that you've purchased.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 13, 2023 08:47 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Thanks for posting, Carson.

We've got to a point now where the incoming RAP is seen by the controller, but the association isn't getting very far.

My earlier problem was that I was landing the incoming traffic on the LMS VIP - wrong. That's been changed to the controller's internal controller IP (same as the Conductor talks to).

I'm sure I read that I should be provisioning the RAP at the MN level. But the MN level doesn't contain the AP Groups  (only the group the AP is presently in), so I can't select the RAP group.  

So I'm provisioning down a level, and I can see what I need to see

In the Provision dialogue, I'm selecting 'static' and entering the public IP that is specified as the RAP-Public-IP in the cluster config. 

On the Conductor CLI I see the AP now in show whitelist-db rap, but no Remote-IP is specified. Should that be the controller's public IP, as specified during provisioning?
I can see that I can set is explicitly by modifying the whitelist, but doing so hasn't yielded any success.

When I look at the Remote AP Whitelist, should there be a defined entry in the IPv4 address field?

I've tried provisioning with certificate auth and with PSK auth. No joy with either.

I've tried provisioning with a Trust Anchor of none and self-signed. No joy with either.

When looking at the connected controller security log, I just can't get past "IKE SA Deletion: IKE2_delSa peer:...."

Further thoughts?

Thanks

------------------------------
Nathan

Original Message:
Sent: Dec 12, 2023 12:41 PM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

I don't know that using separate interfaces, one privately addressed and the other with a public IP, is a tested or supported configuration.  Expectation is that either the public IP address is used as the controller-ip (this was originally the only supported configuration for AOS 8 clusters and RAPs) or that a public IP address is configured to 1:1 NAT with the controller-ip and the cluster configuration has the "RAP public IP" specified.

UDP 4500 is the only port required to be opened to support RAP operation.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 12, 2023 12:11 PM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Trying to get RAPs operational but struggling.

I've read the articles on Flomain and the guide Aruba Remote Access Point Solution Guide for Tele workers and Home Offices, but I just can't get a win here.
Aruba Remote Access Point Solution Guide

Basic RAP Setup with ArubaOS 8 - Flomain Networking

RAP Cluster is 8.10.0.8
The RAP cluster sits under a higher config level as a separate 'RAP' folder, with the 2 hardware nodes in it. (Higher up are 3 Campus AP clusters)

The problem is our internal design - NAT off the border firewall can't work because the network the controllers are on is not routed to the border. Using an NSX load balancer doesn't work for NAT, because although the LB can host the public address and the LB has access to the controller's network, NSX wants to own the VPN endpoint, and we don't seem to be able to work around that.

So I'm going to have to put a public IP on the 2 controllers that I'm going to use for the RAP cluster.
Presently all our controllers only have one IP interface to which the Conductor, the APs, and the admins connect. 

Will the RAP part work if I leave the controllers are they are, but create a new interface on the controllers for the public IP, and leave everything else as it is? Or do I have to zeroise the controllers and start again? The current IP config isn't referred to as 'interface mgmt.'  

controller-ip vlan 628

vlan-name wifiag01-wifimgmt1
vlan wifiag01-wifimgmt1 628

interface vlan 628
    ip address xxx.xxx.xxx.xxx

My thought is to just add a new 'interface vlan xxx' using a public IP,  trunk it in, and specify that in the RAP-IP when I add the controllers to the RAP cluster
Can that work, or am I just smoking crack? 

If it doesn't work, is it a case of zeroise the the controllers, rebuild following the cli wizard, and the Conductor has to talk to the RAP controllers via their public IP, and at some point I set up a management interface?

Are any more ports than UDP 4500 required inbound on the perimeter, as I saw Florian mention 69 and 500, but I didn't spot that in the Aruba guide.

Thanks.

------------------------------
Nathan
------------------------------

Yeah, I'm pretty sure I've got those bases covered. Thanks for the confirmation of the allow-list details.
I think I'm going to have to take the second controller, bin it from Conductor, wipe it, start again with public IP, and see what happens - takes NSX out of our traffic path. I'll update once I've done that, but it'll be next week now.

Quick edit: removed cluster config, delete one of the controllers, just a standalone controller now. Traffic comes in from the RAP, still get the same IKE warning and no association.  errcode:ERR_IKESA_CLEARED 
Onwards.

------------------------------
Nathan

Original Message:
Sent: Dec 13, 2023 09:33 AM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

The RAP allow-list only requires the MAC address, the RAP name, and AP group to identify the RAP. The RAP must be in the allow-list prior to the RAP being allowed to connect.  You can also use a MAC auth for RAP allowance in place of the static allow-list, and with ClearPass you can integrate with Activate to automatically synchronize the desired APs that you've purchased.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 13, 2023 08:47 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Thanks for posting, Carson.

We've got to a point now where the incoming RAP is seen by the controller, but the association isn't getting very far.

My earlier problem was that I was landing the incoming traffic on the LMS VIP - wrong. That's been changed to the controller's internal controller IP (same as the Conductor talks to).

I'm sure I read that I should be provisioning the RAP at the MN level. But the MN level doesn't contain the AP Groups  (only the group the AP is presently in), so I can't select the RAP group.  

So I'm provisioning down a level, and I can see what I need to see

In the Provision dialogue, I'm selecting 'static' and entering the public IP that is specified as the RAP-Public-IP in the cluster config. 

On the Conductor CLI I see the AP now in show whitelist-db rap, but no Remote-IP is specified. Should that be the controller's public IP, as specified during provisioning?
I can see that I can set is explicitly by modifying the whitelist, but doing so hasn't yielded any success.

When I look at the Remote AP Whitelist, should there be a defined entry in the IPv4 address field?

I've tried provisioning with certificate auth and with PSK auth. No joy with either.

I've tried provisioning with a Trust Anchor of none and self-signed. No joy with either.

When looking at the connected controller security log, I just can't get past "IKE SA Deletion: IKE2_delSa peer:...."

Further thoughts?

Thanks

------------------------------
Nathan

Original Message:
Sent: Dec 12, 2023 12:41 PM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

I don't know that using separate interfaces, one privately addressed and the other with a public IP, is a tested or supported configuration.  Expectation is that either the public IP address is used as the controller-ip (this was originally the only supported configuration for AOS 8 clusters and RAPs) or that a public IP address is configured to 1:1 NAT with the controller-ip and the cluster configuration has the "RAP public IP" specified.

UDP 4500 is the only port required to be opened to support RAP operation.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 12, 2023 12:11 PM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Trying to get RAPs operational but struggling.

I've read the articles on Flomain and the guide Aruba Remote Access Point Solution Guide for Tele workers and Home Offices, but I just can't get a win here.
Aruba Remote Access Point Solution Guide

Basic RAP Setup with ArubaOS 8 - Flomain Networking

RAP Cluster is 8.10.0.8
The RAP cluster sits under a higher config level as a separate 'RAP' folder, with the 2 hardware nodes in it. (Higher up are 3 Campus AP clusters)

The problem is our internal design - NAT off the border firewall can't work because the network the controllers are on is not routed to the border. Using an NSX load balancer doesn't work for NAT, because although the LB can host the public address and the LB has access to the controller's network, NSX wants to own the VPN endpoint, and we don't seem to be able to work around that.

So I'm going to have to put a public IP on the 2 controllers that I'm going to use for the RAP cluster.
Presently all our controllers only have one IP interface to which the Conductor, the APs, and the admins connect. 

Will the RAP part work if I leave the controllers are they are, but create a new interface on the controllers for the public IP, and leave everything else as it is? Or do I have to zeroise the controllers and start again? The current IP config isn't referred to as 'interface mgmt.'  

controller-ip vlan 628

vlan-name wifiag01-wifimgmt1
vlan wifiag01-wifimgmt1 628

interface vlan 628
    ip address xxx.xxx.xxx.xxx

My thought is to just add a new 'interface vlan xxx' using a public IP,  trunk it in, and specify that in the RAP-IP when I add the controllers to the RAP cluster
Can that work, or am I just smoking crack? 

If it doesn't work, is it a case of zeroise the the controllers, rebuild following the cli wizard, and the Conductor has to talk to the RAP controllers via their public IP, and at some point I set up a management interface?

Are any more ports than UDP 4500 required inbound on the perimeter, as I saw Florian mention 69 and 500, but I didn't spot that in the Aruba guide.

Thanks.

------------------------------
Nathan
------------------------------

Just athought while reading the AOS hardening guide and some comments about CPSec:
Once a campus AP has been provisioned as a RAP. should there be whitelist-db entries in BOTH cpsec and rap, like I have below, or should the AP now only exist in rap?

Yeah, I'm pretty sure I've got those bases covered. Thanks for the confirmation of the allow-list details.
I think I'm going to have to take the second controller, bin it from Conductor, wipe it, start again with public IP, and see what happens - takes NSX out of our traffic path. I'll update once I've done that, but it'll be next week now.

Quick edit: removed cluster config, delete one of the controllers, just a standalone controller now. Traffic comes in from the RAP, still get the same IKE warning and no association.  errcode:ERR_IKESA_CLEARED 
Onwards.

------------------------------
Nathan

Original Message:
Sent: Dec 13, 2023 09:33 AM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

The RAP allow-list only requires the MAC address, the RAP name, and AP group to identify the RAP. The RAP must be in the allow-list prior to the RAP being allowed to connect.  You can also use a MAC auth for RAP allowance in place of the static allow-list, and with ClearPass you can integrate with Activate to automatically synchronize the desired APs that you've purchased.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 13, 2023 08:47 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Thanks for posting, Carson.

We've got to a point now where the incoming RAP is seen by the controller, but the association isn't getting very far.

My earlier problem was that I was landing the incoming traffic on the LMS VIP - wrong. That's been changed to the controller's internal controller IP (same as the Conductor talks to).

I'm sure I read that I should be provisioning the RAP at the MN level. But the MN level doesn't contain the AP Groups  (only the group the AP is presently in), so I can't select the RAP group.  

So I'm provisioning down a level, and I can see what I need to see

In the Provision dialogue, I'm selecting 'static' and entering the public IP that is specified as the RAP-Public-IP in the cluster config. 

On the Conductor CLI I see the AP now in show whitelist-db rap, but no Remote-IP is specified. Should that be the controller's public IP, as specified during provisioning?
I can see that I can set is explicitly by modifying the whitelist, but doing so hasn't yielded any success.

When I look at the Remote AP Whitelist, should there be a defined entry in the IPv4 address field?

I've tried provisioning with certificate auth and with PSK auth. No joy with either.

I've tried provisioning with a Trust Anchor of none and self-signed. No joy with either.

When looking at the connected controller security log, I just can't get past "IKE SA Deletion: IKE2_delSa peer:...."

Further thoughts?

Thanks

------------------------------
Nathan

Original Message:
Sent: Dec 12, 2023 12:41 PM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

I don't know that using separate interfaces, one privately addressed and the other with a public IP, is a tested or supported configuration.  Expectation is that either the public IP address is used as the controller-ip (this was originally the only supported configuration for AOS 8 clusters and RAPs) or that a public IP address is configured to 1:1 NAT with the controller-ip and the cluster configuration has the "RAP public IP" specified.

UDP 4500 is the only port required to be opened to support RAP operation.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 12, 2023 12:11 PM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Trying to get RAPs operational but struggling.

I've read the articles on Flomain and the guide Aruba Remote Access Point Solution Guide for Tele workers and Home Offices, but I just can't get a win here.
Aruba Remote Access Point Solution Guide

Basic RAP Setup with ArubaOS 8 - Flomain Networking

RAP Cluster is 8.10.0.8
The RAP cluster sits under a higher config level as a separate 'RAP' folder, with the 2 hardware nodes in it. (Higher up are 3 Campus AP clusters)

The problem is our internal design - NAT off the border firewall can't work because the network the controllers are on is not routed to the border. Using an NSX load balancer doesn't work for NAT, because although the LB can host the public address and the LB has access to the controller's network, NSX wants to own the VPN endpoint, and we don't seem to be able to work around that.

So I'm going to have to put a public IP on the 2 controllers that I'm going to use for the RAP cluster.
Presently all our controllers only have one IP interface to which the Conductor, the APs, and the admins connect. 

Will the RAP part work if I leave the controllers are they are, but create a new interface on the controllers for the public IP, and leave everything else as it is? Or do I have to zeroise the controllers and start again? The current IP config isn't referred to as 'interface mgmt.'  

controller-ip vlan 628

vlan-name wifiag01-wifimgmt1
vlan wifiag01-wifimgmt1 628

interface vlan 628
    ip address xxx.xxx.xxx.xxx

My thought is to just add a new 'interface vlan xxx' using a public IP,  trunk it in, and specify that in the RAP-IP when I add the controllers to the RAP cluster
Can that work, or am I just smoking crack? 

If it doesn't work, is it a case of zeroise the the controllers, rebuild following the cli wizard, and the Conductor has to talk to the RAP controllers via their public IP, and at some point I set up a management interface?

Are any more ports than UDP 4500 required inbound on the perimeter, as I saw Florian mention 69 and 500, but I didn't spot that in the Aruba guide.

Thanks.

------------------------------
Nathan
------------------------------

I've not messed with RAP in quite a while but I don't think provisioning CAP to RAP will clear the entry out of the CPSec database.  The RAP process doesn't utilize CPSec.

Just athought while reading the AOS hardening guide and some comments about CPSec:
Once a campus AP has been provisioned as a RAP. should there be whitelist-db entries in BOTH cpsec and rap, like I have below, or should the AP now only exist in rap?

Yeah, I'm pretty sure I've got those bases covered. Thanks for the confirmation of the allow-list details.
I think I'm going to have to take the second controller, bin it from Conductor, wipe it, start again with public IP, and see what happens - takes NSX out of our traffic path. I'll update once I've done that, but it'll be next week now.

Quick edit: removed cluster config, delete one of the controllers, just a standalone controller now. Traffic comes in from the RAP, still get the same IKE warning and no association.  errcode:ERR_IKESA_CLEARED 
Onwards.

------------------------------
Nathan

Original Message:
Sent: Dec 13, 2023 09:33 AM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

The RAP allow-list only requires the MAC address, the RAP name, and AP group to identify the RAP. The RAP must be in the allow-list prior to the RAP being allowed to connect.  You can also use a MAC auth for RAP allowance in place of the static allow-list, and with ClearPass you can integrate with Activate to automatically synchronize the desired APs that you've purchased.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 13, 2023 08:47 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Thanks for posting, Carson.

We've got to a point now where the incoming RAP is seen by the controller, but the association isn't getting very far.

My earlier problem was that I was landing the incoming traffic on the LMS VIP - wrong. That's been changed to the controller's internal controller IP (same as the Conductor talks to).

I'm sure I read that I should be provisioning the RAP at the MN level. But the MN level doesn't contain the AP Groups  (only the group the AP is presently in), so I can't select the RAP group.  

So I'm provisioning down a level, and I can see what I need to see

In the Provision dialogue, I'm selecting 'static' and entering the public IP that is specified as the RAP-Public-IP in the cluster config. 

On the Conductor CLI I see the AP now in show whitelist-db rap, but no Remote-IP is specified. Should that be the controller's public IP, as specified during provisioning?
I can see that I can set is explicitly by modifying the whitelist, but doing so hasn't yielded any success.

When I look at the Remote AP Whitelist, should there be a defined entry in the IPv4 address field?

I've tried provisioning with certificate auth and with PSK auth. No joy with either.

I've tried provisioning with a Trust Anchor of none and self-signed. No joy with either.

When looking at the connected controller security log, I just can't get past "IKE SA Deletion: IKE2_delSa peer:...."

Further thoughts?

Thanks

------------------------------
Nathan

Original Message:
Sent: Dec 12, 2023 12:41 PM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

I don't know that using separate interfaces, one privately addressed and the other with a public IP, is a tested or supported configuration.  Expectation is that either the public IP address is used as the controller-ip (this was originally the only supported configuration for AOS 8 clusters and RAPs) or that a public IP address is configured to 1:1 NAT with the controller-ip and the cluster configuration has the "RAP public IP" specified.

UDP 4500 is the only port required to be opened to support RAP operation.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 12, 2023 12:11 PM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Trying to get RAPs operational but struggling.

I've read the articles on Flomain and the guide Aruba Remote Access Point Solution Guide for Tele workers and Home Offices, but I just can't get a win here.
Aruba Remote Access Point Solution Guide

Basic RAP Setup with ArubaOS 8 - Flomain Networking

RAP Cluster is 8.10.0.8
The RAP cluster sits under a higher config level as a separate 'RAP' folder, with the 2 hardware nodes in it. (Higher up are 3 Campus AP clusters)

The problem is our internal design - NAT off the border firewall can't work because the network the controllers are on is not routed to the border. Using an NSX load balancer doesn't work for NAT, because although the LB can host the public address and the LB has access to the controller's network, NSX wants to own the VPN endpoint, and we don't seem to be able to work around that.

So I'm going to have to put a public IP on the 2 controllers that I'm going to use for the RAP cluster.
Presently all our controllers only have one IP interface to which the Conductor, the APs, and the admins connect. 

Will the RAP part work if I leave the controllers are they are, but create a new interface on the controllers for the public IP, and leave everything else as it is? Or do I have to zeroise the controllers and start again? The current IP config isn't referred to as 'interface mgmt.'  

controller-ip vlan 628

vlan-name wifiag01-wifimgmt1
vlan wifiag01-wifimgmt1 628

interface vlan 628
    ip address xxx.xxx.xxx.xxx

My thought is to just add a new 'interface vlan xxx' using a public IP,  trunk it in, and specify that in the RAP-IP when I add the controllers to the RAP cluster
Can that work, or am I just smoking crack? 

If it doesn't work, is it a case of zeroise the the controllers, rebuild following the cli wizard, and the Conductor has to talk to the RAP controllers via their public IP, and at some point I set up a management interface?

Are any more ports than UDP 4500 required inbound on the perimeter, as I saw Florian mention 69 and 500, but I didn't spot that in the Aruba guide.

Thanks.

------------------------------
Nathan
------------------------------

Recent steps taken:
Removed a controller from the Conductor > zeroised it using the front panel buttons > dealt with internal networking to get public IP VLAN to controller > perimeter firewall rules to allow UDP 4500 to the controller public IP and deny everything else to that IP > full-setup of controller with the public IP > test connectivity internally (success) > test port 4500 to IP is open from outside (success) > bring AP up on internal controllers (cpsec whitelist) > Provision AP to remote with static controller IP of the external IP > approve AP in remote whitelist > allow AP to reboot......

Aaaaand nothing.

I can see that the AP has booted, got a local address for itself, and references the correct public IP for the controller
Checked perimeter FW to look for incoming connection to the controller on port 4500, but there's nothing there from the AP (plenty of other public attempts on 4500, mind).
There's nothing stopping the AP talking out, it's coming from the same outside network that i used to prove the 4500 is open. 
When I was attempting this with NAT previously, the AP was hitting the FW, but the NAT process was failing because of internal NSX 'things.' NSX is out of the picture now; it's just be a straight through connection now, though I do still have NAT-T configured on the VPN config on the MCR. 

Find it odd that previous config pushed during remote provisioning allowed the AP to talk out to the public IP, but now it can't.
Still looking.

------------------------------
Nathan

Original Message:
Sent: Dec 14, 2023 08:52 AM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

I've not messed with RAP in quite a while but I don't think provisioning CAP to RAP will clear the entry out of the CPSec database.  The RAP process doesn't utilize CPSec.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 14, 2023 08:46 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Just athought while reading the AOS hardening guide and some comments about CPSec:
Once a campus AP has been provisioned as a RAP. should there be whitelist-db entries in BOTH cpsec and rap, like I have below, or should the AP now only exist in rap?

------------------------------
Nathan

Original Message:
Sent: Dec 13, 2023 12:06 PM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Yeah, I'm pretty sure I've got those bases covered. Thanks for the confirmation of the allow-list details.
I think I'm going to have to take the second controller, bin it from Conductor, wipe it, start again with public IP, and see what happens - takes NSX out of our traffic path. I'll update once I've done that, but it'll be next week now.

Quick edit: removed cluster config, delete one of the controllers, just a standalone controller now. Traffic comes in from the RAP, still get the same IKE warning and no association.  errcode:ERR_IKESA_CLEARED 
Onwards.

------------------------------
Nathan

Original Message:
Sent: Dec 13, 2023 09:33 AM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

The RAP allow-list only requires the MAC address, the RAP name, and AP group to identify the RAP. The RAP must be in the allow-list prior to the RAP being allowed to connect.  You can also use a MAC auth for RAP allowance in place of the static allow-list, and with ClearPass you can integrate with Activate to automatically synchronize the desired APs that you've purchased.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 13, 2023 08:47 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Thanks for posting, Carson.

We've got to a point now where the incoming RAP is seen by the controller, but the association isn't getting very far.

My earlier problem was that I was landing the incoming traffic on the LMS VIP - wrong. That's been changed to the controller's internal controller IP (same as the Conductor talks to).

I'm sure I read that I should be provisioning the RAP at the MN level. But the MN level doesn't contain the AP Groups  (only the group the AP is presently in), so I can't select the RAP group.  

So I'm provisioning down a level, and I can see what I need to see

In the Provision dialogue, I'm selecting 'static' and entering the public IP that is specified as the RAP-Public-IP in the cluster config. 

On the Conductor CLI I see the AP now in show whitelist-db rap, but no Remote-IP is specified. Should that be the controller's public IP, as specified during provisioning?
I can see that I can set is explicitly by modifying the whitelist, but doing so hasn't yielded any success.

When I look at the Remote AP Whitelist, should there be a defined entry in the IPv4 address field?

I've tried provisioning with certificate auth and with PSK auth. No joy with either.

I've tried provisioning with a Trust Anchor of none and self-signed. No joy with either.

When looking at the connected controller security log, I just can't get past "IKE SA Deletion: IKE2_delSa peer:...."

Further thoughts?

Thanks

------------------------------
Nathan

Original Message:
Sent: Dec 12, 2023 12:41 PM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

I don't know that using separate interfaces, one privately addressed and the other with a public IP, is a tested or supported configuration.  Expectation is that either the public IP address is used as the controller-ip (this was originally the only supported configuration for AOS 8 clusters and RAPs) or that a public IP address is configured to 1:1 NAT with the controller-ip and the cluster configuration has the "RAP public IP" specified.

UDP 4500 is the only port required to be opened to support RAP operation.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 12, 2023 12:11 PM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Trying to get RAPs operational but struggling.

I've read the articles on Flomain and the guide Aruba Remote Access Point Solution Guide for Tele workers and Home Offices, but I just can't get a win here.
Aruba Remote Access Point Solution Guide

Basic RAP Setup with ArubaOS 8 - Flomain Networking

RAP Cluster is 8.10.0.8
The RAP cluster sits under a higher config level as a separate 'RAP' folder, with the 2 hardware nodes in it. (Higher up are 3 Campus AP clusters)

The problem is our internal design - NAT off the border firewall can't work because the network the controllers are on is not routed to the border. Using an NSX load balancer doesn't work for NAT, because although the LB can host the public address and the LB has access to the controller's network, NSX wants to own the VPN endpoint, and we don't seem to be able to work around that.

So I'm going to have to put a public IP on the 2 controllers that I'm going to use for the RAP cluster.
Presently all our controllers only have one IP interface to which the Conductor, the APs, and the admins connect. 

Will the RAP part work if I leave the controllers are they are, but create a new interface on the controllers for the public IP, and leave everything else as it is? Or do I have to zeroise the controllers and start again? The current IP config isn't referred to as 'interface mgmt.'  

controller-ip vlan 628

vlan-name wifiag01-wifimgmt1
vlan wifiag01-wifimgmt1 628

interface vlan 628
    ip address xxx.xxx.xxx.xxx

My thought is to just add a new 'interface vlan xxx' using a public IP,  trunk it in, and specify that in the RAP-IP when I add the controllers to the RAP cluster
Can that work, or am I just smoking crack? 

If it doesn't work, is it a case of zeroise the the controllers, rebuild following the cli wizard, and the Conductor has to talk to the RAP controllers via their public IP, and at some point I set up a management interface?

Are any more ports than UDP 4500 required inbound on the perimeter, as I saw Florian mention 69 and 500, but I didn't spot that in the Aruba guide.

Thanks.

------------------------------
Nathan
------------------------------

Turns out the firewall monitor wasn't updating as fast as I thought it did. The RAP is coming in to the controller via the public controller IP, the FW is recording the permitted connection on 4500. But the console message from the AP is that the IPSec couldn't be established after 83 attempts.

Getting the IKE messages on the controller as I was getting when doing NAT on the perimeter, so even though there's a public IP on the controller, I'm no further forward.

Seems odd that the ports referenced here are 7445 or 27089, but on the FW it is 4500. Wonder if this is part of the problem.
------------------------------
Nathan

Original Message:
Sent: Dec 20, 2023 07:17 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Recent steps taken:
Removed a controller from the Conductor > zeroised it using the front panel buttons > dealt with internal networking to get public IP VLAN to controller > perimeter firewall rules to allow UDP 4500 to the controller public IP and deny everything else to that IP > full-setup of controller with the public IP > test connectivity internally (success) > test port 4500 to IP is open from outside (success) > bring AP up on internal controllers (cpsec whitelist) > Provision AP to remote with static controller IP of the external IP > approve AP in remote whitelist > allow AP to reboot......

Aaaaand nothing.

I can see that the AP has booted, got a local address for itself, and references the correct public IP for the controller
Checked perimeter FW to look for incoming connection to the controller on port 4500, but there's nothing there from the AP (plenty of other public attempts on 4500, mind).
There's nothing stopping the AP talking out, it's coming from the same outside network that i used to prove the 4500 is open. 
When I was attempting this with NAT previously, the AP was hitting the FW, but the NAT process was failing because of internal NSX 'things.' NSX is out of the picture now; it's just be a straight through connection now, though I do still have NAT-T configured on the VPN config on the MCR. 

Find it odd that previous config pushed during remote provisioning allowed the AP to talk out to the public IP, but now it can't.
Still looking.

------------------------------
Nathan

Original Message:
Sent: Dec 14, 2023 08:52 AM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

I've not messed with RAP in quite a while but I don't think provisioning CAP to RAP will clear the entry out of the CPSec database.  The RAP process doesn't utilize CPSec.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 14, 2023 08:46 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Just athought while reading the AOS hardening guide and some comments about CPSec:
Once a campus AP has been provisioned as a RAP. should there be whitelist-db entries in BOTH cpsec and rap, like I have below, or should the AP now only exist in rap?

------------------------------
Nathan

Original Message:
Sent: Dec 13, 2023 12:06 PM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Yeah, I'm pretty sure I've got those bases covered. Thanks for the confirmation of the allow-list details.
I think I'm going to have to take the second controller, bin it from Conductor, wipe it, start again with public IP, and see what happens - takes NSX out of our traffic path. I'll update once I've done that, but it'll be next week now.

Quick edit: removed cluster config, delete one of the controllers, just a standalone controller now. Traffic comes in from the RAP, still get the same IKE warning and no association.  errcode:ERR_IKESA_CLEARED 
Onwards.

------------------------------
Nathan

Original Message:
Sent: Dec 13, 2023 09:33 AM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

The RAP allow-list only requires the MAC address, the RAP name, and AP group to identify the RAP. The RAP must be in the allow-list prior to the RAP being allowed to connect.  You can also use a MAC auth for RAP allowance in place of the static allow-list, and with ClearPass you can integrate with Activate to automatically synchronize the desired APs that you've purchased.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 13, 2023 08:47 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Thanks for posting, Carson.

We've got to a point now where the incoming RAP is seen by the controller, but the association isn't getting very far.

My earlier problem was that I was landing the incoming traffic on the LMS VIP - wrong. That's been changed to the controller's internal controller IP (same as the Conductor talks to).

I'm sure I read that I should be provisioning the RAP at the MN level. But the MN level doesn't contain the AP Groups  (only the group the AP is presently in), so I can't select the RAP group.  

So I'm provisioning down a level, and I can see what I need to see

In the Provision dialogue, I'm selecting 'static' and entering the public IP that is specified as the RAP-Public-IP in the cluster config. 

On the Conductor CLI I see the AP now in show whitelist-db rap, but no Remote-IP is specified. Should that be the controller's public IP, as specified during provisioning?
I can see that I can set is explicitly by modifying the whitelist, but doing so hasn't yielded any success.

When I look at the Remote AP Whitelist, should there be a defined entry in the IPv4 address field?

I've tried provisioning with certificate auth and with PSK auth. No joy with either.

I've tried provisioning with a Trust Anchor of none and self-signed. No joy with either.

When looking at the connected controller security log, I just can't get past "IKE SA Deletion: IKE2_delSa peer:...."

Further thoughts?

Thanks

------------------------------
Nathan

Original Message:
Sent: Dec 12, 2023 12:41 PM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

I don't know that using separate interfaces, one privately addressed and the other with a public IP, is a tested or supported configuration.  Expectation is that either the public IP address is used as the controller-ip (this was originally the only supported configuration for AOS 8 clusters and RAPs) or that a public IP address is configured to 1:1 NAT with the controller-ip and the cluster configuration has the "RAP public IP" specified.

UDP 4500 is the only port required to be opened to support RAP operation.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 12, 2023 12:11 PM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Trying to get RAPs operational but struggling.

I've read the articles on Flomain and the guide Aruba Remote Access Point Solution Guide for Tele workers and Home Offices, but I just can't get a win here.
Aruba Remote Access Point Solution Guide

Basic RAP Setup with ArubaOS 8 - Flomain Networking

RAP Cluster is 8.10.0.8
The RAP cluster sits under a higher config level as a separate 'RAP' folder, with the 2 hardware nodes in it. (Higher up are 3 Campus AP clusters)

The problem is our internal design - NAT off the border firewall can't work because the network the controllers are on is not routed to the border. Using an NSX load balancer doesn't work for NAT, because although the LB can host the public address and the LB has access to the controller's network, NSX wants to own the VPN endpoint, and we don't seem to be able to work around that.

So I'm going to have to put a public IP on the 2 controllers that I'm going to use for the RAP cluster.
Presently all our controllers only have one IP interface to which the Conductor, the APs, and the admins connect. 

Will the RAP part work if I leave the controllers are they are, but create a new interface on the controllers for the public IP, and leave everything else as it is? Or do I have to zeroise the controllers and start again? The current IP config isn't referred to as 'interface mgmt.'  

controller-ip vlan 628

vlan-name wifiag01-wifimgmt1
vlan wifiag01-wifimgmt1 628

interface vlan 628
    ip address xxx.xxx.xxx.xxx

My thought is to just add a new 'interface vlan xxx' using a public IP,  trunk it in, and specify that in the RAP-IP when I add the controllers to the RAP cluster
Can that work, or am I just smoking crack? 

If it doesn't work, is it a case of zeroise the the controllers, rebuild following the cli wizard, and the Conductor has to talk to the RAP controllers via their public IP, and at some point I set up a management interface?

Are any more ports than UDP 4500 required inbound on the perimeter, as I saw Florian mention 69 and 500, but I didn't spot that in the Aruba guide.

Thanks.

------------------------------
Nathan
------------------------------

Probably worth opening a case with TAC to troubleshoot from this point.

Also, the incoming traffic from the RAP will be to the controller on port 4500, the source port can be anything.  What you are seeing there is the peer association timing out.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 20, 2023 10:01 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Turns out the firewall monitor wasn't updating as fast as I thought it did. The RAP is coming in to the controller via the public controller IP, the FW is recording the permitted connection on 4500. But the console message from the AP is that the IPSec couldn't be established after 83 attempts.

Getting the IKE messages on the controller as I was getting when doing NAT on the perimeter, so even though there's a public IP on the controller, I'm no further forward.

Seems odd that the ports referenced here are 7445 or 27089, but on the FW it is 4500. Wonder if this is part of the problem.
------------------------------
Nathan

Original Message:
Sent: Dec 20, 2023 07:17 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Recent steps taken:
Removed a controller from the Conductor > zeroised it using the front panel buttons > dealt with internal networking to get public IP VLAN to controller > perimeter firewall rules to allow UDP 4500 to the controller public IP and deny everything else to that IP > full-setup of controller with the public IP > test connectivity internally (success) > test port 4500 to IP is open from outside (success) > bring AP up on internal controllers (cpsec whitelist) > Provision AP to remote with static controller IP of the external IP > approve AP in remote whitelist > allow AP to reboot......

Aaaaand nothing.

I can see that the AP has booted, got a local address for itself, and references the correct public IP for the controller
Checked perimeter FW to look for incoming connection to the controller on port 4500, but there's nothing there from the AP (plenty of other public attempts on 4500, mind).
There's nothing stopping the AP talking out, it's coming from the same outside network that i used to prove the 4500 is open. 
When I was attempting this with NAT previously, the AP was hitting the FW, but the NAT process was failing because of internal NSX 'things.' NSX is out of the picture now; it's just be a straight through connection now, though I do still have NAT-T configured on the VPN config on the MCR. 

Find it odd that previous config pushed during remote provisioning allowed the AP to talk out to the public IP, but now it can't.
Still looking.

------------------------------
Nathan

Original Message:
Sent: Dec 14, 2023 08:52 AM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

I've not messed with RAP in quite a while but I don't think provisioning CAP to RAP will clear the entry out of the CPSec database.  The RAP process doesn't utilize CPSec.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 14, 2023 08:46 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Just athought while reading the AOS hardening guide and some comments about CPSec:
Once a campus AP has been provisioned as a RAP. should there be whitelist-db entries in BOTH cpsec and rap, like I have below, or should the AP now only exist in rap?

------------------------------
Nathan

Original Message:
Sent: Dec 13, 2023 12:06 PM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Yeah, I'm pretty sure I've got those bases covered. Thanks for the confirmation of the allow-list details.
I think I'm going to have to take the second controller, bin it from Conductor, wipe it, start again with public IP, and see what happens - takes NSX out of our traffic path. I'll update once I've done that, but it'll be next week now.

Quick edit: removed cluster config, delete one of the controllers, just a standalone controller now. Traffic comes in from the RAP, still get the same IKE warning and no association.  errcode:ERR_IKESA_CLEARED 
Onwards.

------------------------------
Nathan

Original Message:
Sent: Dec 13, 2023 09:33 AM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

The RAP allow-list only requires the MAC address, the RAP name, and AP group to identify the RAP. The RAP must be in the allow-list prior to the RAP being allowed to connect.  You can also use a MAC auth for RAP allowance in place of the static allow-list, and with ClearPass you can integrate with Activate to automatically synchronize the desired APs that you've purchased.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 13, 2023 08:47 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Thanks for posting, Carson.

We've got to a point now where the incoming RAP is seen by the controller, but the association isn't getting very far.

My earlier problem was that I was landing the incoming traffic on the LMS VIP - wrong. That's been changed to the controller's internal controller IP (same as the Conductor talks to).

I'm sure I read that I should be provisioning the RAP at the MN level. But the MN level doesn't contain the AP Groups  (only the group the AP is presently in), so I can't select the RAP group.  

So I'm provisioning down a level, and I can see what I need to see

In the Provision dialogue, I'm selecting 'static' and entering the public IP that is specified as the RAP-Public-IP in the cluster config. 

On the Conductor CLI I see the AP now in show whitelist-db rap, but no Remote-IP is specified. Should that be the controller's public IP, as specified during provisioning?
I can see that I can set is explicitly by modifying the whitelist, but doing so hasn't yielded any success.

When I look at the Remote AP Whitelist, should there be a defined entry in the IPv4 address field?

I've tried provisioning with certificate auth and with PSK auth. No joy with either.

I've tried provisioning with a Trust Anchor of none and self-signed. No joy with either.

When looking at the connected controller security log, I just can't get past "IKE SA Deletion: IKE2_delSa peer:...."

Further thoughts?

Thanks

------------------------------
Nathan

Original Message:
Sent: Dec 12, 2023 12:41 PM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

I don't know that using separate interfaces, one privately addressed and the other with a public IP, is a tested or supported configuration.  Expectation is that either the public IP address is used as the controller-ip (this was originally the only supported configuration for AOS 8 clusters and RAPs) or that a public IP address is configured to 1:1 NAT with the controller-ip and the cluster configuration has the "RAP public IP" specified.

UDP 4500 is the only port required to be opened to support RAP operation.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 12, 2023 12:11 PM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Trying to get RAPs operational but struggling.

I've read the articles on Flomain and the guide Aruba Remote Access Point Solution Guide for Tele workers and Home Offices, but I just can't get a win here.
Aruba Remote Access Point Solution Guide

Basic RAP Setup with ArubaOS 8 - Flomain Networking

RAP Cluster is 8.10.0.8
The RAP cluster sits under a higher config level as a separate 'RAP' folder, with the 2 hardware nodes in it. (Higher up are 3 Campus AP clusters)

The problem is our internal design - NAT off the border firewall can't work because the network the controllers are on is not routed to the border. Using an NSX load balancer doesn't work for NAT, because although the LB can host the public address and the LB has access to the controller's network, NSX wants to own the VPN endpoint, and we don't seem to be able to work around that.

So I'm going to have to put a public IP on the 2 controllers that I'm going to use for the RAP cluster.
Presently all our controllers only have one IP interface to which the Conductor, the APs, and the admins connect. 

Will the RAP part work if I leave the controllers are they are, but create a new interface on the controllers for the public IP, and leave everything else as it is? Or do I have to zeroise the controllers and start again? The current IP config isn't referred to as 'interface mgmt.'  

controller-ip vlan 628

vlan-name wifiag01-wifimgmt1
vlan wifiag01-wifimgmt1 628

interface vlan 628
    ip address xxx.xxx.xxx.xxx

My thought is to just add a new 'interface vlan xxx' using a public IP,  trunk it in, and specify that in the RAP-IP when I add the controllers to the RAP cluster
Can that work, or am I just smoking crack? 

If it doesn't work, is it a case of zeroise the the controllers, rebuild following the cli wizard, and the Conductor has to talk to the RAP controllers via their public IP, and at some point I set up a management interface?

Are any more ports than UDP 4500 required inbound on the perimeter, as I saw Florian mention 69 and 500, but I didn't spot that in the Aruba guide.

Thanks.

------------------------------
Nathan
------------------------------

Morning,

Did a pcap off the Palo perimeter.
Figured it must be OK for the source port to be anything as the connection is allowed.
We never get any traffic going back out. No filtering happening, it's just not there.
We're about to close for the holidays. Will take this up with TAC as you suggest. I'll draft the email and have it auto send on Jan 2nd.
I'll post back when I know more.

Season's best
Nathan

Probably worth opening a case with TAC to troubleshoot from this point.

Also, the incoming traffic from the RAP will be to the controller on port 4500, the source port can be anything.  What you are seeing there is the peer association timing out.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 20, 2023 10:01 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Turns out the firewall monitor wasn't updating as fast as I thought it did. The RAP is coming in to the controller via the public controller IP, the FW is recording the permitted connection on 4500. But the console message from the AP is that the IPSec couldn't be established after 83 attempts.

Getting the IKE messages on the controller as I was getting when doing NAT on the perimeter, so even though there's a public IP on the controller, I'm no further forward.

Seems odd that the ports referenced here are 7445 or 27089, but on the FW it is 4500. Wonder if this is part of the problem.
------------------------------
Nathan

Original Message:
Sent: Dec 20, 2023 07:17 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Recent steps taken:
Removed a controller from the Conductor > zeroised it using the front panel buttons > dealt with internal networking to get public IP VLAN to controller > perimeter firewall rules to allow UDP 4500 to the controller public IP and deny everything else to that IP > full-setup of controller with the public IP > test connectivity internally (success) > test port 4500 to IP is open from outside (success) > bring AP up on internal controllers (cpsec whitelist) > Provision AP to remote with static controller IP of the external IP > approve AP in remote whitelist > allow AP to reboot......

Aaaaand nothing.

I can see that the AP has booted, got a local address for itself, and references the correct public IP for the controller
Checked perimeter FW to look for incoming connection to the controller on port 4500, but there's nothing there from the AP (plenty of other public attempts on 4500, mind).
There's nothing stopping the AP talking out, it's coming from the same outside network that i used to prove the 4500 is open. 
When I was attempting this with NAT previously, the AP was hitting the FW, but the NAT process was failing because of internal NSX 'things.' NSX is out of the picture now; it's just be a straight through connection now, though I do still have NAT-T configured on the VPN config on the MCR. 

Find it odd that previous config pushed during remote provisioning allowed the AP to talk out to the public IP, but now it can't.
Still looking.

------------------------------
Nathan

Original Message:
Sent: Dec 14, 2023 08:52 AM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

I've not messed with RAP in quite a while but I don't think provisioning CAP to RAP will clear the entry out of the CPSec database.  The RAP process doesn't utilize CPSec.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 14, 2023 08:46 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Just athought while reading the AOS hardening guide and some comments about CPSec:
Once a campus AP has been provisioned as a RAP. should there be whitelist-db entries in BOTH cpsec and rap, like I have below, or should the AP now only exist in rap?

------------------------------
Nathan

Original Message:
Sent: Dec 13, 2023 12:06 PM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Yeah, I'm pretty sure I've got those bases covered. Thanks for the confirmation of the allow-list details.
I think I'm going to have to take the second controller, bin it from Conductor, wipe it, start again with public IP, and see what happens - takes NSX out of our traffic path. I'll update once I've done that, but it'll be next week now.

Quick edit: removed cluster config, delete one of the controllers, just a standalone controller now. Traffic comes in from the RAP, still get the same IKE warning and no association.  errcode:ERR_IKESA_CLEARED 
Onwards.

------------------------------
Nathan

Original Message:
Sent: Dec 13, 2023 09:33 AM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

The RAP allow-list only requires the MAC address, the RAP name, and AP group to identify the RAP. The RAP must be in the allow-list prior to the RAP being allowed to connect.  You can also use a MAC auth for RAP allowance in place of the static allow-list, and with ClearPass you can integrate with Activate to automatically synchronize the desired APs that you've purchased.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 13, 2023 08:47 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Thanks for posting, Carson.

We've got to a point now where the incoming RAP is seen by the controller, but the association isn't getting very far.

My earlier problem was that I was landing the incoming traffic on the LMS VIP - wrong. That's been changed to the controller's internal controller IP (same as the Conductor talks to).

I'm sure I read that I should be provisioning the RAP at the MN level. But the MN level doesn't contain the AP Groups  (only the group the AP is presently in), so I can't select the RAP group.  

So I'm provisioning down a level, and I can see what I need to see

In the Provision dialogue, I'm selecting 'static' and entering the public IP that is specified as the RAP-Public-IP in the cluster config. 

On the Conductor CLI I see the AP now in show whitelist-db rap, but no Remote-IP is specified. Should that be the controller's public IP, as specified during provisioning?
I can see that I can set is explicitly by modifying the whitelist, but doing so hasn't yielded any success.

When I look at the Remote AP Whitelist, should there be a defined entry in the IPv4 address field?

I've tried provisioning with certificate auth and with PSK auth. No joy with either.

I've tried provisioning with a Trust Anchor of none and self-signed. No joy with either.

When looking at the connected controller security log, I just can't get past "IKE SA Deletion: IKE2_delSa peer:...."

Further thoughts?

Thanks

------------------------------
Nathan

Original Message:
Sent: Dec 12, 2023 12:41 PM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

I don't know that using separate interfaces, one privately addressed and the other with a public IP, is a tested or supported configuration.  Expectation is that either the public IP address is used as the controller-ip (this was originally the only supported configuration for AOS 8 clusters and RAPs) or that a public IP address is configured to 1:1 NAT with the controller-ip and the cluster configuration has the "RAP public IP" specified.

UDP 4500 is the only port required to be opened to support RAP operation.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 12, 2023 12:11 PM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Trying to get RAPs operational but struggling.

I've read the articles on Flomain and the guide Aruba Remote Access Point Solution Guide for Tele workers and Home Offices, but I just can't get a win here.
Aruba Remote Access Point Solution Guide

Basic RAP Setup with ArubaOS 8 - Flomain Networking

RAP Cluster is 8.10.0.8
The RAP cluster sits under a higher config level as a separate 'RAP' folder, with the 2 hardware nodes in it. (Higher up are 3 Campus AP clusters)

The problem is our internal design - NAT off the border firewall can't work because the network the controllers are on is not routed to the border. Using an NSX load balancer doesn't work for NAT, because although the LB can host the public address and the LB has access to the controller's network, NSX wants to own the VPN endpoint, and we don't seem to be able to work around that.

So I'm going to have to put a public IP on the 2 controllers that I'm going to use for the RAP cluster.
Presently all our controllers only have one IP interface to which the Conductor, the APs, and the admins connect. 

Will the RAP part work if I leave the controllers are they are, but create a new interface on the controllers for the public IP, and leave everything else as it is? Or do I have to zeroise the controllers and start again? The current IP config isn't referred to as 'interface mgmt.'  

controller-ip vlan 628

vlan-name wifiag01-wifimgmt1
vlan wifiag01-wifimgmt1 628

interface vlan 628
    ip address xxx.xxx.xxx.xxx

My thought is to just add a new 'interface vlan xxx' using a public IP,  trunk it in, and specify that in the RAP-IP when I add the controllers to the RAP cluster
Can that work, or am I just smoking crack? 

If it doesn't work, is it a case of zeroise the the controllers, rebuild following the cli wizard, and the Conductor has to talk to the RAP controllers via their public IP, and at some point I set up a management interface?

Are any more ports than UDP 4500 required inbound on the perimeter, as I saw Florian mention 69 and 500, but I didn't spot that in the Aruba guide.

Thanks.

------------------------------
Nathan
------------------------------

A bit of progress - 

Elevated logging level for Security on the controller to debugging, then checked the CLI output.

"authmgr[4007]: <124004> <4007> <DBUG> |authmgr|  auth server status 0 for server net-cp01  group default sent to process 8551"

So the controller was using the 'default' server group to auth the incoming AP, and was trying to use our ClearPass01 server - which would never work.
No other config uses the default server group, so I had a look. Our 2 ClearPass servers were in the default group, and could not be deleted. I don't recall manually adding them there,  and we only use ClearPass in the ClearPass Group for Guest WiFi and MPSK clients. 

So I moved the 'internal' server up above both ClearPass servers.

This resulted in the RAP being authenticated against the 'Internal' server - where the whitelist is stored.

[Yesterday 3:33 PM] Millward, Nathan

Jan  9 15:15:57 2024  localdb[4084]: <133005> <4084> <INFO> |localdb|  User 28:de:65:04:b6:44  Successfully Authenticated
Jan  9 15:15:57 2024  authmgr[4007]: <124453> <4007> <DBUG> |authmgr|  auth_user_query_resp: response user:28:de:65:04:b6:44 ip:217.114.50.230 
Jan  9 15:15:57 2024  authmgr[4007]: <124184> <4007> <DBUG> |authmgr|  {L3} Authenticating Server is Internal.

The MM showed the RAP was now up, but I couldn't test anything as I was working remotely.

This morning I got to the office and the RAP was offline. No idea why.
I've changed the VPN Authentication > default-rap server group to Internal - no need for it to use default, but this hasn't helped.
I can see the RAP coming up, but getting dropped for some unknown reason.

Jan 10 11:41:12 2024  isakmpd[3953]: <103082> <3953> <INFO> |ike|  IKEv2 Client-Authentication succeeded for 172.16.1.21 (External 217.114.50.230) for default-vpn-role
Jan 10 11:41:12 2024  authmgr[4007]: <124458> <4007> <DBUG> |authmgr|  IP UP int: 172.16.1.21, ext:217.114.50.230 flags 0x2

.
.
.

Jan 10 11:41:22 2024  isakmpd[3953]: <103063> <3953> <DBUG> |ike|   IPSEC_deleteSaByInnerIPExtIP delete IPSEC SA 217.114.50.230:(inner:172.16.1.21)
Jan 10 11:41:22 2024  isakmpd[3953]: <103101> <3953> <INFO> |ike|  IPSEC SA deleted for peer 217.114.50.230

So something worked, then it didn't. The problem was configurational, and I can only guess that still must be the case.
I'll keep looking.

Morning,

Did a pcap off the Palo perimeter.
Figured it must be OK for the source port to be anything as the connection is allowed.
We never get any traffic going back out. No filtering happening, it's just not there.
We're about to close for the holidays. Will take this up with TAC as you suggest. I'll draft the email and have it auto send on Jan 2nd.
I'll post back when I know more.

Season's best
Nathan

Probably worth opening a case with TAC to troubleshoot from this point.

Also, the incoming traffic from the RAP will be to the controller on port 4500, the source port can be anything.  What you are seeing there is the peer association timing out.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 20, 2023 10:01 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Turns out the firewall monitor wasn't updating as fast as I thought it did. The RAP is coming in to the controller via the public controller IP, the FW is recording the permitted connection on 4500. But the console message from the AP is that the IPSec couldn't be established after 83 attempts.

Getting the IKE messages on the controller as I was getting when doing NAT on the perimeter, so even though there's a public IP on the controller, I'm no further forward.

Seems odd that the ports referenced here are 7445 or 27089, but on the FW it is 4500. Wonder if this is part of the problem.
------------------------------
Nathan

Original Message:
Sent: Dec 20, 2023 07:17 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Recent steps taken:
Removed a controller from the Conductor > zeroised it using the front panel buttons > dealt with internal networking to get public IP VLAN to controller > perimeter firewall rules to allow UDP 4500 to the controller public IP and deny everything else to that IP > full-setup of controller with the public IP > test connectivity internally (success) > test port 4500 to IP is open from outside (success) > bring AP up on internal controllers (cpsec whitelist) > Provision AP to remote with static controller IP of the external IP > approve AP in remote whitelist > allow AP to reboot......

Aaaaand nothing.

I can see that the AP has booted, got a local address for itself, and references the correct public IP for the controller
Checked perimeter FW to look for incoming connection to the controller on port 4500, but there's nothing there from the AP (plenty of other public attempts on 4500, mind).
There's nothing stopping the AP talking out, it's coming from the same outside network that i used to prove the 4500 is open. 
When I was attempting this with NAT previously, the AP was hitting the FW, but the NAT process was failing because of internal NSX 'things.' NSX is out of the picture now; it's just be a straight through connection now, though I do still have NAT-T configured on the VPN config on the MCR. 

Find it odd that previous config pushed during remote provisioning allowed the AP to talk out to the public IP, but now it can't.
Still looking.

------------------------------
Nathan

Original Message:
Sent: Dec 14, 2023 08:52 AM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

I've not messed with RAP in quite a while but I don't think provisioning CAP to RAP will clear the entry out of the CPSec database.  The RAP process doesn't utilize CPSec.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 14, 2023 08:46 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Just athought while reading the AOS hardening guide and some comments about CPSec:
Once a campus AP has been provisioned as a RAP. should there be whitelist-db entries in BOTH cpsec and rap, like I have below, or should the AP now only exist in rap?

------------------------------
Nathan

Original Message:
Sent: Dec 13, 2023 12:06 PM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Yeah, I'm pretty sure I've got those bases covered. Thanks for the confirmation of the allow-list details.
I think I'm going to have to take the second controller, bin it from Conductor, wipe it, start again with public IP, and see what happens - takes NSX out of our traffic path. I'll update once I've done that, but it'll be next week now.

Quick edit: removed cluster config, delete one of the controllers, just a standalone controller now. Traffic comes in from the RAP, still get the same IKE warning and no association.  errcode:ERR_IKESA_CLEARED 
Onwards.

------------------------------
Nathan

Original Message:
Sent: Dec 13, 2023 09:33 AM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

The RAP allow-list only requires the MAC address, the RAP name, and AP group to identify the RAP. The RAP must be in the allow-list prior to the RAP being allowed to connect.  You can also use a MAC auth for RAP allowance in place of the static allow-list, and with ClearPass you can integrate with Activate to automatically synchronize the desired APs that you've purchased.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 13, 2023 08:47 AM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Thanks for posting, Carson.

We've got to a point now where the incoming RAP is seen by the controller, but the association isn't getting very far.

My earlier problem was that I was landing the incoming traffic on the LMS VIP - wrong. That's been changed to the controller's internal controller IP (same as the Conductor talks to).

I'm sure I read that I should be provisioning the RAP at the MN level. But the MN level doesn't contain the AP Groups  (only the group the AP is presently in), so I can't select the RAP group.  

So I'm provisioning down a level, and I can see what I need to see

In the Provision dialogue, I'm selecting 'static' and entering the public IP that is specified as the RAP-Public-IP in the cluster config. 

On the Conductor CLI I see the AP now in show whitelist-db rap, but no Remote-IP is specified. Should that be the controller's public IP, as specified during provisioning?
I can see that I can set is explicitly by modifying the whitelist, but doing so hasn't yielded any success.

When I look at the Remote AP Whitelist, should there be a defined entry in the IPv4 address field?

I've tried provisioning with certificate auth and with PSK auth. No joy with either.

I've tried provisioning with a Trust Anchor of none and self-signed. No joy with either.

When looking at the connected controller security log, I just can't get past "IKE SA Deletion: IKE2_delSa peer:...."

Further thoughts?

Thanks

------------------------------
Nathan

Original Message:
Sent: Dec 12, 2023 12:41 PM
From: chulcher
Subject: RAP cluster creation without having to zeroise the controllers

I don't know that using separate interfaces, one privately addressed and the other with a public IP, is a tested or supported configuration.  Expectation is that either the public IP address is used as the controller-ip (this was originally the only supported configuration for AOS 8 clusters and RAPs) or that a public IP address is configured to 1:1 NAT with the controller-ip and the cluster configuration has the "RAP public IP" specified.

UDP 4500 is the only port required to be opened to support RAP operation.

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Dec 12, 2023 12:11 PM
From: n.millward
Subject: RAP cluster creation without having to zeroise the controllers

Trying to get RAPs operational but struggling.

I've read the articles on Flomain and the guide Aruba Remote Access Point Solution Guide for Tele workers and Home Offices, but I just can't get a win here.
Aruba Remote Access Point Solution Guide

Basic RAP Setup with ArubaOS 8 - Flomain Networking

RAP Cluster is 8.10.0.8
The RAP cluster sits under a higher config level as a separate 'RAP' folder, with the 2 hardware nodes in it. (Higher up are 3 Campus AP clusters)

The problem is our internal design - NAT off the border firewall can't work because the network the controllers are on is not routed to the border. Using an NSX load balancer doesn't work for NAT, because although the LB can host the public address and the LB has access to the controller's network, NSX wants to own the VPN endpoint, and we don't seem to be able to work around that.

So I'm going to have to put a public IP on the 2 controllers that I'm going to use for the RAP cluster.
Presently all our controllers only have one IP interface to which the Conductor, the APs, and the admins connect. 

Will the RAP part work if I leave the controllers are they are, but create a new interface on the controllers for the public IP, and leave everything else as it is? Or do I have to zeroise the controllers and start again? The current IP config isn't referred to as 'interface mgmt.'  

controller-ip vlan 628

vlan-name wifiag01-wifimgmt1
vlan wifiag01-wifimgmt1 628

interface vlan 628
    ip address xxx.xxx.xxx.xxx

My thought is to just add a new 'interface vlan xxx' using a public IP,  trunk it in, and specify that in the RAP-IP when I add the controllers to the RAP cluster
Can that work, or am I just smoking crack? 

If it doesn't work, is it a case of zeroise the the controllers, rebuild following the cli wizard, and the Conductor has to talk to the RAP controllers via their public IP, and at some point I set up a management interface?

Are any more ports than UDP 4500 required inbound on the perimeter, as I saw Florian mention 69 and 500, but I didn't spot that in the Aruba guide.

Thanks.

------------------------------
Nathan
------------------------------