MAC to IP resolution between Wireless Controller and NAC


We are having trouble with guests completing the captive portal registration on the NAC. This is apparently a MAC-to-IP resolution issue between the EWC and the NAC. The subnet for the captive portal is 10.200.x.x and the DHCP is handled by the EWC's onboard DHCP for the topology.

I doing something wrong because the NAC is not resolving these addresses therfor they connot complete registration. The information from the switches resolves perfectly but not from this "guest" subnet. I am sure there is a check box somewhere I am missing, any help?

13 replies

Userlevel 7
Is that a bridge@controller topology = the clients get a IP in the same subnet as the NAC portal ?

The unregistered role should look something like this....
allow DHCP, DNS, http and https to the portal, ARP, return dircetion and deny the rest.



Also check that...
https://gtacknowledge.extremenetworks.com/articles/Q_A/Why-the-redirection-to-portal-page-failed-for...

Is MAC auth also enabled ?



Cheers,
Ron
The NAC portal is not in the same subnet - because there are two controllers each with a B@EWC topology - therefor two guest topology subnets.

I made two changes and am currently testing. I checked "Enable RADIUS Accounting" and added the NACs into the field. I also unchecked "Collect Accounting Information of Wireless Controller". The other screenshots showed no changes needed. This last screenshot did have some differences.

I am not seeing an increase in success for MAC-to-IP but the first device I tested for captive portal registration succeeded. I am doing more testing now.
Userlevel 7
You'd set the NAC IP in the controller so DHCP information is provided to the NAC.
GUI > VNS > global > NAC integration
The NAC Integration was already configured. Thanks.
Userlevel 7
If I unterstand that correctly you can't ping the guest client from the NAC - correct ?
If that is that case - have you configured a IP route on the NAC to reach the guest subnet.
Do you use the main interface on the NAC for the guest auth or did you enabled the 2nd NIC for it.
"If I unterstand that correctly you can't ping the guest client from the NAC - correct ?"
Not sure what I said that led you to think this. I can ping clients from the NAC.

"Do you use the main interface on the NAC for the guest auth"

Yes. We use the main interface. Would using a secondary interface improve performance?
Userlevel 1
Where do clients get their IP from? where is your DHCP server?
Userlevel 1
Are you bridging at controller? It would help if you put a ip-helper or bootprelay to a NAC gateway on the router to your guest VLAN. Also, did you configure SNMPv3 between Netsight and the EWC?
Matthew Hum wrote:

Are you bridging at controller? It would help if you put a ip-helper or bootprelay to a NAC gateway on the router to your guest VLAN. Also, did you configure SNMPv3 between Netsight and the EWC?



The local DHCP server in the EWC is providing IP Adresses. Would the ip-helper still be useful? I assume the NAC would be "sniffing" dhcp traffic.
Userlevel 1
Matthew Hum wrote:

Are you bridging at controller? It would help if you put a ip-helper or bootprelay to a NAC gateway on the router to your guest VLAN. Also, did you configure SNMPv3 between Netsight and the EWC?

The EWC should be sending it over, but an additional ip-helper wouldn't hurt.
Please verify SNMPv3.
you can further check the logs on NAC to identify why IP-to-MAC resolution is failing.
Matthew Hum wrote:

Are you bridging at controller? It would help if you put a ip-helper or bootprelay to a NAC gateway on the router to your guest VLAN. Also, did you configure SNMPv3 between Netsight and the EWC?

SNMPv3 is configured and working. I will check the logs
Userlevel 4
Matthew Hum wrote:

Are you bridging at controller? It would help if you put a ip-helper or bootprelay to a NAC gateway on the router to your guest VLAN. Also, did you configure SNMPv3 between Netsight and the EWC?

As you mentioned that NAC portal is not in same subnet, I think the ip-helper or bootp relay configuration would be need in core switch so that the NAC could get the DHCP packets for MAC-to-IP resolution.
Do you have the EWC sending station events to NAC? https://gtacknowledge.extremenetworks.com/articles/Solution/Seeing-Non-NAC-End-Systems-in-NAC-Manage... says how to disable them, https://gtacknowledge.extremenetworks.com/articles/Q_A/Why-does-client-see-system-is-misconfigured-w... has a brief note about "2. Is the end system in an "Active" state due to a RADIUS authentication and not other XML type event (Eg Identifi messaging)"

There's also https://gtacknowledge.extremenetworks.com/articles/How_To/NAC-Troubleshooting-Tips-Debug-methodology...
My Mac-to-IP seems to be much better. I have changed a few check boxes and added the helper-ip addresses. NAC registration is still spotty. GTAC said this was due to MAC-to-IP but having improved MAC-to-IP I am not seeing any better performance. Before a client would log in "Extended State" "Resolving IP Address". Now it logs "IdentiFi State Change" but the client end-user sees the same thing - A registration screen that just spins and then times out. If you let it sit long enough you get the AUP screen and can finalize registration (which is just a check box to submit the AUP).

Reply