Controllerless Networks

Hi all,

 

I have 2 x 7240 controllers which facilitate a number of VPN connections back to our central office from VC clusters and IAP devices.

 

After upgrading the 7240 controllers from 6.3.1.19 to 6.4.2.13 there is an issue with the VPN in that the tunnel remains UP but the clients can no longer obtain and IP address via DHCP. I have tried giving the client a static IP but this also has no effect.

 

Downgrading the firmware makes the VPN work without issue.

 

Nothing has changed on the VPN config. The only difference is the firmware revisions. I therefore ask if there is anything that need to be added to the controller or IAP configuration for the new 6.4.x firmware to work and successfully connect via the VPN.

 

Is there anything that would cause this?

 

Thanks,

#6.4

How's the DHCP configured on the IAP? Centralize L2 , Distributed L3

Hi there,

 

I am using L2 Centralised. see attached.

 

ta,

 

Ed

edd1e_j,

 

If you have not already, please open a tac case in parallel so that they can try to replicate your issue with your config and logs..  It might be something that requires your specific configuration to experience.

 

Hi yes TAC case already open;

 

1823232

 

ta,

 

Ed

Did you already downgrade back to 6.3.1.19 or are you still on 6.4.2.13?

Did you turn on dhcp debugging like was suggested to possibly observe the issue?

 

As I have the luxury of a test device I still have the firmware on 6.4.2.13.

 

I have run DHCP debugging but do not see any DHCP traffic for the MAC address of my client.

 

(aruba-local-7240) (config) #logging level debugging network process dhcpd subcat dhcp
(aruba-local-7240) (config) #show log network all | include e8:b1:fc:60:7b:0b

(aruba-local-7240) (config) #show log network all | include e8:b1:fc:60:7b:0b

(aruba-local-7240) (config) #show log network all | include e8:b1:fc:60:7b:0b

(aruba-local-7240) (config) #tar logs tech-support
This operation may take a while, Please do not power cycle the box

 

TAC logs have been sent to Aruba TAC support.

 

thanks,

 

Ed

You might have to configure an external syslog server.  It is possible that if you have enough info in the syslog server that the logs might have rolled.  If you configure an external syslog server to collect the network log traffic, you might be able to see your client.  Have you tried to get a dhcp address and immediately look at the network log?

 

Hi,

 

When the IAP is rebooted it briefly allows me to pickup an IP address then the gets lost as a 169.x.x.x address. It appears that the VPN tunnel is UP and working but traffic is not passing correctly.

 

The 7240 controlllers are lugged into a HP 5400zl. Firmware revision K.15.16.0009.

 

I am wondering if this could be the issue as we've had problems with Aruba connecting to HP in the past with the VRRP config.

 

Any known issues with HP and Aruba (now they are merged entities I hope not!).

 

(aruba-local-7240) #show log network all | include 7b:0b
Jan 28 11:20:06 :202541:  <DBUG> |dhcpdwrap| |dhcp| Received DHCP packet from Datpath, sos msg hdr flags 0x42 opcode 0x5a ingress 0x2102 vlan 93 egress 0x5d src mac e8:b1:fc:60:7b:0b
Jan 28 11:20:06 :202536:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan93: REQUEST e8:b1:fc:60:7b:0b Transaction ID:0x8aaa151a reqIP=172.18.33.209 Options 3d:01e8b1fc607b0b 0c:484944303139323431 51:0000004849443031393234312e76616c656f66676c616d6f7267616e2e676f762e756b 3c:4d53465420352e30 37:010f03062c2e2f1f2179f92b

(aruba-local-7240) #show crypto ipsec sa

IPSEC SA Active Session Information
-----------------------------------
Initiator IP     Responder IP     InitiatorID         ResponderID         Flags    Start Time      Inner IP
------------     ------------     -----------         -----------         -----  ---------------   --------
x.x.4.118     x.x.4.117     x.x.4.118/32     x.x..4.117/32     T      Jan 28 09:42:41     -

IPSEC SA (V2) Active Session Information
-----------------------------------
Initiator IP     Responder IP     SPI(IN/OUT)        Flags Start Time        Inner IP
------------     ------------     ----------------   ----- ---------------   --------
z.z.111.110  x.x.4.118     6a810c00/311cb00   UT2   Jan 28 11:15:35   a.a.a.8
y.y.88.36    x.x.4.118     a966600 /eaa2de00  UT2   Jan 28 11:17:34   a.a.a.7

Flags: T = Tunnel Mode; E = Transport Mode; U = UDP Encap
       L = L2TP Tunnel; N = Nortel Client; C = Client; 2 = IKEv2

Total IPSEC SAs: 3

(aruba-local-7240) #show crypto isakmp sa

ISAKMP SA Active Session Information
------------------------------------
Initiator IP     Responder IP   Flags       Start Time      Private IP
------------     ------------   -----     ---------------   ----------
x.x.4.118     x.x.4.117   i-a-p     Jan 28 09:15:07          -
y.y.88.36    x.x.4.118   r-v2-c-I  Jan 28 10:56:28   a.a.a.7
z.z.111.110  x.x.4.118   r-v2-c-I  Jan 28 11:15:36   a.a.a.8

Flags: i = Initiator; r = Responder
       m = Main Mode; a = Agressive Mode v2 = IKEv2
       p = Pre-shared key; c = Certificate/RSA Signature; e =  ECDSA Signature
       x = XAuth Enabled; y = Mode-Config Enabled; E = EAP Enabled
       3 = 3rd party AP; C = Campus AP; R = RAP;  Ru = Custom Certificate RAP; I = IAP
       V = VIA; S = VIA over TCP

Total ISAKMP SAs: 3

(aruba-local-7240) #

Are you able to ping IAP from the DHCP server after the upgrade and also can you ping the DHCP server from the IAP?
On that VLAN do you have the ip helper address pointing the DHCP


Sent from Outlook Mobile

We run split tunnelling so this would be difficult to PiNg the controller from the IAP unless we added the local IAP LAN to the VPN.

 

We certainly have an IP helper on the VLAN. Like I said, this all workied fine prior to the upgrade.

 

ta,

 

Ed

When the IAP builds a tunnel it uses an inner IP address which is provided by the controller (ip local pool) , that pool needs to be routable in order for your DHCP server at the Data center to lease IP addresses to the clients behind the IAP.

You can see what's the IP address assigned by running the following command:
show vpdn l2tp local pool

or under the iap role
show rights

Hi Victor,

 

The IAPS I have setup are both using the same pool;

 

(aruba-local-7240) #show vpdn l2tp local pool

IP addresses used in pool rap-pool
         a.a.a.7
         a.a.a.10

 Total:-
         2 IPs used - 2045 IPs free - 2047 IPs configured
IP pool allocations / de-allocations - L2TP: 0/0  IKE: 10/16

 

The VLAN 93 is tagged on the interface that connects to our internal Corporate switch which then in tun has the default gateway for VLAN93 and the ip helper statements.

 

ta,

 

Ed

Can the DHCP server ping the IP addresses define under the RAP POOL ?

Hi Victor,

 

You cannot PiNG to the IAP pool from the DHCP server. i thought the DHCP pool was only local to the controller for assigning the IAPs internal addresses.

 

Unless something has changed in the firmware release about routing traffic then I fail to see how this configuration, that works on 6.3.1.19 doesn't on 6.4.2.13 after upgrade.

 

we never routed this traffic previously. Sh IP route on Controller gives;

 

C    a.a.a.7/32 is an ipsec map y.y.88.36-a.a.a.7
C    a.a.a.10/32 is an ipsec map z.z.110-a.a.a.10

 

ta,

 

Ed

The pool needs to be routable in your network in order for your DHCP server to provide IP addresses.

OK but my working configuration has no route. This is running firmware 6.3.1.19

 

The IAP is creating a IPSEC VPN tunnel to the 7240 controller. This then has an interface in VLAN93 which is the DG and also has the ip helper command to our internal DHCP server. The internal pool is purely for the IAP but the network being adverrtised by the VPN is the network for VLAN93.

 

ta,

 

Ed

Is the IAP cluster managed by Airwave or Central? Starting with controller release 6.4.x.x, there is an additional security feature introduced to only allow IAP VPN branches with trusted configurator to register on controller. Based on the symptoms described in the earlier comments, this could possibly be causing an issue.

 

VPN tunnel does come up, but IAP does not register with the controller, causing client Centralized L2 VLANs to not be registered on controller and leading to clients not getting IP.

 

This can be manually overriden by disabling IAP trusted branch DB validation if the cluster is not managed by Airwave/Central.

 

(7240) (config) #iap trusted-branch-db allow-all

All IAP+VPN branches are trusted

(7240) #

Hello Naveen,

 

Apologies for the lateness in my reply. I think this is on the right track as it is exactly the behaviour I am seeing however I have tried adding the command below as well as;

 

iap trusted-branch-db add mac-address xx:xx:xx:xx:xx:xx

 

but the VPN tunnel is still failing. Any other ideas? The config on the IAP remains the same it is only the upgrade to 6.4.x that makes this fail. If I roll back to 6.3.1.19 then the tunnel instantly comes back up again so it's something with the new features within 6.4.x that is stopping this from working.

 

Thanks,

 

Ed

Hello Naveen,

 

I have rebuilt the master/local trust and enabled firmware version 6.4.2.13 on both;

 

(aruba-master-7240) #show switches

All Switches
------------
IP Address    Name               Location        Type    Model      Version         Status  Configuration State  Config Sync Time (sec)  Config ID
----------    ----               --------        ----    -----      -------         ------  -------------------  ----------------------  ---------
x.x.4.117  aruba-master-7240  Broadband Room  master  Aruba7240  6.4.2.13_52246  up      UPDATE SUCCESSFUL    0                       553
x.x.4.118  aruba-local-7240   Broadband Room  local   Aruba7240  6.4.2.13_52246  up      UPDATE SUCCESSFUL    2                       553

 

I then applied the command;

 

(7240) (config) #iap trusted-branch-db allow-all

All IAP+VPN branches are trusted

(7240) #

 

This got the VPN back working as it should do now that the master-local configuration is correct so thanks for all of your help. This command certainly fixed the issue but needed to have the master/local configuration sorted out as well.

 

Many thanks,

 

Ed