ARCHITECTURE

Differences between Out-Of-Band Edge and Vendors architectures ?

This document presents the differences in functionality between the architecture Out-Of-Band Edge and the different architectures Out-Of-Band compatible constructors (type Meraki, Aruba, Aerohive, Ruckus vSZ…).

The article is presented in the following PDF

Why do I have to create my own public certificate for the central controller, in case of Out-Of-Band Edge architecture?

In an Out-Of-Band Edge architecture, the user device will request both the Edge and the central controllers.

As described in the flow diagram of Out-Of-Band Edge documentation, the user will:

  • firstly be redirected to the captive portal of the Edge
  • that will redirect the user to the captive portal of the Central (the customer then enters his credentials)
  • If accepted by the central controller, the user device will send a last message to the Edge controller so that it gets locally connected

Because the user device will commmunicate with both Edge and central controllers, and in order to avoid any security alert on the user browser, the Edge and central controllers must have different domain names, each certified by a public certificate (and not self-signed).

While the Edge controllers can keep the default domain name and certificates, you need to define a new domain name on the central controller and buy and install the matching certificate on the central controller.

For more information about how to generate new certificates, you can refer to the article on customized certificates.

How and when should I configure LACP on the equipement connected to UCOPIA physical servers?

Physical UCOPIA controllers from US5000 have several incoming Ethernet ports, and several outgoing Ethernet ports.
These Ethernet ports are configured with LACP (enabling, among others, to reach a greater bandwidth and increase link reliability).

When installing an UCOPIA physical controller (US5000 or bigger), you thus need to correctly configure LACP on the equipment connected to the UCOPIA controller.

The commands to configure LACP differ from vendor to vendor. Here are the commands for Cisco equipment:

  • Creation of a channel-group to bundle together the different physical ports:
    Switch1(config)#interface range gigabitEthernet 0/1 - 2
    Switch1(config-if-range)#channel-group 1 mode active //other modes are possible like passive or on
    Switch1(config-if-range)#channel-protocol lacp
    Switch1(config-if-range)#exit
  • Creation of a port-channel virtual interface linked to the channel-group created previously: interface port-channel command
    Switch1(config-if-range)#interface port-channel 1 
    Switch1(config-if)#switchport mode trunk
    Switch1(config-if)#switchport trunk allowed vlan x,y
    Switch1(config-if)#no shutdown
    Switch1(config-if)#exit
  • Checking of the entries of channel-group:
    show etherchannel summary

For more information, please refer to the documentation of your vendor on how to configure LACP.

How can updates/upgrades impact my service?

During an update/upgrade, you should be aware that:

  • The authentication server of UCOPIA controller restarts, thus disconnecting all users. This forces the users without the automatic reconnection to authenticate again on the splash page.
  • As many packages need to be installed, the service may be disrupted or interrupted (the installation time is greater for evolutive upgrades than for corrective updates)

How can I add or modify a VLAN on an UCOPIA cluster?

As explained in the detailed article on High Availability (HA), the local subnets are not synchronized between the members of an UCOPIA cluster. In order to add or modify a VLAN on each member, here are the steps to be performed:

  1. Create or modify a VLAN on each member of the cluster.
    Attention: when modifying a non-native VLAN, there will be a service interruption for this VLAN only. If the modified VLAN is the native one (in or out), then the service interruption will extend to all VLANs.
  2. Once the VLAN has been created/modified, and only if IP settings (address or mask) have been changed, then you must validate again the HA configuration (and check the virtual IP addresses to be used after the VLAN  creation/modification). This is to be done on “Configuration > High Availability > Redundancy or load-balancing”.
    This step isn’t necessary if you haven’t modified IP settings (ex: only DHCP modification, or modification of the admin or deleg access).
    Attention: the validation of HA configuration interrupts service on the whole cluster for a few minutes

How to set up an Out-Of-Band Vendor architecture?

Here are some useful documentations in order to help you install UCOPIA controllers in an Out-Of-Band Vendor architecture:

Vendor Documentation
Meraki – Description of the configuration steps on this link
Aerohive – Description of the configuration steps on this link
Ruckus – Description of the precise configuration to be done on this link
Aruba – Description of the precise configuration to be done on this link
Cisco – Description of the precise configuration to be done on this link

How to set up an Out-Of-Band Edge architecture?

If you want to set up an Out-Of-Band Edge architecture, you can refer to the documentation Out_of_Band_Edge_Architecture_Guide, directy stored in your UCOPIA controller from version 5.1.6, or to the documentation on that link.

OPERATIONS

Why is the domain name « controller.access.network » resolved by the UCOPIA controller with a public IP address?

Since the version 5.1, the domaine name “controller.access.network” is resolved by UCOPIA controllers with a public IP address “195.154.179.210” (that all UCOPIA controllers consider to be one of their own IP address).

This has been done for 2 reasons:

1) To ease the UCOPIA configuration: If the UCOPIA controller is not used as the DNS server, you would have to configure the external DNS server with the correct resolution of “controller.access.network” for each incoming network.
Thanks to the public DNS translation “controller.access.network”, no additional DNS entry need to be done on the external DNS server.
All unauthenticated users who are redirected to “controller.access.network”, try to reach the public IP address. This way, they have to go through the UCOPIA controller in charge that will detect this request to our “public IP address of UCOPIA” and answer with the splash page.

2) To ensure that users are handled by the right controller, in case of HA architecture: Let’s take the example of an active/active architecture, where an external DNS server redirects all users to one of the active controller (DNS entry: “controller.access.network” <–> VIP 1). Then, some issues might be observed, because the user is always redirected to the splash page of one UCOPIA controller that can be different from the UCOPIA controller that actually manages the user.
> An authenticated user arrives on the network
> After resolution of the “controller.access.network” in “VIP 1”, the user is redirected to the splash page of the UCOPIA controller n°1
> If the user tries to connect via Facebook, then a temporary “open URL” to Facebook is enabled on the UCOPIA controller n°1
> The unauthenticated user is redirected to Facebook website, to connect, but as he is managed by the active UCOPIA controller n°2 and not n°1, his flows are going through UCOPIA controller n°2 that block them
> The user is unenabled to connect on the network.

So, thanks to the public DNS translation “controller.access.network”, no additional DNS entry need to be done on the external DNS server. Whatever the used DNS server, unauthenticated users will always be redirected to the UCOPIA controller that is on their way to the Internet.

Response matrix for helping answering tenders

In order to help you answer tenders where you propose UCOPIA as a solution, we have drawn up this reponse matrix, with a list of the main UCOPIA features, to be found on this link.

For more details on each of these features, we invite you to read the White Paper or the ADVANCE / EXPRESS manuals.

How can I migrate from one UCOPIA controller to another?

If you have an UCOPIA controller 1 and would like to migrate to another new controller 2, here are the different ways to do it, depending on your expectations.

1- CONFIGURATION EXPORT:

If you want the new controller 2 to have the exact same configuration as controller 1 (and you don’t want to do it manually), then, you should export the configuration (that includes the internal user accounts) from the old controller 1 to import it to the new one 2. Note: the configuration backup includes all configuration settings (network, external services, profiles…) and the internal UCOPIA directory, but doesn’t include user logs.

Prerequisites:

  • The 2 controllers must have the exact same version and build.
  • If controller 1 has an ADVANCE licence, the new controller 2 needs to also have an ADVANCE licence, for the configuration export

Process:

  • [Controller 1] Export the configuration from controller 1: go to “Operations > Configuration management > Run a controller backup” from the admin interface of controller 1
  • [Controller 2] Import the configuration backup file to controller 2: go to “Operations > Configuration management > Manual restoration” from the admin interface of controller 2

2- EXPORT OF THE USER ACCOUNTS ONLY:

If you can manually redo the configuration of controller 2 (because it is simple and not necessarily similar to the configuration of controller 1) but want to export the user accounts, then, you should export the user accounts, using the migration tool.

Note 1: Re-creation of old users profiles on the controller 2 might be needed before the users import process on this controller.

Note 2: During the user accounts import process, every validity settings, time credit and time slots specific to each user will be erased.

  • [Controller 1] Export the configuration from controller 1: go to “Operations > Configuration management > Run a controller backup” from the admin interface of controller 1
  • [Controller 2] Go to “Operations > Migration tools > Import users” and select the configuration backup file exported from controller 1

image

3. LOGS EXPORT:

Prerequisites:

  • The 2 controllers can communicate with each other
  • The version of the controller 2 must be equal or greater of version of controller 1

Process if controller 1 has a version  5.0: The old controller 1 will play the role of FTP server and controller 2 will get its logs from controller 1

  • [Controller 1] To access the migration tool on the old controller, connect to the admin interface with the following adminstrator account:
  • URL : https://ip_old_controller /admin
    Login : maintenance
    Default password : similar to the password of your « admin » account, after the 1st password modification
  • [Controller 1] Go to “Operations > Migration tools > Transfer logs” and enable controller FTP server, so that the old controlleur 1 will play the role of FTP server and send the logs to the controller 2. Select the version and serial number of the new controller 2.

image

  • [Controller 2] Create an external FTP server in “Configuration > External services > FTP” and create a FTP account corresponding to the controller 1, with the login and password as following:

Login : maintenance
Default password : similar to the password of your « admin » account, after the 1st password modification.

image

  • [Controller 2] Import the logs from the controller 1 to controller 2: go to “Configuration > Logging > Enable log backup transfer” from the admin interface
  • [Controller 2] Go to “Operations > Log file management ” and click on “Refresh data” above the table to see the log files of controller 1. Select the log files you want to import
  • [Controller 2] Once the transfer and synchronization done, go to “Configurations > External services > FTP” and delete the FTP account of the old controller 1.

Process if controller 1 has a version < 5.0: The new controller 2 will play the role of FTP server and controller 1 will import its logs into the new controller 2

  • [Controller 2] Access the migration tool on the old controller and go to “Operations > Migration tools > Transfer logs” and enable controller FTP server, so that the new controlleur 2 will play the role of FTP server and receive the logs from the controller 1. Select the version and serial number of the old controller 1.
  • [Controller 1] Create an external FTP server in “Configuration > External services > FTP” and create a FTP account corresponding to the controller 2, with the login and password as following:

Login : maintenance
Default password : similar to the password of your « admin » account, after the 1st password modification.

image

  • [Controller 1] Export the logs from the controller 1 to controller 2: go to “Configuration > Logging > Enable log backup transfer” from the admin interface
  • [Controller 1] You can manually synchronize, delete… the logs backup of your choice in “Operations > Log file management”
  • [Controller 2] Once the logs migration done, it is mandatory to synchronize them in the new controller to be able to exploit them. Go to “Operations > Log file management ” and click on “Refresh data” above the table. Only the, the imported logs will be displayed in the table.
  • [Controller 2] Go to “Operations > Migration tools > Transfer logs” and disable controller FTP server

What basic troubleshooting steps are useful when a user can’t access the Internet?

The diagram below describes the troubleshooting steps to be performed when a user can’t access the Internet through an UCOPIA controller.

image

How can I configure an ICAP server in UCOPIA?

Here is an example of target architecture with an external ICAP server:

ICAP server

CONFIGURATION ON THE ICAP SERVER

Make sure the ICAP server listens on TCP / port 1343, where UCOPIA will send its ICAP requests.

CONFIGURATION ON THE UCOPIA CONTROLLER

  • Activation of the external ICAP service: In « Zero-conf > Web », add the port 80 (and 443 if HTTPS filtering) as a port supported after authentication and enable the redirection to a Web gateway with ICAP service.
    Note: the option “Append the client’s IP address in the HTTP requests forwarded by proxy after authentication” only concerns external proxies. UCOPIA always sends to the ICAP server the following fields:
    – X-Client-IP (= X-Forwarded-For)
    – X-Authenticated-User (= user ID encoded in base64)
    Attention: When activating the ICAP service, the UCOPIA controller isn’t able to apply its own filtering rules.

ICAP-conf-UCOPIA

  • Make sure that the profiles whose traffic should be controlled by the ICAP server have the option “Web traffic > Enable proxy Web redirection for each port…” enabled, in “Management > Profiles”

Here is an example of data from a TCP stream from UCOPIA outgoing interface with a configured external ICAP server:

ICAP-messages

PORTALS AND CUSTOMIZATION

GRPD & portal personalization

UCOPIA proposes you a captive portal customization to display GDPR related information :

To set it up, you will need to work on visual model based on the “standard” factory visual model (available in version 5.1.x with new features enabled):

  1. In « Configuration > Customization > Portals > Visual models tab» : export the visual model by clicking on the zip icon
  2. unzip this file twice and you should get 2 folders : « portal » and « deleg »
  3. In « portal/ressources/custom/ » paste this file
  4. Zip together the folders « portal » and « deleg »
  5. Import the created .zip file into UCOPIA via « Configuration > Customization > Portals > Visual models tab », and the following steps :
    • click on the edit icon (tools icon) of visual you exported in 1
    • Select«external model», give in the .zip file created in step 4, select responsive model and validate

Warning:

  • The proposed text is an example. You will have to adapt it for your customer
  • We strongly advise to have this text reviewed by a jurist
  • We also advise to add into it a link to your customer’s privacy policy (most of the time on the customer’s website)

How to change the logo and background image on a customized portal?

If you have created a splash page based on the factory model “standard” or on an external model, then you cannot use the graphical editor embedded in the controller itself to customize the splash page.

Thus, to modify the logo and background images on the splash page:

  • You can either use the Wizard on UWS and deploy the new visual model on the controller
  • Or, you can export of the source code of the captive portal and modify it as wished

Here are the necessary steps for the latter solution:

– In the menu “Configuration > Customization > Portals > Visual models”, export the visual model you want by clicking on the compression icon.

– You will get a .zip file to be unzipped.

– Go to ” portal\resources\_images” and change the “background.png” file with your own background picture (and keep the same name and extension) and/or change the “ucopia-logo-white.png” with your own logo picture (and keep the same name and extension)

– Once this is done and saved, zip the files into a new one.

– In the menu “Configuration > Customization > Portals > Visual models”, import the new visual model by clicking on “Add a visual model”.

How can I have charters displayed in the right language while the rest of the portal is in default language ?

UCOPIA standard portal supports up to 16 languages.

If the default language of the user browser is not supported by UCOPIA, then the whole portal will be displayed in the default language of the portal.

Yet, UCOPIA gives you the means to have an adapted charter, with a charter displayed in the not-supported language (let’s say Czesh in our example), even if the rest of the portal will remain in English.
The charter can be defined in many languages (not only the 16 supported languages but many others like Czesh, Finnish…) from the UCOPIA administration tool “Configuration > Customization > Charters > Add a new charter > Select the language”.

Then, for the Czesh charter to be displayed in Czesh and not English, you need the following change in the portal code itself :

– In the menu “Configuration > Customization > Portals > Visual models”, export the visual model you want by clicking on the compression icon.

– You will get a .zip file to be unzipped.

– In the file “portal\resources\_javascript\portal_global.js” (and similarly in “portal_mobile\resources\…” and “portal_tablet\resources\…” if your portal isn’t in a responsive model), modify the code as following:

// Translate policies
//My customization to be done here
var policy_custom_lang = displayLang;
if( navigator.language == "cs" ){ policy_custom_lang = "cs"; };
logonForm_policy_configure(policy_custom_lang);
autoLogonForm_policy_configure(policy_custom_lang);
subscriptionForm_policy_configure(policy_custom_lang, 'one');
oneSubscriptionForm_connect_policy_configure(policy_custom_lang);
//\End of my customization to be done here
subscriptionForm_policy_configure(displayLang, 'direct');
subscriptionForm_policy_configure(displayLang, 'print');
subscriptionForm_policy_configure(displayLang, 'mail');
subscriptionForm_policy_configure(displayLang, 'sms');
subscriptionForm_policy_configure(displayLang, 'paypal');
subscriptionForm_policy_configure(displayLang, 'ogone');
subscriptionForm_policy_configure(displayLang, 'pps');

– Once this is done and saved, zip the files into a new one.

– In the menu “Configuration > Customization > Portals > Visual models”, import the new visual model by clicking on “Add a visual model”.

USER AUTHENTIFICATION / REGISTRATION

How to avoid confusing passwords with visually similar characters?

When generating passwords for Wi-Fi users, it is important for the password to be clearly readable and not to have confusion between characters such as capital “i” (I) and lowercase “l”, or the capital “o” and number zero.

  • With UCOPIA, you can define your own constraints for the passwords, in the administration tool “Management > Input constraints”. For instance, you can forbid capital letters, force the password to be only made up of digits…
  • Once your configuration of input constraints created, you just need to apply it on the desired profiles in “Management > Profiles > Modify a profile > Password policies”. You can apply the password policy only for password being automatically generated (during a self-subscription or on the delegation interface) and/or for password being manually generated (by the user or and delegated administrator)
image

INSTALLATION

How can I integrate a UCOPIA controller with an external Olfeo server?

This document explains how to integrate the UCOPIA controller with the proxy and URL filtering solution Olfeo, via an ICAP connection. The configurations to be done on UCOPIA on one hand, and on the Olfeo server on the other hand are detailed.

USER MANAGEMENT

Can I filter P2P traffic with an UCOPIA controller ?

Unfortunately, there is no easy solution to block Peer2Peer traffic. A possible solution is to block the P2P server where customers register to get the files to be downloaded.

There are 2 cases:

  • If the P2P servers use the standard web port (80 and 443): you can create new URL categories where the domain name and IP@ of the P2P server is specified, and block this category in the profiles of your choice.
    – Add ports 80 and 443 in the list of supported ports after authentication (“Configuration > Zero configuration > Web”)
    – Create a new URL category, in “Management > URL categories “)
    – Activation of the black list in the target profile (“Management > Profiles > Web traffic”)
  • If a random port is used: in this case, it would be very time-consuming to manually enter the more than 40000 available ports in the list of supported ports by UCOPIA. Blocking traffic sent to a given @IP whatever the port is possible via the definition of a new service. But, user profiles only accept whitelist of services and no blacklist. Given the number of IP@ to be allowed to a user, this isn’t a practical solution.

LOGGING

How can I know the size of the log files in my UCOPIA controller?

  • To know the size of the user log files on your UCOPIA controller, go to the administration tool “Operations > Log file management”. Here, you can see the size of your user log files (in our example: 17.77 MB) and the free memory (in our example: 434.12 GB).
    Every day, the logs of the day are compressed into a new file with the extension .tar.bz2

Log-file-size

  • On the administration tool, “Monitoring > System > Log partition”, the log partition gives the information of the partition containing all the logs, and not only user logs : user logs, configuration backups, the update patches, the different captive portals
    In our example, the log partition is about 9,6GB (so the user logs only represents 0,18% of the log partition)

Log-partition