Routed architecture

Content table
Introduction ................................................................................................................................. 2
1. What are the functional differences between a switched and a routed architecture ................ 3
2. What are the prerequisites for the network configuration? .................................................... 4
3. Is there any recommendation for the incoming addressing policy? ......................................... 7
4. Does the routed architecture change the way the users are redirected to the captive portal and
are managed by UCOPIA? ............................................................................................................. 7

Introduction
This article presents the prerequisites and required configuration for a routed network architecture.

When working with a routed network architecture, with at least one router sitting between the user workstations
and the controller incoming interface, and/or sitting in the outgoing interface of the controller, a certain number
of parameters must be verified and configured on the different equipment.

Our explanations will be based on the below network diagram where routers are installed in the incoming and
outgoing interfaces of UCOPIA.
Access network 2

Remote network 1 Access network 1

Remote network 2

Remote access 3

Remote network 1: Access network 1:

192.168.10.0/24 192.168.100.0/24
Gateway: 192.168.10.254 (Router 1) Gateway: 192.168.100.254 (UCOPIA IN 1)
DHCP: 192.168.100.254 (UCOPIA IN 1)
Access network 2:
Remote network 2: 192.168.101.0/24
192.168.11.0/24 Gateway: 192.168.101.254 (UCOPIA IN 2)
Gateway: 192.168.11.254 (Router 2)
DHCP: 192.168.100.254 (UCOPIA IN 1)

Remote network 3:
192.168.12.0/24
Gateway & DHCP: 192.168.12.254 (Router 3)
1. What are the functional differences between a switched and a
routed architecture
A routed architecture implies an interconnection of different networks by means of routers.
As UCOPIA doesn’t belong to the same VLAN as users, the mechanisms based on level 2 protocols do not
work any longer.

The routed architecture impacts the following UCOPIA features, which will not be available:
 "Fixed IP" Zero Configuration:
This mechanism where a user with a fixed IP address is automatically handled by UCOPIA is based on
the responses to ARP requests coming from the user workstation.
 Load balancing between a cluster of two UCOPIA Advance controllers:
The mechanism of distributing workstations to one or the other UCOPIA controllers located on the same
cluster, is determined in the DHCP server configuration, by assigning a specific gateway. But in a routed
architecture, the UCOPIA controllers are not the gateways of the workstations. So this load balancing
should be provided by the gateways of the workstations.
 Recognition of user equipment (if UCOPIA is not DHCP server, like in our above example “Remote
access 3”, or if flows are NATed):
If UCOPIA is not DHCP server or users’ flows are NATed, then UCOPIA will only see the MAC address of
the router located in its incoming interface and won’t have knowledge of the users’ equipment MAC
addresses. Thus, the features related to the user equipment management are not available (like locking
user accounts with their recorded equipment, automatically authenticating a recognized equipment or
associating a unique user account per device with One-Click Button registration).

UCOPIA distinguishes the routed and switched networks as you can see in the administration tool “Configuration
> Network > Controller > Type of incoming network”:
1. Switched network: UCOPIA will only accept users’ equipment on the same VLANs as its incoming interfaces,
and will retrieve the MAC address of users’ equipment (from the ARP table or DHCP leases) to insert the
information in the logs.
2. Routed network: Users come from a routed network. Their IP address is either associated to the router
MAC address (if no DHCP relay, then no MAC address is recorded in the logs) or can be associated to the
user’s equipment MAC address (if DHCP Relay and UCOPIA is DHCP server).
3. Switched and routed network: Users can come from a switched or a routed network. This is the network
enabled by default, for the most general case (the configuration to be preferred).
2. What are the prerequisites for the network configuration?

a- Definition of the incoming access networks: Define the Access networks 1 and 2 (of the above example) in
“Configuration > Network > Incoming networks”
b- Definition of the incoming remote networks: Define the Remote networks 1 and 2 (of the above example)
in “Configuration > Network > Incoming networks”
c- Static routes: UCOPIA must be one of the hop on the flow path between the end user ‘s equipment and the
resources made available (internal network, Internet...).
It is essential to create static routes on UCOPIA so that the flows destined for the end users (in the remote
networks 1, 2 or 3 in the example above) can be correctly routed by UCOPIA to the right gateway (in
“Configuration > Network > Static routes”).

NOTE: You can then verify the correct routing between the incoming VLAN of the UCOPIA controller and
the network of the remote site (provided that your equipment accepts the ICMP messages), for instance thanks
to ping or traceroute commands.
d- [optional] DHCP: For remote subnets, we recommend the default gateway of users to be configured as
DHCP Relay, and UCOPIA as remote DHCP server.
So your users can benefit from the comfort created by our MAC addresses management like explained
previously at the beginning of the article.

e- Outgoing networks and addressing policies:

After you have configured the incoming networks, you can now configure the outgoing networks including
the outgoing addressing policies. Define the outgoing addressing policies for each profile in “Configuration
> Network > Outgoing networks”.
- For instance, “Employees” will be routed to the outgoing network “employees” with access to the
“Employee” zone (allowing access to the internal resource).
- “Guests” users in the remote networks will be routed to the outgoing network “out” with access to the
default-zone.
Finally, you need to define the default addressing policy of the output flows of the controller (NAT or
Routing) that will be applied to data from unauthenticated users and from the controller itself.

3. Is there any recommendation for the incoming addressing policy?

UCOPIA recommends to apply routing policies instead of NAT in the path between user’s equipment and UCOPIA
(between the router 1 till the router n in the above example) for different reasons:
- NAT consumes more processor and memory resource as NAT needs to translate IP addresses for all
incoming and outgoing flows and memorize it in a translation table
- NAT (except 1 to 1) causes loss of end user’s traceability, as illustrated below. UCOPIA only sees in the
packet the NAT IP address of the router n and never the user’s equipment IP address nor its MAC
address. In such a case, UCOPIA can’t track the traffic per user and can’t distinguish a user coming from
the remote network 1 or from the remote network 2 (see the above schema)  That is why no dynamic
feature per zone is possible (e.g. portal customization per zone, adaptive profile according to the
location…)

4. Does the routed architecture change the way the users are
redirected to the captive portal and are managed by UCOPIA?

If UCOPIA is inline, then all interception and captive portal redirection techniques are similar in both routed and
switched networks.
When an unauthenticated user asks for an URL, UCOPIA answers that the address of the URL has changed and
that the new URL address is now the one of the captive portal (ex: https://controller.access.network/portal).
The only condition is to make possible the resolution of the captive portal redirection URL, either by configuring
UCOPIA as the DNS server, or by adding a new DNS entry on the external DNS server.