Dedicated Guest NAC (IA-V) for GIM/guest: Add switch to more than two NAC Engines

[htw]

Hi,
we want to deploy a 802.1x wifi and a guest network on APs which are controlled by an ECA HA pair.
Two NACs will handle 802.1x authentication for 802.1x wifi. In "NAC Manager" we have an appliance group with those two NACs and in "switches" tab both ECAs are configured as Switch with both NACs as primary and secondary engine and ECAs are using a RADIUS pasthrough rule. As a result authentication requests from those ECAs are processed by both NACs. This works so far.

Now we want to deploy a GIM guest network with external captive portal (from ECAs point of view) on a third dedicated NAC (Guest-NAC). Since Guest Users will have to communicate with this NAC (to see the login portal) this NAC needs a second user registration interface with an IP address reachable from user networks.

ExtremeCloud Appliance Deployment Guide, Section "Deploying XMC as External Captive Portal" describes the use of a NAC as portal provider. There you have to add the switch (our ECAs) to the Guest-NAC. But if I do this, the ECAs will be removed from the 802.1x appliance group?

Can't I add a switch (ECA) to more than two NAC-Engines?

[Rodney_Lacroix · Accepted solution]

If your goal is to simply SEE the end systems authenticating in XMC but use the XCAs captive portal then you'd simply have to add the XCA as a switch to the engine, create a location-based rule for end systems coming from that location (the XCA and/or SSID of the network(s)) that uses a profile that does NOT replace the policy attributes, and point to the engine as the RADIUS server for the XCA network in the XCA AAA configuration. Create a "dummy" policy in XCA that will be "assigned" to those end systems (at least from an XCA point of view). Again, the profile used in XCA should be set to use that policy and the checkbox for "Replace RADIUS attributes" on the profile should be disabled.

Set the default policy for the XCA network to Unregistered.

The end systems will authenticate to the engine, show up in the End Systems table of XMC, and should continue through the authorization/reauthentication processes on XCA. However, just keep in mind that in doing this, XMC/NAC will not provide policy or any other authentication processes to the XCA end systems.

[htw]

If we use existing NACs, can ECAs embedded NAC also provide guest portal? Perhaps with some virtual IP so Guest users in an B@AC guest network can see this page without giving additional interface to NACs? Can ECAs guest portal be feeded with guest user accounts from GIM?

[Rodney_Lacroix]

As mentioned previously, you can't have a switch (XCA or otherwise) managed by different Access Control engines in different engine groups. Each engine group will (or can) have it's own AAA configuration and NAC configuration (and profiles/policies/etc.). Because of this, there would be no way to enforce to the switch and have it assume the correct configuration. Hence, the limitation.

That said, you can configure the individual interfaces on each engine (check the Details tab when clicking on an engine). You can specify an IP, routes and type of traffic that the interface is responsible for. For example, setting an interface to "Registration and Remediation" means that it will listen only for registration and/or assessment traffic on that particular interface.

You can certainly still do what you want to do by incorporating a separate engine for this, but the ability is already in the product to configure interfaces however you'd like. That being said, you may still want to incorporate location-based rules (or portals) for these particular users coming in from the XCA that you'd like to deliver a portal to.

The thing about GIM is that any users or devices you create are also linked to a single GIM repository (and, therefore, LPR). As such, whatever AAA configuration you use, and engine group, must also have that GIM server and repository specified. You can't use the same GIM repository across different engine groups, for the same reasons listed above for the switches.

[htw]

Hi Rodney,
thanks for your response. How can this be done? In my environment both Wireless-802.1x-NACs are in Engine group A. (f.e. 192.168.4.216 and 192.168.64.216)
Guest NAC is in engine group B. (f.e. 192.168.64.204)
Both ECAs are added as switches to both NACs in Engine Group A with both NACs configured as primary and secondary engine.
As soon as I add an ECA as switch in Engine Group B by configuring it as primary or secondary engine there, this ECA disappears from the remaining former NAC.
In the following screenshot I want to add ECA 192.168.64.201 to guest NAC 192.168.64.204. NAC Manager Java Client asks about this, because this ECA is already added to NACs 192.168.4.216 and 192.168.64.216:

XMC WebClient does not ask and simply moves switch to the other appliance. The switch only appears in those appliance groups with NACs which are configured as primary or secondary engine of the switch. Is there a workaround?

You don’t need to add a third NAC engine for this. Seems like overkill unless you are planning a massive deployment of clients.

Our NACs have only IP interfaces in our management IP space. A NAC which delivers portal to guest users must be reachable for those guest users (I think) to be able to see guest portal login page. So I assume I have to activate second interface on Guest Portal NAC and use an IP adresss which is reachable from guest users IP space. We wanted to avoid this on our Main-Wireless-NACs or ECA. For this reason we considered a dedicated NAC for Guest Portal.