Load Balancing 802.1x RADIUS traffic to NAC.

[Mark_Lamond]

Hi there,

I'm having some issues using LSNAT load balancing with 802.1x RADIUS requests on the S Series or N Series to some NAC appliances at the back end.

With my client switch configured to send RADIUS requests to the VIP address on the S Series, 802.1x auth fails, but MAC auth is fine. The LSNAT load balancing is configured with four NAC appliances as real servers, though only one is "in service" to aid troubleshooting at the moment.

The VIP address of the load balancers are configured as load balancers in NAC manager.

With my client switch configured to send RADIUS requests direct to real IP address of the single NAC appliance the load balancer was configured to use, 802.1x and MAC auth are successful.

I've tried this using B series and D series as client switches, and tried the same LSNAT configuration on the S Series and N Series with identical results. When using the VIP address, 802.1x fails but MAC auth is fine.

NAC Manager shows the following error message when 802.1x auth fails:
“Authentication request became stale, challenge sent, no response received from client (switch 192.168.132.115/end-system).”

Wireshark proves no packets are being dropped between NAC and switch. The final challenge (before the failure) that is sent out by NAC reaches the uplink port on the switch.

It appears that the EAP-TLS communication between client PC and NAC is breaking down some how.

Has anyone has seen similar issues?

Thanks,
Mark.

[Jeremy_Gibbs]

Yeah, we are running the latest 8.32 firmware the S4 can take for our 180 cards. Using LSNAT makes the response time a LOT slower as well. I also notice when I authenticate, different parts of the communication will hit different NAC appliances. When that happens, it doesn't work. When all the auth stuff hits the one NAC, it works. Tried sticky sip but that didn't help.

[Joseph_Burnswor]

Yes, the config looks good. Im sorry I could not help on this. The GTAC gods have spoken, and I would follow the firmware path as they said.

Hope it gets resolved for you

[Jeremy_Gibbs]

We are running 8.32.2.0008 on the S4. Havn't looked into fragment size but I will take a look at that. We use NAC as a RADIUS server.

[Mark_Lamond]

We ended up getting professional services involved to take a look at the issue.
Looking back through my notes, the reason for the problem is because is because our client certificate could not fit in one packet so was being fragmented across multiple packets. This is something LSNAT couldn't deal with at the time, so fragments were being dropped causing the TLS conversation to fail.

There was a bug fix in the S series firmware v8.31.01.005 which sounds like a similar issue:
"Fragmented packets are not allowed to traverse across an LSNAT6/4 or LSNAT4/6 vserver, the packets will be dropped"

In our case we were using straight LSNAT IPv4 to IPv4 with no IPv4/6 or IPv6/4 conversion.
I've never tried it again since the fix, might give it a go if I have time.

What hardware are you running and what firmware version are you on?

We did try a few things to reduce the size of the EAP packets, but from what i remember our client certificate was just too big.

Here are a few tips on that which were relevant when we had the issue with our NAC version - I would advise treading carefully, lots of potential to break stuff . Use wireshark/tcpdump on both client side and NAC side to monitor how the packets appear before and after LSNAT.



I. To reduce fragmentation on NAC:

Add the following appliance or appliance group properties and then enforce the appliance:

RADIUS_EAP_TLS_FRAGMENT_SIZE=1200
RADIUS_INNER_EAP_TLS_FRAGMENT_SIZE=1024

This will reconfigure the eap.conf and inner eap configuration files

II. To reduce packet size from client:

Microsoft’s KB on the subject (http://support.microsoft.com/kb/883389😞

The Extensible Authentication Protocol (EAP) packets of the RADIUS server are large when some firewall programs drop the UDP fragments to help protect the network. Framed MTU is used with EAP authentication to notify the RADIUS server about the Maximum Transmission Unit (MTU) negotiation with the client. The RADIUS server communicates with the client, so that the RADIUS server does not send EAP messages that cannot be delivered over the network. The default attribute value of the framed MTU for the IAS server is 1,500. You can set the attribute to a minimum of 64 and a maximum of 1,500. To avoid the fragment issues, you can set the attribute value to 1,344.

Thanks,
Mark

[Doug]

Have you seen this? Not sure if it helps or not.... https://gtacknowledge.extremenetworks.com/articles/Solution/RADIUS-Authentication-failing-using-LSNA...