Controllerless Networks

Hi All,

 

I have a situation where I would like to deploy Instant access points at a small branch site. This branch site does not have direct to net access. Currently, at the larger branch sites, controllers are used and guest access (separate SSID/VLAN) is tunneled via GRE back to the HQ master controller DMZ.

 

Is this possible with Instant? I.e.. I need routing table functionality, where local management of the IAP and Corproate SSID with RFC1918 networks are routed locally at the branch site, but guest Internet access is tunneled via GRE back to a HQ master controller DMZ?

 

Regards,

 

Chris

 

If you want to the IAPs to remain as IAPs and not convert them to Campus APs, then refer to Chapter 30 - VPN Configuration in the IAP 6.2.0.0-3.2 User Guide.  I don't have any specific experience with this, but this may suit your needs to tunnel traffic to a controller at HQ.

 

 

 

 

 

 

I'd like to do this as well, but mainly to provide a decent captive portal page and guest provisioning capability, which the Instants lack.

 

In order to do that, I assume that I'd need to create the other end of the tunnel on the controller, with tunnel destination being <instant vc> and make it untrusted.

 

So if on the instant, the tunnel dhcp was L2 Centralised, Guest users on the instant will then fall into the logon role and be given the captive portal of the controller.  Is that correct?

 

Does this tunnel comsume a licence or count towards anything on the controller platform limits?

 

 

ok, tried this with the traffic being tunnelled from the instant to the controller.

 

On the instant, make the ssid, employer with open and no captive portal.  Make the controller end untrusted and captive portal from the controller will be presented.

 

Only caveat is that you'll need to upload a server cert on the controller for captive portal with a different CN, otherwise the instant will intercept and hijack the dns response and then it won't open up.

 

:-)

ok, so I've deployed this now and there has been some problems with the tunnels.  For the past few weeks it was fine, but now the cabling guys have finished and plugged the other APs in, it seemed to stop working.

 

Not strictly a topology change, but with the addition of more APs, the tunnels seems to break.

 

The only thing I could do is to reboot the APs and hope for the best tomorrow.

for reference if anyone is looking at this.

 

Make sure the Instants are on a completely different subnet to the controllers.

 

 

I'm trying this now in 6.3.1.1-4.0.0.0_40930 and am confused as to how I get the guest-SSID into the tunnel.

 

I've got the SSID set to employee and VLAN 100.

In controller based tunnels, I specify that the VLAN belongs to the tunnel.

In the iAP VPN setup that doesn't seem to be an option.

 

I'm sure it's obvious but I need a hint.

I've not tried it on that version, but the dhcp scope for your vlan 100 needs to be 'Centralised L2'.  In there you specify the vlan and coupled with the vlan setting in the ssid, this is what determines what vlan goes into the tunnel.  In the routing table for the VPN, this determines which traffic is routed into the tunnel, but for a guest ssid, it has to be all traffic.

 

If your intention is to use the controllers captive portal, you need to upload a custom cert to the controller.  Even though on the instants, you set it to employee ssid, the instant will intercept the traffic if it sees a request for 'securelogin.arubanetworks.com', and you'll get the portal for the instant.

 

Post back with how it goes.

 

:smileyhappy:

 

 

I have the SSID set thus:

and the tunnel (VPN) set so:

I'm missing where else to set the VLAN for the tunnel.

ok, set the tunnel routing like this to send all traffic into the tunnel.

 

 

In the DHCP scope, it should be centralised L2.

 

 

Is that how you have it?

I've made the DHCP change -- not sure why that would matter.

 

What gateway should I be placing in the tunnel routing box - the gateway that a guest will be assigned by dhcp, or the far end of the tunnel or something else?

 

I still am not getting how the guest vlan (100) is getting placed into the tunnel.

 

 

What I've found is the following.

Configure the controller end GRE and map the VLAN to tunnel. Make sure you choose Tunnel Mode 48. I like to use the loopback as the tunnel source but that is up to you.

On the IAP VC end create the GRE tunnel, disable per AP tunnel, and make sure the tunnel mode is 48 also. In the routing profile define 0.0.0.0 0.0.0.0 via the same ip as the GRE tunnel endpoint (e.g the controller loopback).

Now to map the VLAN into the tunnel, go into the DHCP section and define a L2 Centralised DHCP with the VLAN that is to be tunnelled.

Finally create a WLAN and reference the VLAN again as "static"

For corporate traffic you can create another WLAN and just reference a different VLAN that is not defined as L2 centralised in the DHCP section.

Don't ask me why it needs to be this complicated.

Regards

Chris

Agreed, I still find it somewhat confusing, though the documentation is somewhat better than when the feature was first added.

 

I'm not sure about the setting the tunnel mode, as I've seen in another post that you shouldn't change this and it's not mentioned to change it in the user guide.

 

The routing profile however applies to all traffic, so even if another corp SSID is set to a non-centralised dhcp, the traffic would get sent into the tunnel with that route above.  I think that is how it works...though I'm still confused.  Some good examples of fluffy cloud diagrams would be nice in the guide as well.

 

I've only deployed this live for a guest only solution.  Had some initial problems, but once it was working, I've not touched it since.

I was able to send the guest traffic through the tunnel and bridge the corporate onto a local VLAN with the config described above.

 

If you were to define the corporate VLAN anywhere in the DHCP section of the IAP config, then it is my understanding that the corporate traffic would also be sent through the tunnel (undesirable in my case).

 

My lab topology which I used as a proof of concept is attached.

 

Chris

 

Turns out adding the DHCP thing did it, just took a while before the dhcp requests got up the tunnel and answered -- can't say why my leaving for lunch was necessary, but I've got guest-clients now.

 

I'm using GRE type 0 on the controller and type "Aruba GRE" on the controller.

 

After controller-to-controller tunnels, it is fairly obscure.

 

Not my ticket originally so I can't mark it solved.

 

Thanks for the help!

I spoke too soon.  I'm getting client connection attempts, some get DHCP, but we're having trouble passing traffic (those devices with a DHCP address -- those without can't pass anything)

 

Syslog shows gobs of these:

Dec  4 16:18:19 10.10.254.228 <10.10.254.228 0.0.0.0> cli[1168]: [primary tunnel] Error!!!: Received RC_OPCODE_ERROR lms 10.21.0.65 tunnel 0.0.0.0 RC_ERROR_IKE_XAUTH_AUTHORIZATION_FAILED

10.10.254.228 is the IP address of the iAP

10.10.254.105 is the IP address of the VC

10.21.0.65 is the IP address of the controller to which the tunnel is built.

 

The tunnel is type "Aruba GRE" in the iAP and type 0 in the controller, is that correct?

 

OK, I've got a lot closer with help from TAC (Thanks Payal!!)

 

I'm not doing VPN per se, just need to tunnel some guests on the WAN so I switched to tunnel mode 0 at both ends.

This requires switching from Aruba GRE to Manual GRE.

 

remote DHCP over the tunnel requires the VLAN getting tunneled to exist in the local switch-fabric so that the DHCP request can get passed to the VC in order to get tunneled (poor planning Aruba) so I have to use per-ap-tunnels

 

Tunneled traffic is considered "wired" at the far end, so I'm going to have to put a captive portal on the iAP rather than have the controller at the head-end handle that, so I still have an Authentication problem to solve -- I only want to have one database, and we're currently using guest-provisioning on the master controller, which we doubt will accept AAA requests from the iAP.

 

 

Thanks for your comments and input, Matthew. Another thing to note is the Aruba GRE feature on IAP 4.0 is supported on controllers running AOS 6.4 and above (which is not yet released).