I have quite a few iAP 205 and iAP 305 running 6.5.x.x.
Internal iAP are terminating Aruba-GRE on a 6.4.x.x MC and we're preparing to use some 205H and 305H iAP as RAP for work-from-home users.
My SE tells me "6.x RAP will not be able to connect to 8.x MC and 8.x RAP can't connect to 6.x MC"
Is that accurate?Can I get the 6.5.x.x iAP to connect to an MC running 8.5.x.x? or Can I get the 8.5.x.x iAP to connect to an MC running 6.5.x.x? I don't want to maintain two sets of MC while I migrate from 205 to 305 over the next three years.
Which should I upgrade first, the 305 iAP or the MC (understanding that the 205s will have to stay at 6.5)?
TAC provided the answer (super secret command at the end):
Instant APs running Instant 8.3.x.x or earlier versions can terminate IAP-VPN connections with controllers running ArubaOS 126.96.36.199 or later versions only if the backward compatibility feature is enabled on the controller.
Instant APs running Instant 188.8.131.52 or later versions cannot terminate IAP-VPN connections with controllers running ArubaOS 8.3.x.x or earlier versions.
So to answer your question, Yes IAP 205 running 6.5.x.x can terminate VPN connections to controller running 8.5.x.x using CLI flag on the controller as below:
Have you tested this and is it working? We did and upgrade with migration tool from 6.5.4 on a 7010 standalone Ctrl to 8.4.04. The IAP does not get traffic through the tunnel even though you can see teh tunnels are up. In the Aruba Instant user guide for 8.5 page 324, it states under point to remember:
Instant APs running 8.3.x.x or earlier versions cannot terminate IAP-VPN connections with ArubaOS controllers running 184.108.40.206 or later versions.
We have been on an open TAC case and the backwards compatability commands does not rectify the issue.
The following error comes up in the logs:
|IAP manager Process| register_iap_bid:579 Terminating IAP-VPN on this platform (Mobility Master / Legacy Master) is not supported
I've got 220.127.116.11 and 18.104.22.168 iAP - both working with a 7210 running 22.214.171.124. After fixing a typo in my routing tables (elsewhere in the network) everything sems to be working.
So, the tunnels were up and the only thing not working was the client was not getting an DHCP IP from external DHCP server. We could see the DHCP request from the AP but the controller was not sending it to the DHCP server.
We have a port channel with multiple VLANs where the Guest and BYOD VLAN is tagged. When you do a show int vlan xx<guest>, you can see the interface state is up/down. The interface state is why the controller can't send the DHCP request out the VLAN interface.
To fix this go under the VLAN interface and do "operstate up". You might have a duplicate BID for exisitng IAPs that you will have to delete. The logs will show - <ERRS> |IAP manager Process| !!! Not a trusted branch - '<233nsg5364nds>';remove this entry from white-list
Then reboot and it worked fine.
I got the same problem, even including "the secret command" iapvpn_backward_compatible on the 7030 the tunnel doesn´t go up.
At the IAPs end the tunnel is in status UP, but in the 7030 the tunnel goes down after goes up (in reverse order):
Jun 18 15:07:42 IAP manager Process: <342001> <3890> <ERRS> |IAP manager Process| handle_iap_dpp_hb_gre_add: 1016, can't find branch for heartbeat tunnelJun 18 15:07:42 IAP manager Process: <342001> <3890> <ERRS> |IAP manager Process| register_iap_bid:579 Terminating IAP-VPN on this platform (Mobility Master / Legacy Master) is not supportedJun 18 15:07:42 fpapps: <399838> <3481> <WARN> |fpapps| Received MAP_ADD from IKE for 10.74.217.245-172.16.20.12 (gw 172.16.20.12) mapid 0 vlanid 0 ip 172.16.20.12 mask 255.255.255.255 src_ip 0.0.0.0 peer_ip 0.0.0.0 uplink_ip 0.0.0.0 flags 0x0Jun 18 15:07:42 fpapps: <399838> <3481> <WARN> |fpapps| Received MAP_DEL from IKE for 10.74.217.245-172.16.20.12 (gw 172.16.20.12) mapid 0 vlanid 0 load-balance 0Jun 18 15:07:42 fpapps: <399838> <3481> <WARN> |fpapps| Received TUN_DOWN from IKE for 10.74.217.245-172.16.20.12Jun 18 15:07:42 fpapps: <399838> <3481> <WARN> |fpapps| Received TUN_UP from IKE for 10.74.217.245-172.16.20.12 mapid 0, vlanid 0, ip 172.16.20.12, src_ip 0.0.0.0, peer_ip 0.0.0.0, gw 172.16.20.12, flags 0x0 uplink_prio 0
How did you solve? Any ideas?
Solved configuring it as "standalone" in the initial wizard setup, the first time was deployed as "master" and with the same config didn´t work.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.