Wireless Access

last person joined: an hour ago 

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

AP provision through vpn tunnel

Jump to Best Answer
  • 1.  AP provision through vpn tunnel

    Posted Apr 23, 2012 04:08 PM

    I have a couple of AP-93's, that I am trying to connect to a 3400 on the other side of an vpn tunnel. The AP's will show up as status "upgrading" after a long while, and then dissappear again. This continues over and over, I tried setting the MTU to 1300 on the ap system-profile, but this doesn't seem to help.

     

    The AP's hadn't been provisioned before, so they ended up with the default profile. My best bet right now is to do a purge and reset the AP's and try again.

     

    Any suggestions?


    #3400


  • 2.  RE: AP provision through vpn tunnel

    Posted Apr 23, 2012 06:07 PM

    How are you setting up the AP-93? Are you hard coding the controller IP / master IP on the AP?

     

    (assuming this is a master/local scenario)

     

    My guess would be that they cannot communicate with the controller IP address that they are being assigned to. You could even try creating a new ap group, setup the LMS as the master IP address, and provision them in there. If that works, you know it's a problem with them getting to the local.



  • 3.  RE: AP provision through vpn tunnel

    Posted Apr 23, 2012 06:25 PM

    If the AP-93 is new, it is very possible that it does not have an ArubaOS image. It will use its firmware to download the ArubaOS image via tftp by resolving aruba-master.yourdomain.com (where yourdomain.com is the domain it received via dhcp).

    To override the server name resolution, you could hard-code the server-ip and master environment variables by dropping into the apboot prompt and entering the following:

    setenv serverip xx.xx.xx.xx

    setenv master xx.xx.xx.xx

    save

    reset

     

    Once the AP-93 downloads its code via tftp, it will boot up and attempts to contact the master controller. Once it does, it will download the version running on the master via ftp. I suggest version 6.1.3.1 on the controller for best results. 

     



  • 4.  RE: AP provision through vpn tunnel

    Posted Apr 23, 2012 06:32 PM

    Hi,

    I checked now, and can see traffic going to and from the controller and AP's. I am setting the controller through dhcp options 43 and 60. Will try to add aruba-master record in dns.



  • 5.  RE: AP provision through vpn tunnel

    Posted Apr 24, 2012 04:30 AM

    now the AP changes state to denied. in the whitelist, they have a state of "approved-ready-for-cert"

    the log shows the following messages:

     

    Unsecure AP "d8:c7:c8:c8:98:8d" (MAC d8:c7:c8:c8:98:8d, IP x.x.x.x) has been denied access because Control Plane Security is enabled and the AP is not approved.

     

    <303086> <ERRS> |AP d8:c7:c8:c8:99:3e@x.x.x.x nanny| Process Manager (nanny) shutting down - AP will reboot!

    <303022> <WARN> |AP d8:c7:c8:c8:98:8d@x.x.x.x nanny|  Reboot Reason: AP rebooted Tue Apr 24 07:10:58 GMT 2012; SAPD: Reboot after image upgrade failed: -1

     

    this problem only occurs for AP's going through vpn tunnels



  • 6.  RE: AP provision through vpn tunnel

    Posted Apr 24, 2012 07:35 AM

    danish82,

     

    Unfortunately, the MTU setting in the  ap system profile only takes effect once an ap has upgraded and gotten its instructions.  If the AP has not made it to the whitelist yet, it cannot receive the MTU 1300 command.  You can try to sidestep this by turning off control plane security temporarily if you do not need it, or upgrade the APs before sending them out to the site with VPN.

     



  • 7.  RE: AP provision through vpn tunnel

    Posted Apr 24, 2012 08:14 AM

    ok :(

    There's no way to set this manually on the AP either?



  • 8.  RE: AP provision through vpn tunnel

    Posted Apr 24, 2012 03:16 PM

    no difference with control plane security disabled.

    it seems like the ap downloads the boot image ok, but every time it logs the following:

    Reboot Reason: AP rebooted Tue Apr 24 12:59:20 GMT 2012; SAPD: Reboot after image upgrade failed: -1

     

    then it will try to download the boot image again, and the circle continues. is the only solution, to actually ship the AP back, provision it and send it out again?

     



  • 9.  RE: AP provision through vpn tunnel

    Posted Apr 24, 2012 05:48 PM

    please open a TAC case, so they can determine exactly what is happening.

     



  • 10.  RE: AP provision through vpn tunnel
    Best Answer

    Posted Apr 27, 2012 02:56 PM

    case solved. The problem was an RTT of around 300ms. The download of AP image was too slow, which caused a process to timeout (10 mins) and the cycle repeated it self over and over.

     

    TAC provided me with a patched image which works just fine now :)

     

    This was only a problem because I hadn't provisioned the AP's before shipping them out.



  • 11.  RE: AP provision through vpn tunnel

    Posted May 03, 2012 07:58 AM

    I'm having a similar issue. I've got AP93s on the back on a route based VPN between 2 fortinet firewalls. The APs discover the master using DHCP options from the Fortinet and connect to the controller. They upgrade their image ok and are provisioned in the "default" ap group.

    However, when I try and provision the AP into a different ap group, they just seem to hang. They still show as up on the controller but I can't re-provision them (I'm assuming this is because the controller knows it's tried to push down a new config). Ultimately I have to power-cycle the the remote campus APs and then try the re-provisioning process all over again, unfortunately with the same result.

     

    I have changed the MTU value in the default ap group to 1400 but this was after the APs initially connected to the controller.



  • 12.  RE: AP provision through vpn tunnel

    Posted May 04, 2012 06:43 AM

    Does that different AP-Group have an LMS-IP in the AP system profile?

     

    Please type "show log system 50" to determine what is going on.

     

     



  • 13.  RE: AP provision through vpn tunnel

    Posted May 15, 2012 06:50 AM

    Hi Colin,

     

    Yes the ap-group does have an lms-ip address, outputs from a system log and ap-debug are as follows

     

    system-log

    May 15 10:26:09 :303022: <WARN> |AP d8:c7:c8:c8:92:4d@192.168.4.112 nanny| Reboot Reason: AP rebooted Tue May 15 10:15:20 gmt 2012; SAPD: Reboot after image upgrade failed: -1
    May 15 10:38:33 :303022: <WARN> |AP d8:c7:c8:c8:92:4d@192.168.4.112 nanny| Reboot Reason: Reboot caused by kernel panic: assert

     

    ap-debug

    May 15 10:38:52 :305006: <INFO> |stm| AP d8:c7:c8:c8:92:4d rebooted
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_ap_init: AP d8:c7:c8:c8:92:4d: NOT setting auth timeout, auth = 1, by_user = ap_auth_not_required
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_ap_init: AP d8:c7:c8:c8:92:4d: is NOT a mesh node
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_ap_adjust_radios: AP d8:c7:c8:c8:92:4d
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_check_arm_multiband: AP d8:c7:c8:c8:92:4d: ARM multiband disabled
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_set_rf_band: AP d8:c7:c8:c8:92:4d: radio 0 using band 0 source: Configuration
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_ap_adjust_radios: AP d8:c7:c8:c8:92:4d
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_check_arm_multiband: AP d8:c7:c8:c8:92:4d: ARM multiband disabled
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_set_rf_band: AP d8:c7:c8:c8:92:4d: radio 0 using band 0 source: Configuration
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_check_arm_multiband: AP d8:c7:c8:c8:92:4d: ARM multiband disabled
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_set_rf_band: AP d8:c7:c8:c8:92:4d: radio 0 using band 0 source: Configuration
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_ap_adjust_radios: AP d8:c7:c8:c8:92:4d
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_check_arm_multiband: AP d8:c7:c8:c8:92:4d: ARM multiband disabled
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_set_rf_band: AP d8:c7:c8:c8:92:4d: radio 0 using band 0 source: Configuration
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_override_ap_radio_prof: AP d8:c7:c8:c8:92:4d radio 0: enabled 1 mode 1 chan 6 pwr 30
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_ap_get_vap_config: AP d8:c7:c8:c8:92:4d radio 0
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_ap_assign_vaps: AP d8:c7:c8:c8:92:4d radio 0 enabled 1 mode 1 (16 VAPs) VAPs to assign 1
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_proc_hello_req: AP d8:c7:c8:c8:92:4d: Sending response to (192.168.4.112) with result 0
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_ap_generic_req_proc: AP d8:c7:c8:c8:92:4d: req FLASHING setting last_activity to 1337078332
    May 15 10:38:52 :305026: <DBUG> |stm| sapm_proc_flash_reboot_req: AP d8:c7:c8:c8:92:4d: Sending response with result 0
    May 15 10:38:52 :305010: <INFO> |stm| AP d8:c7:c8:c8:92:4d upgrading flash image.
    May 15 10:39:05 :305026: <DBUG> |stm| sapm_ap_ageout: AP ip 192.168.4.112: state 8: long_ageout 0
    May 15 10:39:49 :305026: <DBUG> |stm| sapm_ap_ageout: AP ip 192.168.4.112: state 8: long_ageout 0
    May 15 10:41:03 :305026: <DBUG> |stm| sapm_ap_ageout: AP ip 192.168.4.112: state 8: long_ageout 0
    May 15 10:42:16 :305026: <DBUG> |stm| sapm_ap_ageout: AP ip 192.168.4.112: state 8: long_ageout 0
    May 15 10:43:29 :305026: <DBUG> |stm| sapm_ap_ageout: AP ip 192.168.4.112: state 8: long_ageout 0
    May 15 10:44:43 :305026: <DBUG> |stm| sapm_ap_ageout: AP ip 192.168.4.112: state 8: long_ageout 0

     

    We are having various levels of success by interupting the ap boot sequence and adding the serverip manually. The ap database on the controller looks like this

     

    AP Database
    -----------
    Name Group AP Type IP Address Status Flags Switch IP
    ---- ----- ------- ---------- ------ ----- ---------
    00:1a:1e:cc:a7:21 Glangwili_ap_group 61 192.168.1.117 Up 11d:23h:49m:45s 192.168.1.2
    00:1a:1e:cc:a7:24 Glangwili_ap_group 61 192.168.1.126 Up 11d:23h:49m:50s 192.168.1.2
    00:1a:1e:cc:a7:28 Glangwili_ap_group 61 192.168.1.119 Up 11d:23h:49m:49s 192.168.1.2
    00:1a:1e:cc:a7:2e Glangwili_ap_group 61 192.168.1.116 Up 11d:23h:49m:53s 192.168.1.2
    00:1a:1e:cc:a7:36 Glangwili_ap_group 61 192.168.1.118 Up 11d:23h:49m:49s 192.168.1.2
    00:1a:1e:cc:a7:39 Glangwili_ap_group 61 192.168.1.121 Up 11d:23h:49m:46s 192.168.1.2
    00:1a:1e:cc:a7:3c Glangwili_ap_group 61 192.168.1.123 Up 11d:23h:49m:52s 192.168.1.2
    00:1a:1e:cc:a7:3d Glangwili_ap_group 61 192.168.1.114 Up 11d:13h:43m:49s 192.168.1.2
    00:1a:1e:cc:a7:3f Glangwili_ap_group 61 192.168.1.115 Up 11d:23h:49m:44s 192.168.1.2
    00:1a:1e:cc:a7:40 Glangwili_ap_group 61 192.168.1.124 Up 11d:23h:49m:36s 192.168.1.2
    00:1a:1e:cc:a7:96 Glangwili_ap_group 61 192.168.1.120 Up 11d:23h:49m:7s 192.168.1.2
    00:1a:1e:cc:a7:c0 Glangwili_ap_group 61 192.168.1.122 Up 11d:23h:49m:51s 192.168.1.2
    d8:c7:c8:c8:8f:ca default 93 192.168.4.110 Down 192.168.1.2
    d8:c7:c8:c8:91:88 default 93 192.168.2.111 Up 2h:57m:5s D 192.168.1.2
    d8:c7:c8:c8:92:1d default 93 192.168.2.110 Up 2h:57m:6s D 192.168.1.2
    d8:c7:c8:c8:92:4d default 93 192.168.4.112 Upgrading ID 192.168.1.2
    d8:c7:c8:c8:92:e2 default 93 192.168.4.111 Down 192.168.1.2
    d8:c7:c8:c8:92:eb Glangwili_ap_group 93 192.168.0.31 Up 1h:37m:34s 192.168.1.2
    d8:c7:c8:c8:92:f0 default 93 192.168.3.112 Down 192.168.1.2
    d8:c7:c8:c8:93:04 default 93 192.168.2.114 Up 2h:57m:5s D 192.168.1.2
    d8:c7:c8:c8:93:9a Bronglais_ap_group 93 192.168.1.110 Down 192.168.1.2
    d8:c7:c8:c8:93:a5 Glangwili_ap_group 93 192.168.0.27 Up 1h:1m:36s 192.168.1.2
    d8:c7:c8:c8:96:f5 default 93 192.168.3.110 Up 18h:35m:20s D 192.168.1.2