Review the following configuration considerations when installing and configuring ExtremeCloud IQ Site Engine ExtremeControl.
- ExtremeControl Configuration Tables
- General Considerations
- Considerations When Implementing Policy Roles
- ExtremeWireless Controller Configuration
- DNS Proxy Functionality for Registration and Remediation
ExtremeControl Configuration Tables
The following tables provide valuable information to help guide you through the deployment of Extreme Networks ExtremeControl for your network. The first table displays suggested ExtremeControl configurations to use for different network deployment circumstances (e.g. type of end-systems on the network, network topology, authentication method deployed, etc.). The second table displays details and information for each of the different suggested ExtremeControl configurations. The information in the tables assumes that DHCP is deployed on the network.
Suggested ExtremeControl Configuration for Different Deployments
| Policy/VLAN Switch Configuration |
Number of Devices Allowed to Connect to Authentication-enabled Edge Port |
Type of End-Systems |
Authentication Method Deployed |
Switch Support IEEE 802.1X MIB |
Switch Support, Session Timeout and Termination Action RADIUS Attributes |
Suggested Configuration |
|---|---|---|---|---|---|---|
| - Policy Only (without changing of VLANs) |
* | * | * | * | * | A |
| - VLAN only - Policy and VLAN - Policy Only (with changing of VLANs) |
Multiple | Microsoft XP SP1 with KB822596 installed1 |
802.1X2 | Yes | * | A |
| - VLAN only - Policy and VLAN - Policy Only (with changing of VLANs) |
Multiple | * | 802.1X2 | Yes | * | B |
| - VLAN only - Policy and VLAN - Policy Only (with changing of VLANs) |
Multiple | * | 802.1X2 | No | Yes | C |
| - VLAN only - Policy and VLAN - Policy Only (with changing of VLANs) |
Multiple | * | 802.1X2 | No | No | D |
| - VLAN only - Policy and VLAN - Policy Only (with changing of VLANs) [for Enterasys switch] |
Multiple | * | MAC Authentication |
* | * | B |
| - VLAN only - Policy and VLAN - Policy Only (with changing of VLANs) [for non-Enterasys switch] |
Multiple | * | MAC Authentication |
* | Yes | C |
| - VLAN only - Policy and VLAN - Policy Only (with changing of VLANs) [for non-Enterasys switch] |
Multiple | * | MAC Authentication |
* | No | D |
| - VLAN only - Policy and VLAN - Policy Only (with changing of VLANs) |
Single | Microsoft or MAC OS |
* | * | * | E |
| - VLAN only - Policy and VLAN - Policy Only (with changing of VLANs) |
Single | Linux | * | * | * | F |
| Wireless Device | Multiple | * | * | * | * | G |
* = Any value.
N/A = Not applicable.
1For more information on this patch, see the following link:
http://support.microsoft.com/default.aspx?scid=kb;en-us;KB822596
2When 802.1X is implemented to authenticate multiple users on a
single switch port, the downstream device providing connectivity to the users must support the
forwarding of EAP frames. Unintelligent devices such as repeaters and switches with newer
firmware releases should forward EAP frames. However, some switches do not forward EAP frames
therefore preventing the 802.1X authentication of multiple users on a single port.
ExtremeControl Configuration Details
|
Configuration |
Port Link Control |
Assessing Session Timeout |
Assessing Policy Configuration |
DHCP Server Configuration Considerations |
Other Considerations |
|---|---|---|---|---|---|
| A | Disabled | Disabled | * | No | N/A |
| NOTE:
This is the simplest of configurations. |
|||||
| B | Disabled | Disabled | Initial Scan Only |
- Set short lease times (e.g. 1 min) for the unauthenticated,
Assessing, and
Quarantine VLANs - Normal lease times can be configured for the Accept (Production) VLANs |
N/A |
| NOTES: When an end-system transitions from the unauthenticated, Assessing, or Quarantine VLAN to another VLAN, the end-system will soon renew its IP address via DHCP to automatically re-establish connectivity to the network. When a compliant end-system on the Production VLAN is subsequently quarantined after failing a re-assessment, the end-system's connectivity to the network will be lost until expiration of the DHCP lease for the Accept (Production) VLANs. |
|||||
| C | Disabled | Enabled | Initial Scan Only |
- Set short lease times (e.g. 1 min) for the unauthenticated,
Assessing, and
Quarantine VLANs - Normal lease times can be configured for the Accept (Production) VLANs |
N/A |
| NOTES:
When an end-system transitions from the unauthenticated, Assessing, or Quarantine VLAN to another VLAN, the end-system will soon renew its IP address via DHCP to automatically re-establish connectivity to the network. Furthermore, the end-system will continually reauthenticate to the network while it is being scanned. When a compliant end-system on the Production VLAN is subsequently quarantined after failing a re-assessment, the end-system's connectivity to the network will be lost until expiration of the DHCP lease for the Accept (Production) VLANs. |
|||||
| D | Disabled | Disabled | Initial Scan Only |
- Set short lease times (e.g. 1 min) for the unauthenticated,
Assessing, and
Quarantine VLANs - Normal lease times can be configured for the Accept (Production) VLANs |
Set short reauthentication interval manually on edge switches (e.g. 2 min) |
| NOTE:
This is not a very scalable configuration model, and therefore should not be implemented for a network with a large number of end-systems. |
|||||
| E | Enabled | Disabled | * | No | N/A |
| NOTE:
End-system will be reauthenticated and will renew its IP address via DHCP with link down/up execution. |
|||||
| F | Enabled | Disabled | Initial Scan Only |
- Set short lease times (e.g. 1 min) for the unauthenticated,
Assessing, and
Quarantine VLANs - Normal lease times can be configured for the Accept (Production) VLANs |
N/A |
| NOTES:
End-system will be reauthenticated with link down/up execution and will automatically re-establish network connectivity via DHCP upon lease expiration of the IP address in the unauthenticated, Assessing, and Quarantine VLANs. When a compliant end-system on the Production VLAN is subsequently quarantined after failing a re-assessment, the end-system will be reauthenticated and will renew its IP address via DHCP with link down/up execution. |
|||||
| G | Disabled | * | * | * | RFC 3576 Reauthentication Enabled |
| NOTES:
ExtremeCloud IQ Site Engine supports RFC 3576 which provides for forced reauthentication (Force Reauth) of end-systems connected to an RFC 3576-capable switch. RFC 3576 defines new RADIUS messaging that enables the ExtremeControl Gateway to send Disconnect or Change of Authorization (CoA) RADIUS messages to the authenticating switch or AP to force reauthentication on a currently authenticated end-system. |
|||||
* = Any value.
N/A = Not applicable.
General Considerations
- Gateway RADIUS Attributes to Send - Send RFC 3580 Only Feature. This feature
(configured in the Add/Edit Switches to Identity and Access Appliance Group panel) lets you specify
that an ExtremeControl Gateway sends a VLAN (instead of a policy) via RFC 3580-defined
RADIUS Tunnel attributes to the RFC 3580-enabled switches
in your network. Keep in mind the following considerations when configuring this
feature:
- Send RFC 3580 Only is not supported on Matrix E7 Devices. Matrix E7 devices should not be configured with the "Gateway RADIUS Attributes to Send" parameter set to RFC 3580 Only.
- Send RFC 3580 Only does not support end-systems with static IP addresses. The Send RFC 3580 Only feature is not-supported for end-systems with static IP addresses. This is because end-systems transitioned between VLANs must be assigned an IP address on the appropriate subnet to maintain IP connectivity to the network, which is facilitated dynamically through DHCP.
- Send RFC 3580 Only requires a particular DHCP configuration for Active/Default Role port mode. When the Send RFC 3580 Only feature is configured, the Active/ Default Role port mode on network devices requires a particular DHCP configuration. The DHCP lease time for the pool of IP addresses that corresponds to the default role's VLAN must be short (e.g. less than 1 minute) because the Active/Default Role port mode enables end-systems to obtain IP addresses via the DHCP protocol before they are authenticated to a VLAN.
- Switch management fails with Send
RFC 3580 Only and certain Auth Access
Types. Switch management via TELNET/WebView fails with the following configuration in the Add/Edit Switches to
Identity and Access Appliance Group window:
Auth Access Type = "Management Access" or "Any Access"
Gateway RADIUS Attributes to Send = "RFC 3580 Only"
This is because switches check the "mgmt" attribute in the Filter-ID for Telnet management. To avoid this problem, set the Auth Access Type to "Network Access."
- Enable Port Link Control Option. Port link control is required if you
are using VLAN only (RFC 3580) switches or if
you are using policy with VLANs on policy-enabled switches.
When an end-system is transitioned between VLANs with a new VLAN being assigned to a switch port, the end-system
is required to obtain a new
IP address for the assigned VLAN. To do this, the ExtremeControl Gateway links down the port
(using the ifAdmin MIB), waits
the configured amount of time, and then links up the port,
causing the end-system to make a new DHCP request and get a new IP
address.
- Port Link Control is not supported on authentication-enabled switch ports providing connectivity to multiple end-systems. Do not enable port link control for switches authenticating multiple users per port. When an ExtremeControl Gateway is configured to return only the VLAN RADIUS attribute, the gateway links down the authenticated port to force the end-system to release and then renew the DHCP IP address when port link control is enabled. This action interrupts IP connectivity of other authenticated end-systems on the port. If the switch is an Enterasys switch, protection is automatically provided by reading the number of users currently on the port prior to linking down an port.
- Port Link Control is only supported on Windows XP or later. Port link control is only supported for end-users that are authenticating from end-systems running Windows XP or later. When an ExtremeControl Gateway is configured to return only the VLAN RADIUS attribute, the gateway links down the authenticated port to force the end-system to release and then renew the DHCP IP address when port link control is enabled. However, other systems such as NT workstations, do not release their DHCP IP address when the port is linked down. To account for this scenario, disable port link control, set the ExtremeControl Profile to "Use Assessment Policy During Initial Assessment Only," and set the DHCP lease time for the IP address pools that correspond to the VLAN(s) associated to the Quarantine and Assessing access policies, as well as the default VLAN associated to the unauthenticated state of the port, to a low value (e.g. 1 minute). This forces an end-system to send DHCP Request messages every 30 seconds while it is unauthenticated, being assessed, and quarantined. Upon passing assessment, the end-system is dynamically assigned an IP address on the production VLAN shortly after assessment is complete, establishing connectivity to the network on the production VLAN.
- ExtremeControl Gateway DHCP Snooping:
- Option 1: Locate the ExtremeControl Gateway on the same subnet as the DHCP server. If the ExtremeControl engine is in the same subnet
(relay router interface) as the end-system, it is able to hear ACK responses from the DHCP
server, enabling it to have
more accurate DHCP entries unless the relay router
(or DHCP server) sends unicast ACK responses directly to the end-system.
Note: Whether the ACK response is sent using unicast or broadcast is normally determined by how the end-system requests the packet. If the end-system sends out a DHCP discover/request with a unicast bootp flag, then the DHCP server (or relay router) sends the ACK response using unicast. This is typically what happens. Sometimes, the end-system can request the DHCP discover/request with a broadcast bootp flag set. In this case, the end-system gets the ACK response with broadcast, and the ExtremeControl engine hears the ACK response if it is in the same broadcast domain.
The benefit of using option 1 over the helper-address implementation described in option 2, is that the helper-address implementation only gets the requests from the end-systems that might not have the correct IP address. When an ExtremeControl Gateway learns a MAC/IP address pair, it sends a message to all other ExtremeControl Gateways, so only one ExtremeControl Gateway needs to live on each subnet with a DHCP server on it, to leverage this technique. - Option 2: Add the ExtremeControl Gateway IP address as a helper address on default gateway routers. To increase the accuracy of the MAP-to-IP resolution, the ExtremeControl Gateway listens for DHCP traffic on port 67 and saves the MAC/IP address pairs it learns. In order to receive DHCP traffic, the IP address of any ExtremeControl Gateway must be added as a helper address on default gateway routers on the network. Routers permit multiple IP helper address entries, so the ExtremeControl Gateway's IP address can be added along with the actual DHCP server IP addresses. When an ExtremeControl Gateway learns a MAC/IP address pair, it sends a message to all other ExtremeControl Gateways, so only one ExtremeControl Gateway IP address needs to be added.
- Option 1: Locate the ExtremeControl Gateway on the same subnet as the DHCP server. If the ExtremeControl engine is in the same subnet
(relay router interface) as the end-system, it is able to hear ACK responses from the DHCP
server, enabling it to have
more accurate DHCP entries unless the relay router
(or DHCP server) sends unicast ACK responses directly to the end-system.
- Configure RADIUS settings on 3rd-party switches. You must manually configure
the RADIUS settings on your third-party switches communicating to the ExtremeControl
Gateway. In addition, make sure that
the shared secret on the switches matches the shared secret you entered in the
Advanced Switch Settings window. This is the
shared secret the switches uses to communicate with ExtremeControl Gateways.
- Configuring Agent-based Assessment Test Sets with Hotfix Checks. When configuring an Agent-based test set to perform multiple hotfix checks, make
sure that the Monitoring Interval is set to at least 5 minutes, so that the
assessment agent does not take a lot of CPU cycles trying to monitor these settings.
- Supported desktop browsers for end-systems connecting through ExtremeControl. The following browsers are supported for desktop end-systems connecting to the network through Extreme Networks ExtremeControl:
- Microsoft Edge
- Mozilla Firefox 34 and later
- Google Chrome 33.0 and later
- Supported mobile browsers for end-systems connecting through ExtremeControl. The following browsers are supported for mobile end-systems connecting to the network through the Mobile Captive Portal of Extreme Networks ExtremeControl:
- Microsoft Edge
- Microsoft Windows 10 Touch Screen Native (Surface Tablet)
- iOS 9+ Native
- Android 4.0+ Chrome
- Android 4.4+ Native
- Dolphin
- Opera
NOTES: A native browser indicates the default, system-installed browser. Although this can be Chrome (Android), this also includes the default, system-controlled browser used for a device’s Captive Network Detection. Typically, this is a non-configurable option for Wi-Fi Captive Network Detection, but default Android, Microsoft of iOS devices are tested for compatibility with the Mobile Captive Portal.
A mobile device can access the standard (non-mobile) version of the Captive Portal using any desktop-supported browsers available on a mobile device. - For other browsers, the Mobile Captive Portal requires the browser on the mobile device be compatible with Webkit or Sencha Touch. To confirm compatibility with Webkit or Sencha Touch, open http://<ip_of_engine>/mobile_screen_preview using your mobile web browser. If the browser is compatible, the page displays properly.
- RADIUS Configuration on E1 Devices. The ExtremeControl engine opens an
SSH/Telnet session on the E1 device and enable RADIUS by running a script of CLI
commands. CLI credentials for the device are obtained from the device
profile and must be configured in the Authorization/Device Access tool.
- RADIUS Authentication and Accounting Configuration on ExtremeXOS/Switch Engine Devices. ExtremeCloud IQ Site Engine uses CLI access to perform RADIUS configuration operations on ExtremeXOS/Switch Engine devices. CLI credentials for the device are obtained from the device profile and must be configured in the Authorization/Device Access tool.
- RADIUS Accounting Configuration on Fixed Switching Devices. ExtremeControl uses CLI to configure RADIUS accounting on Enterasys fixed switching devices (A-Series, B-Series, C-Series, D-Series, G-Series, and I-Series). CLI credentials for the device are obtained from the device profile and must be configured in the Authorization/Device Access tool. This does not apply to A4, B5, and C5 devices running firmware version 6.81 and higher. Those devices support RADIUS accounting configuration using SNMP. For more information, see How to Enable RADIUS Accounting.
Considerations When Implementing Policy Roles
This section describes the communication that takes place between ExtremeControl engines and end-systems connecting to the network. This communication should be taken into account when defining and deploying policy roles and rules on your network. It is particularly critical because certain policy roles and rules can discard traffic that is necessary for communication between the end-system and the engine. For example, in a Guest policy role, NetBIOS traffic is probably discarded, but doing so could impact the MAC to IP resolution process.
Review the following information and verify that the policy roles and rules deployed on your network will permit the required communication between end-systems and your ExtremeControl engines.
IP resolution via NetBIOS
MAC Resolution via NetBIOS
ExtremeControl engine UDP Port 137 <==> End-System Port 137
Remediation and Registration
ExtremeControl engine (TCP or UDP) Port 80 <==> End-System Port (determined on the client)
- HTTP
ExtremeControl engine (TCP or UDP) Port 443 <==> End-System Port (determined on the client)
- HTTPS
ExtremeControl Agent Discovery via HTTP
ExtremeControl engine Port TCP 8080 <==> End-System Port (determined on the client)
ExtremeControl Agent Heartbeat via HTTPS
ExtremeControl engine Port TCP 8443 <==> End-System Port (determined on the client)
ExtremeControl Agent-less Assessment
All ports determined by the selected test set.
The following software is optional and can be installed with agent-less
Assessment:
SAMBA add-on enabled
TCP Ports 149 and 195, and UDP Ports 137 and 138.
End-System Reachability Test (Assessment Configurations - does not apply to
agent-based assessment)
ICMP Ping Test => ICMP Protocol (1), ICMP Type (8)
TCP Ping Test => Default TCP Ports: 21, 22, 23, 25, 79, 80, 111, 135, 139, 445, 497, 515, 548,
1025, 1028, 1029, 1917, 5000, 6000, 9100
ExtremeWireless Controller Configuration
- The NAS IP address used for the wireless controller should be either the management IP address or an IP address of one of its physical data ports, or all zeros to force ExtremeControl (ExtremeControl) to use the source IP. If a logical IP address is used, then ExtremeControl is unable to reauthenticate end-systems.
- If you have configured Assisted Remediation, you must
perform the following steps if your network includes wireless controllers:
- Enable the "ToS override for ExtremeControl" option configured through Wireless Manager in the Edit WLAN Service > Authentication Mode Configuration > Settings window.
- If Policy Manager is not being used to configure policy on the wireless
controller, use Wireless Manager to
manually add the following rule to the VNS Quarantine, Assessing, and Unregistered filters
to permit HTTP traffic to pass through (IN/OUT) the controller when end-systems
are proxied to the Internet during remediation.
0.0.0.0/0 tcp port 80 (Allow traffic In/Out) - If Policy Manager is being used to configure policy for the wireless controller, use the Classification Rule Wizard to add an "Allow HTTP" rule to a service currently included in your Quarantine, Assessing, and Unregistered policy roles. The rule would be a traffic classification type "IP TCP Port Destination" with the TCP type set to HTTP (80) and the Access Control set to "Permit Traffic."
DNS Proxy Functionality for Registration and Remediation
ExtremeControl (ExtremeControl) Gateway engines provide DNS proxy functionality for use in networks that are deploying registration and/or remediation, but cannot configure the policy-based routing that is required to redirect network traffic to the web portal. Using DNS proxy, any end-system that needs to be redirected to the remediation and registration web portal has its DNS packets spoofed to direct all web page requests to the ExtremeControl Gateway engine. This enables networks that do not have a router to deploy registration and remediation.
Basic Operation
To set up DNS proxy, the ExtremeControl engine is configured as a secondary DNS server in the DHCP scope, in addition to the primary DNS server on the network. When an end-system is required to register or undergo remediation, access to the primary DNS server is blocked and the end-system sends its DNS requests to the DNS proxy on the ExtremeControl Gateway engine.
The DNS proxy must determine whether to spoof the packet or forward the request to the primary DNS server. If the end-system is unregistered or quarantined, the DNS proxy spoofs the DNS packet and send back a DNS response to the end-system with the ExtremeControlengine IP address. This redirects the end-system traffic to the web portal where the end user can register or remediate. After the end user has registered or remediated their end-system, their DNS requests are forwarded to the primary DNS server.
For third-party devices, a dynamic ACL is configured to block access to the primary DNS server for end-systems undergoing registration or remediation. This causes the DNS requests to be sent to the DNS proxy. The DNS proxy determines whether spoofing is necessary or not by checking the state of the end-system in the database. If the end-system is unregistered or quarantined, the DNS proxy spoofs the DNS packet.
To permit access to hosts or domains for any protocol other than http, you must add the host or domain to the list of allowed web sites configured in the Network Settings view of the ExtremeControl Edit Portal Configuration window. The DNS proxy uses this list of permitted domains to determine if the end-system is permitted access to the requested domain. This can be useful if you want to enable end-systems to perform specific functions such as anti-virus updates or software updates that run over TCP/UDP ports.
You can also define post authorization assessment behavior using DNS proxy. End-systems in the scan state are granted access according to the assessment settings in your ExtremeControl profile.
- If an assessment policy is not defined, the user is permitted access while being scanned.
- If an assessment policy is defined for initial assessment only, the user is permitted access if they passed the last scan. If the first or last scan resulted in quarantine, the user is redirected to the ExtremeControl Gateway.
- If an assessment policy is defined for all assessments, the user is redirected to the ExtremeControl Gateway.
Enabling DNS Proxy
Use the following steps to enable DNS proxy:
- Enable Registration and/or Remediation via the Edit ExtremeControl Configuration window and enforce. Note that it is important to wait a couple of minutes after enabling or disabling registration and remediation for the DNS proxy to be notified of the enable/disable change, and to start or stop proxying DNS requests.
- Uncomment the "#DNS_PROXY_ENABLE=true" in the config.properties file on the ExtremeControl engine by deleting the # symbol at the beginning of the line.
- Restart the ExtremeControl engine using the nacctl restart command.
- Start the DNS Proxy process on the engine using the /opt/nac/server/dnsProxy.sh start command.
Backup DNS Server
Because the DNS proxy forwards DNS requests to the primary DNS server, it is important to configure a backup DNS server on your network, in case the primary server is down. The DNS proxy polls the primary DNS server every minute. If the primary server is down, a backup DNS server is used. If both servers are down, all DNS requests forwarded by the DNS proxy are dropped.
Troubleshooting
DNS proxy error messages are logged in the /var/log/dnsProxy.log file on the ExtremeControl engine. You can enable diagnostics for DNS proxy by going to the ExtremeControl engine administration web page and enabling the DNS Proxy diagnostic group to provide troubleshooting information. Launch the ExtremeControl engine administration web page by using the following URL: https://<ExtremeControlengineIP>:8443/Admin. The default user name and password for access to this web page is "admin/Extreme@pp." Select the Diagnostics page and then the Server Diagnostics page. View the output in the /var/log/dnsProxy.log file or on the Log Files > Server Log web page.