NAC Load Balancing with Guest Portal

  • 0
  • 2
  • Question
  • Updated 4 years ago
Hi there,

Does anyone out there have experience of using multiple NAC appliances with the self registration portal in an LSNAT load balancing configuration?

I have just added a second NAC appliance to an existing working setup, and configured load balancing for RADIUS auth. The RADIUS side of things seems to be working fine, however what to do about the web portal? I'm not doing any assessment BTW.

Consider this:
  1. A client connects to my guest VNS, which uses web redirect to an external captive portal running on the NAC appliance 1.
  2. The RADIUS auth for the VNS is sent to the load balancer VIP.
  3. Let's assume the auth goes through the load balancer and happens to go to the second NAC box (the one that's not running the web portal).
  4. NAC processes the auth correctly, and appears to send back the correct policy to the wireless controller (verified looking at NAC end system log).
  5. Then something goes wrong, my end system disappears from the end system log and my client is kicked off. My wireless controller never applies the policy. The client is stuck with the default policy while this is going on, before getting kicked.

Do I have to load balance the guest portal web traffic as well? So the NAC appliance receiving the RADIUS auth, also delivers the guest portal back to the client?

I notice in the NAC appliance interface options there is a feature to "mirror" the guest portal across a number of appliances. But the manual is very short on detail about what this is actually does - do I have to set this up?

Is it even valid to run two appliances in load balancing mode, but only have the guest portal running on one?

If I change my guest VNS auth RADIUS server back to the real IP of the first NAC appliance (running the portal) everything starts working fine again.

Oh - and another question. :)
As I have added a new NAC appliance presumably I should be forwarding DHCP traffic from my guest LAN to both appliances to help with IP resolution? When this goes live, I won't know which NAC will be dealing with the auth for that client.

Any pointers would be great.

Many thanks,
Mark.
Photo of Mark Lamond

Mark Lamond

  • 456 Points 250 badge 2x thumb

Posted 5 years ago

  • 0
  • 2
Photo of Laurent Bourqui

Laurent Bourqui

  • 62 Points
Hi Mark,

Wondering if you have got any answer to this problem. I'm facing a very similar problem and couldn't find any solution to that.

I have two NAC gateway one of them is hosting the captive portal. Everything works fine when captive portal and Radius authentication are sent to the same NAC gateway. As soon as I use a VIP address for the captive portal, I'm not able to redirect the radius request to the same NAC gateway, which leads to a failed authentication.

Any hint or help to solve this problem would be welcome.

Regards
Laurent
Photo of Mark Lamond

Mark Lamond

  • 456 Points 250 badge 2x thumb
Hi Laurent,

No solution yet I'm afraid. I have been busy on other projects but this still needs solving.

We're prepared to use some professional services days to get a solution, I'll chase that up this week.

Will let you know how I get on, it's good to know someone else in the same situaiton.

Regards,
Mark.
Photo of Mark Lamond

Mark Lamond

  • 456 Points 250 badge 2x thumb

Hi there,

I've been back working on this and we didn't have the VIP/LSNAT set up correctly (a simple mistake on our part) - the VIP's have now been set up a separate subnet to the back-end NAC's so the switch can correctly LSNAT the return RADIUS packets.

So that's the LSNAT is now working correctly for RADIUS auth traffic, however it has thrown up another problem.

After the RADIUS Request / RADIUS Accept messages are exchanged between the wireless controller and NAC the back end NAC box that was dealing with the auth request sends out a RADIUS Disconnect message. This is necessary to "kick" the client so when they re-connect to the wireless network they get their their new policy (which NAC sent back in the preceeding RADIUS Accept message).

The wireless controller appears to be ignoring the disconnect message because if i manually disconnect the client from the controller GUI, they re-join and everything works fine. I suspect the wireless controller is ignoring the disconnect message because the source IP of the packet is from the real IP of the back-end NAC, and not from the VIP,

Can't think how to solve this at present and GTAC are involved.

Laurent - we're now in a situation where if we remove the LSNAT/VIP from the equation and set some wireless controllers to send their RADIUS auth requests to one NAC, and some to another everything works fine with the guest portal only set up on the first NAC. GTAC confirmed that this is a supported configuration and NAC boxes in the same group talk to each other to stay in sync. The reason it wasn't working before for us was a routing error on one of the wireless controllers (a silly mistake on our part).

So in can confirm that even if the guest portal is on one NAC, and the RADIUS auths go to another NAC everything works fine. I can't remember what i did to make this work, but will look over the config if it would help you.

Regards,
Mark.
(Edited)
Photo of Mark Lamond

Mark Lamond

  • 456 Points 250 badge 2x thumb

Okay, we've got it all working now with help from GTAC.

To get the wireless controller to accept the RADIUS disconnect messages from the real IP's of the NAC boxes you have to add the real IP's as authentication servers under "Global > Authentication".

You only have to assign the VIP RADIUS server to the VNS as the authentication server, but the real NAC IP's must be configured under Global.

On to the next problem!

Regards,
Mark.

 
(Edited)