Wireless Access

 View Only
last person joined: yesterday 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

RAP cluster creation without having to zeroise the controllers

This thread has been viewed 39 times
  • 1.  RAP cluster creation without having to zeroise the controllers

    Posted Dec 12, 2023 12:11 PM

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


  • 2.  RE: RAP cluster creation without having to zeroise the controllers

    EMPLOYEE
    Posted Dec 12, 2023 12:42 PM

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



  • 3.  RE: RAP cluster creation without having to zeroise the controllers

    Posted Dec 13, 2023 08:47 AM

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



  • 4.  RE: RAP cluster creation without having to zeroise the controllers

    EMPLOYEE
    Posted Dec 13, 2023 09:33 AM

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



  • 5.  RE: RAP cluster creation without having to zeroise the controllers

    Posted Dec 13, 2023 12:06 PM

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



  • 6.  RE: RAP cluster creation without having to zeroise the controllers

    Posted Dec 14, 2023 08:47 AM

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



  • 7.  RE: RAP cluster creation without having to zeroise the controllers

    EMPLOYEE
    Posted Dec 14, 2023 08:53 AM

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



  • 8.  RE: RAP cluster creation without having to zeroise the controllers

    Posted Dec 20, 2023 07:18 AM

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



  • 9.  RE: RAP cluster creation without having to zeroise the controllers

    Posted Dec 20, 2023 10:01 AM

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



  • 10.  RE: RAP cluster creation without having to zeroise the controllers

    EMPLOYEE
    Posted Dec 20, 2023 10:42 AM

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



  • 11.  RE: RAP cluster creation without having to zeroise the controllers

    Posted Dec 21, 2023 06:25 AM

    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



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



  • 12.  RE: RAP cluster creation without having to zeroise the controllers

    Posted Jan 10, 2024 09:03 AM

    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.



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



  • 13.  RE: RAP cluster creation without having to zeroise the controllers

    Posted Mar 01, 2024 05:38 AM

    Forgot to update/close this query any sooner.
    Ultimately the remote AP was coming up then dropping out because of LMS IP config that I hadn't removed, or forgot to remove, or failed to deploy a change for removal. User error. Very confusing, but user error. An LMS entry can't exist in the AP Group.

    Once the RAP was active on the controller, clients weren't getting IP addresses. They were associating, sending the Request, and nothing was hitting our SIEM or DHCP servers.

    This turned out to be down to the fact that I was trying to trial the RAP service (for which we have a broad use case) within the confines of restrictive and complex internal infrastructure. I'll spare the detail, but I'd got myself into a position where I wasn't even allowing the client VLANs to reach the controller, and I'd lost sight of what interface the management traffic was connected over. What I thought was an active interface, wasn't!
    The problems were entirely of my/our own internal making. The process ended up being a pretty good refresher on complex troubleshooting - that being that you really do have to start with the very simplest things first - almost like, in fact, exactly like, 'is it plugged in?'

    Cheers.



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