shared workplace infrastructure in the public sector
TRANSCRIPT
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 1 of 31
White Paper
UK Public Sector Shared Workplace Infrastructure
Secure connectivity for Public Sector agencies over shared wired and wireless
network infrastructures.
Summary
This whitepaper outlines solutions that can provide secure connectivity for Public Sector agencies over shared
wired and wireless network infrastructures. This guide is targeted at network professionals and other personnel
who assist in the design of Public Sector office networks and compliments the design patterns and principles
issued by GDS Common Technology Services (CTS).The solutions outlined in this guide have been developed in
response to a demand for:
location independent working to enable employees from multiple public sector agencies to work
collaboratively and without restriction from any public sector building;
extending secure connectivity beyond public sector buildings to enable efficient service delivery to the
citizen;
maximising the utilisation of public sector buildings through multi-tenancy and consolidation
reducing operating expenses through real-estate reduction.
Demand for increased flexibility, agility and automation.
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 2 of 31
Contents Requirements & Constraints ..................................................................................................................... 3
High-level Shared Workplace Infrastructure Design.................................................................................. 4
Shared Wide Area Network (WAN) Designs .............................................................................................. 5
Common Direct Network Service Provider (DNSP) ................................................................................ 5
Overlay VPN ........................................................................................................................................... 6
DMVPN ............................................................................................................................................... 8
DMVPN per-Tenant .......................................................................................................................... 10
MPLS over DMVPN ........................................................................................................................... 11
IPSec Requirements ......................................................................................................................... 13
A Hybrid WAN Architecture focused on Users Needs ..................................................................... 15
Shared Wireless SSID and Wired LAN .................................................................................................. 17
Wireless Coverage............................................................................................................................ 18
Network Separation ......................................................................................................................... 19
Network Access Control (NAC) ........................................................................................................ 20
Wired 802.1x Solution Overview ..................................................................................................... 20
Wired 802.1x Data & Voice Design Considerations ......................................................................... 21
Access by user enrolment (Guest Wireless Overlay Model) ............................................................ 22
IP Addressing .................................................................................................................................... 23
TrustSec ............................................................................................................................................ 24
Federated RADIUS Authentication Proxy Service ................................................................................ 26
Authentication Workflow ................................................................................................................ 27
Change of Authorisation (CoA) – RFC 5176 ..................................................................................... 28
Direct Internet Access (DIA) ................................................................................................................. 29
Solution Components .......................................................................................................................... 30
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 3 of 31
Requirements & Constraints
The following table lists the requirements and constraints which have been considered when designing the
services.
Table 1. Design Requirements and Constraints
Requirement / Constraint Notes
Compliance with current HMG
Information Assurance guidelines
Use of an assured transport network for unencrypted transmission of OFFICIAL data
Use of a CPA Foundation Grade IPSec or SSL VPN product (with Two-Factor Authentication)
and Walled Garden architecture for transport of OFFICIAL data over a non-assured network,
e.g. Internet
Managed End-User Devices only
Provide a “seamless” user
experience
Not IPSec or SSL VPN based
No reliance on Guest Wi-Fi access
Full access to “home” network
resources
Not relying on Citrix/Terminal Services/VDI services to access applications
Access to shared local resources,
eg. printers
Network designs should include provision for access to shared local resources
Overlapping IP schemes The majority of public sector organisations use the RFC1918 10.0.0.0/8 network for their
internal network resources
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 4 of 31
High-level Shared Workplace Infrastructure Design A shared workplace infrastructure design for a multi-tenant building includes a single wireless LAN SSID and wired
LAN switch infrastructure which all tenants share. In a shared infrastructure design, one or more VLAN’s are
created on the shared LAN for each tenant organisation and their users, both local and roaming trusted visitors, are
dynamically assigned to those VLAN’s as they are authenticated onto the network. Once connected, the user will
have secure access to:
shared network resources within the building such as printers;
their own organisation’s wider network via an Overlay VPN or Common Direct Network Service Provider
(DNSP) WAN connection.
Transport
Tenant 1 DC Tenant 2 DC
MGMT
WLC
AAA/ISE
DMVPN
Spoke
Router
T1
DMVPN
Hub
T2
DMVPN
Hub
Firewall Firewall
AAA/ISE AAA/ISE
AAA Proxy
T1
DMVPN
T2
DMVPN
MGMTAccess
Switch
T1 User
T2 User
Shared
SSIDT1 User
T2 User
Figure 1 - High-level Shared Infrastructure Design with 2 Tenants and Overlay VPN’s
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 5 of 31
Shared Wide Area Network (WAN) Designs
Common Direct Network Service Provider (DNSP)
The simplest form of multi-tenant building connectivity can be provided where all tenants have their WAN’s
provided by the same DNSP or Regional PSN provider. In this scenario, a single Ethernet WAN circuit can be
logically segmented between the tenants and the L3VPN’s of each tenant extended from the SP infrastructure to
the CPE router using VRF-lite technology. The WAN of each tenant is then presented on a separate physical LAN
interface on the CPE router and connected to each tenant’s own LAN infrastructure. Hierarchical QoS (HQoS) is
employed on the WAN circuit to dedicate portions of the available bandwidth to each of the tenants dependent on
their individual requirements.
T3 VRF
T2 VRF
T1 VRF
Tenant 1 WAN
Tenant 2 WAN
Tenant 3 WAN
Tenant 1 LAN
Tenant 2 LAN
Tenant 3 LAN
DNSP
Figure 2 – Common DNSP Design with 3 Tenants using VRF-lite
This approach benefits the tenants by reducing WAN costs to each tenant by eliminating the duplication of WAN
circuits and sharing the cost of connectivity between them.
Typically, one tenant will act as the lead-tenant and have the responsibility of:
Contracting with the WAN service provider;
Apportioning WAN costs to the other tenants and cross-charging them where appropriate;
Providing power, cooling, rack space, etc… for the NTE and CPE equipment of the provider;
Providing technical contacts, access and escort for service provider staff during commissioning and
troubleshooting of the WAN service during and outside of office hours;
Submitting change requests to the service provider on behalf of the other tenants.
A Common DNSP design is most appropriate for buildings where each tenant has a permanent presence requiring
dedicated wired and wireless LAN resources, e.g. a joint emergency services control room manned by police,
ambulance and fire & rescue staff. It is also commonly used technique at shared datacenter facilities.
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 6 of 31
Overlay VPN
In this model, all tenants share connectivity to a common transport network over which they construct overlay
VPN’s to connect their presence in the multi-tenant building to their corporate resources.
Overlay VPN’s have many advantages and solve the issues caused by:
Overlapping IP schemes within the public sector networks where all users will typically be trying to access
resources in one of many 10.0.0.0/8 networks;
The requirement for “seamless” access which prevents the use of techniques such as Network Address
Translation (NAT), Remote-Access SSL or IPSec VPN’s, Citrix, etc… that would typically be used as a
workaround for overlapping IP schemes. By using an overlay VPN for WAN connectivity, the user
experience is unaffected as the tunneling is moved from the end-user’s client to the network infrastructure.
Other advantages are:
supplier independence – two or more connectivity suppliers can be used for carrier resilience and the
ability to encrypt overlay VPN’s with IPSec allows a wider choice of suppliers;
transport independence – overlay VPN’s are not restricted to particular network connectivity, eg. the
Common DNSP model requires an Ethernet presentation with 802.1Q support. The ability to encrypt
overlay VPN’s with IPSec enables a choice of connectivity options e.g. MPLS, Internet based transport or
a hybrid of both.
security – each tenant can manage their own overlay VPN;
Internet usage policy enforcement - tunneling all traffic from the remote users will also mean Internet
access for remote users will always flow via their home organisation’s Internet connection rather than
using a local guest Internet breakout. This will ensure their Internet usage is subject to their home
organisation’s security and content controls even while working remotely;
speed to deploy – broadband Internet or wireless connectivity can be operational in days versus the
extended lead times on MPLS connectivity;
shorter contracts – broadband and wireless connectivity contracts are typically much shorter than those
of MPLS solutions providing maximum flexibility to the customer.
One disadvantage of the overlay model when compared to the Common DNSP model is the inability of each tenant
to reserve bandwidth on the shared WAN link for their own exclusive use. However, technologies such as
Adaptive QoS for DMVPN or the Intelligent Path Control capability of Intelligent WAN (IWAN) could be deployed to
alleviate application performance issues during periods of congestion.
The foundation of an overlay VPN design is a common transport network which provides connectivity to:
enable tunnel creation between the endpoints in each overlay network,
carry user and device authentication traffic between RADIUS servers, such as Cisco Identity Services
Engine (ISE), at the multi-tenant building and the user’s home network.
For the UK public sector operating at OFFICIAL level, the transport network can be:
an Assured network such as the PSN Shared Services VPN or an equivalent on a Regional PSN;
a suitably configured CPA Foundation Grade IPSec VPN over an unassured network, e.g. Internet;
or a combination of both (hybrid WAN);
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 7 of 31
The choice of transport network is likely to be decided based on the connectivity options available at the location
and the mix of tenants. However, for the majority of sites, a PSN connection into a Shared Services VPN from a
DNSP or Regional PSN is the most likely option as it provides:
assurance to permit OFFICIAL traffic to traverse in the clear;
service level guarantees;
additional security of a closed network;
less complexity compared to an Internet based VPN which requires PKI authentication
However, an Internet based VPN is a good option for:
providing additional bandwidth and/or secondary path to supplement a primary PSN connection;
extending network connectivity into non-public sector buildings to assist with the efficient delivery of
services, e.g. residential care homes where NHS and Local Authority Social Care staff attend regularly;
Providing connectivity for temporary or mobile locations, e.g. ad-hoc vaccination centres during a
pandemic.
Table 2. PSN WAN connectivity compared with Internet based Transport
PSN Shared Services VPN Internet VPN
Assurance PSN Assured None
Security
Limited to PSN members only
No internet access
Data sovereignty guaranteed
Open
Data sovereignty uncontrolled
Service Levels SLA backed Availability SLA only
Quality of Service Supported None
Connectivity Wired Wired & Wireless options
Suppliers Restricted to DNSP’s Unrestricted
As in the Common DNSP model, one tenant will act as the lead-tenant to own the relationship with the transport
connectivity provider(s).
Each tenant is likely to install their own router or firewall into the multi-tenant building to provide VPN connectivity
to their own services. However, it is possible for costs to be reduced further through sharing of VPN routers
between tenants through the use of VRF-Aware VPN technologies such as Dynamic Multipoint VPN technology
(DMVPN).*
* DMVPN is an accreditable encryption solution, as outlined within the PSN Technical Domain Description, as follows:
“An encryption architecture which utilizes mGRE NHRP (including proprietary implementations*) to form dynamic tunnels which adhere to the PSN Cryptographic Framework
(Interim or PRIME, unique key pair per end device and unique traffic encryption keys per security association)” (Cabinet Office: Technical Domain Description).
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 8 of 31
Tenant 1
Tenant 2
Common
Transport
Network
Tenant 1
Overlay VPN
Tenant 2
Overlay VPN
Tenant 1
WAN
Tenant 2
WAN
Figure 3 - Shared WAN Design with Overlay VPN's
Each tenant’s tunnel headend should be placed outside of a firewall at their DC so a security boundary can be
maintained between the remote users and their internal network and enable filtering of traffic from the remote
users.
Cisco’s DMVPN technology offers the simplest, scalable and flexible solution for overlay VPN’s and has been
deployed extensively by UK public sector agencies and suppliers.
DMVPN
Dynamic Multipoint VPN is a Cisco IOS feature that combines standards based protocols, GRE, NHRP and IPSec
together to form a solution that can deliver very large-scale overlay VPN networks with relatively simple
configuration and little operational overhead.
DMVPN is a very flexible technology which can be configured to operate:
In Hub & Spoke or Dynamic Full-Mesh modes;
With or without IPSec encryption;
With static routing, BGP, EIGRP, RIP or OSPF;
With VRF’s;
With Quality of Service (QoS);
With IPv6 as both the payload (IPv6 over IPv4) and/or the underlying transport (IPv6 over IPv6);
With MPLS.
Routers participating in a DMVPN network are classed as “Hubs” or “Spokes”. Hubs are typically placed in the
Data Centers closest to the applications. Hubs have Multipoint GRE (mGRE) interfaces through which they
maintain permanent tunnels and routing adjacencies with each of the spokes. Spokes can be added to a DMVPN
network without requiring any additional configuration on the hub.
In hub and spoke DMVPN deployments, all spoke-to-spoke traffic passes through the hub. But in dynamic full-
mesh deployments, only the first packets in a spoke-to-spoke flow are routed through the hub. The hub reacts to
the first packets in the spoke-to-spoke flow by sending NHRP indirect messages to the spokes which instruct them
to create a dynamic on-demand tunnel. Subsequent packets in the flow are then routed directly between the
spokes via the on-demand dynamic tunnel.
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 9 of 31
Figure 4 - DMVPN Static and Dynamic Tunnels
DMVPN is fully VRF-aware. This allows DMVPN tunnels to be sourced from and attached to VRF’s on a Cisco
router as well as the global/default routing table. Cisco routers can join multiple DMVPN networks with each in a
separate VRF if required. This facilitates the construction of different overlay topologies for each VRF or tenant.
DMVPN can also take advantage of Front VRF (fVRF) and Inside VRF’s (iVRF) which allow the tunnel source
interface and the tunnel interface to be in different VRF’s. The tunnel source interface is placed in the fVRF and
the GRE encapsulation/decapsulation process forms a secure “conduit” through to the tunnel interface placed in an
iVRF. This allows the internet to be used as a tunnel transport network safely as the internet connection is placed
in a separate VRF to the internal corporate networks.
The DMVPN networks for multi-tenant buildings can be deployed in one of two ways:
One DMVPN for each tenant. Each DMVPN can be on a separate router for each tenant or combined
onto a single shared router using VRF-Aware DMVPN. A DMVPN for each tenant allows different overlay
topologies to be created for each tenant and ensures maximum flexibility but increases configuration
complexity as the number of tenants rises.
A single MPLS enabled DMVPN. An MPLS enabled DMVPN reduces the overlay network to a single
DMVPN which is shared by all tenant traffic. Separation of the traffic flows is maintained by MPLS VPNv4
labels applied to the packets on ingress to the router from the iVRF’s. This model requires DMVPN hubs
to be provided centrally so is best suited to a Regional PSN service provided by a single service provider.
The choice of DMVPN per-tenant or MPLSoDMVPN will be determined by the number and type of tenants and the
configuration complexity each additional tenant introduces and the degree of flexibility required in the overlay
topologies.
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 10 of 31
DMVPN per-Tenant
PSN WWW
Tenant 1 DC Tenant 2 DC
MGMT
WLC AAA/ISE
PSN
DMVPN
Router
WWW
DMVPN
Router
PSN
DMVPN
Hub
WWW
DMVPN
Hub
PSN
DMVPN
Hub
WWW
DMVPN
Hub
Firewall Firewall
AAA/ISE AAA/ISE
AAA Proxy
AAA ProxyT1 PSN
DMVPN
T2 PSN
DMVPNT1 WWW
DMVPN
T2 WWW
DMVPN
AAA
DMVPN
CSR1000v
T1 User T2 User T1 User
Shared
SSIDT1 User
T2 User
Figure 5 - Resilient Shared Infrastructure Design with PSN & Internet Transport – VRF-Aware DMVPN per-Tenant
In a DMVPN per-Tenant design, each tenant requires:
A DMVPN overlay. A separate DMVPN will be created for each of the participating organisations to
tunnel their traffic between their remote users and their Data Center. Dual DMVPN’s over two different
transport networks can be used for resilience
DMVPN Hub routers. Each tenant will require one or more DMVPN Hub routers to terminate their own
DMVPN’s. Dual Hubs should be used for resilience and hubs should be placed close to the applications.
One or more DMVPN Spoke routers. The DMVPN routers at the multi-tenant buildings will be spokes in
the DMVPN’s of each tenant. The spoke routers can be dedicated physical devices for each tenant or
shared between tenants with VRF-Aware DMVPN. Traffic between multi-tenant buildings will be carried
via dynamic on-demand tunnels.
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 11 of 31
Dynamic full-mesh DMVPN deployments. The DMVPN’s should be deployed in dynamic full-mesh
mode to support peer-to-peer applications between remote users at different locations on the DMVPN,
e.g. voice/video calls with Cisco Jabber
GRE encapsulation without IPSec protection on Assured transport networks. IPSec encryption of
the DMVPN networks will not be required if the transport network is an assured service appropriate for the
transport of user data classified as OFFICIAL (subject to local accreditor approval). Tunneling across
Assured networks is used as a workaround for the overlapping IP schemes rather than for security
protection purposes.
GRE encapsulation with IPSec protection on unassured transport networks. IPSec tunnel protection
must be enabled on Internet based DMVPN’s in accordance with CPA Foundation Grade IPSec Security
Gateway guidance.
Use of fVRF and iVRF’s. The DMVPN tunnels on each router will be sourced from IP addresses in an
fVRF attached to the transport network. The DMVPN tunnel interfaces will terminate in iVRF’s.
BGP. iBGP Is recommended as the dynamic routing protocol for the DMVPN overlays for its scalability,
stability and flexibility. The hubs should be configured as Route Reflectors and spokes should peer with all
hubs. iBGP is preferred for the hub-spoke peerings as it allows path manipulation easily using local-
preference and weight whereas eBGP requires AS path-prepending or MED.
MPLS over DMVPN
PSN
MPLSoDMVPN
SPOKE1
SPOKE2
SPOKE3
WLC1
WLC2
WLC3
AAA Proxy
HUB1
HUB2WWW
Tenant 1
WAN
Tenant 2
WAN
Tenant n
WAN
AAA
AAA
AAA
Multi-Tenant BuildingsTransport & Overlay
NetworksCentral DC & Authentication Departmental Networks
ASA/ASAv
ASA/ASAv
ASA/ASAv
Figure 6 - Shared Infrastructure Design with PSN & Internet Transport – MPLSoDMVPN
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 12 of 31
An MPLS over DMVPN design requires:
A single DMVPN overlay. A single DMVPN overlay will be created to tunnel the traffic for each of the
participating organisations from the multi-tenant buildings to a central datacenter. Traffic from the multi-
tenant buildings will be aggregated at the central datacenter and forwarded onto the individual tenant
networks, typically using an Option-A interconnect Dual MPLS enabled DMVPN’s over two different
transport networks can be used for resilience
Centralised DMVPN Hub routers. The MPLS enabled DMVPN will require hubs located in the central
datacenter. Dual Hubs should be used for resilience.
One or more DMVPN Spoke routers. The DMVPN routers at the multi-tenant buildings will be spokes in
the MPLS enabled DMVPN. All tenants will share the DMVPN routers and their traffic will remain
separated by VRF’s.
Dynamic full-mesh DMVPN deployments. The DMVPN should be deployed in dynamic full-mesh mode
to support peer-to-peer applications between remote users at different locations on the DMVPN, e.g.
voice/video calls with Cisco Jabber. Traffic between multi-tenant buildings will be MPLS switched over
dynamic on-demand tunnels. MPLS enabled dynamic tunnels are supported from IOS-XE 3.12S and IOS
15.4(2)T
GRE encapsulation without IPSec protection on Assured transport networks. IPSec encryption of
the DMVPN network will not be required if the transport network is an assured service appropriate for the
transport of user data classified as OFFICIAL (subject to local accreditor approval). Tunneling across
Assured networks is used as a workaround for the overlapping IP schemes rather than for security
protection purposes.
GRE encapsulation with IPSec protection on unassured transport networks. IPSec tunnel protection
must be enabled on Internet based DMVPN’s in accordance with CPA Foundation Grade IPSec Security
Gateway guidance.
Use of Global Routing Table and iVRF’s. In an MPLS enabled DMVPN, the tunnels MUST be sourced
from and terminated in the Global Routing table in order for BGP VPNv4 next-hop resolution to work
correctly. All customer facing interfaces, ie. the tenant VLAN’s are placed in iVRF’s
Multi-Protocol BGP (MP-BGP). MP-BGP with VPNv4 SAFI is the only dynamic routing protocol
permitted on the MPLS enabled DMVPN overlay although IGP’s can be run within the iVRF’s and
redistributed into MP-BGP just as in a normal MPLS L3VPN network. The hubs should be configured as
VPNv4 Route Reflectors and spokes should peer with all hubs.
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 13 of 31
IPSec Requirements
Internet Based DMVPN must use one of the following CESG approved IPSec profiles. At time of writing, the
guidance1 states:
Foundation profile is suitable for protection of OFFICIAL until 31st December 2021. This will be reviewed
on an annual basis
The use of “PSN Interim” profile is acceptable only until 31st December 2018
All VPN deployments should migrate to Foundation or End-State PRIME by 1st January 2018
Table 3. CESG Foundation and PRIME cipher suites
Algorithm Foundation End-State PRIME
Encryption ESP AES-CBC 128 AES-GCM 128
Key Exchange IKEv1 IKEv2
Hash HMAC-SHA256-128 HMAC-SHA256-128
Diffe-Hellman Group 14 Group 19
Authentication RSA X.509v3 ECDSA 256bit X.509v3
Certificate Enrollment/Re-Enrollment SCEP EST
Performance data for the ISR4000, ISR G2, ASR1000 and selected 800 series models using the Foundation profile
are available under a non-disclosure agreement (NDA). Please contact your Cisco Account Manager for further
details.
1 CESG document – Network Encryption at OFFICIAL v2.3
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 14 of 31
Software Defined-WAN (SD-WAN) – Cisco Intelligent WAN (IWAN)
Cisco’s Software Defined WAN (SD-WAN) solution is called Intelligent WAN (IWAN) and it enables customers to
augment their provider networks with alternative WAN transport services like Internet or mobile to build a hybrid
WAN architecture, and even offload public cloud traffic with Direct Internet Access.
Context-aware routing features like application visibility and intelligent path control help ensure the best user
experience. The transport path to the Data Centre via the Internet is secured using IPsec network encryption
technology – DMVPN, so the end-to-end delivery is secured. Cisco’s Access Routing platforms have been assured
via Commercial Product Assurance (CPA) Foundation Grade for IPsec VPN.
Application Visibility – includes uses a form of Stateful Deep Packet Inspection called NBAR2 to identify
and classify applications as they traverse the network and Performance Monitor which collects and
reports performance metrics of the applications
o NBAR2 is invaluable as it is no longer practical or possible to classify applications based on
Access Control Lists (ACL’s) any longer because:
the applications are moving to the cloud so the destination IP address is variable.
applications are all standardising on HTTP/S for transport. Distinguishing between
business critical applications and web browsing is no longer possible using L4 port
information alone. Application Visibility when combined with QoS mechanisms can
ensure business critical web or cloud-based applications have priority over web
browsing or guest Internet traffic across the network.
o Performance Monitor – is embedded into the router and:
collects performance metrics such as bandwidth usage, response time and latency of
TCP applications and jitter, delay, latency and loss of RTP applications such as voice
can export the performance data to external management platforms in NetFlow v9 or
IPFIX formats for use in capacity management or traffic analysis reporting
Intelligent Path Control – is based on Performance Routing v3.
o PfRv3 uses the application classification and realtime performance data provided by NBAR2 and
Performance Monitor to dynamically adjust the routing of individual applications to ensure their
performance requirements are met. This is different to standard routing based on the
reachability and metrics of destination network prefixes, e.g. with PfRv3 a voice call may be
rerouted because delay, jitter or packet loss on the primary path are causing a degradation in call
quality even though the primary network path is still available. With standard routing, as long as
the primary path was available the voice calls would continue to use it and call quality would
suffer
o PfRv3 also load-shares by default, i.e. it actively tries to maintain an equal split of traffic across
all links. So for tenants paying for resilient links into a multi-tenant building, instead of having
one link idle, both links are actively forwarding traffic.
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 15 of 31
A Hybrid WAN Architecture focused on Users Needs
A hybrid WAN architecture is a mixture of both provider services and other alternative transport methods like the
Internet or mobile networks.
Private
Cloud
Public
Cloud
Virtual
Private
Cloud
MPLS
WWW
Cisco Cloud
Web Security
Branch
Hybrid WAN
Transport
(DMVPN)
Direct Internet
Access
Figure 7 - Hybrid WAN Architecture
A hybrid approach allows:
WAN bandwidth capacity to be added at significantly lower cost than MPLS
Improved performance of business critical applications by offloading internet and non-business critical
applications from the MPLS service onto the secure Internet path
Intelligent load-sharing of traffic across the MPLS and Internet paths so both paths are utilised
Improved availability of branch sites through dual WAN links and/or dual CPE routers
Improved performance of cloud-based applications by allowing branch users to access them directly via
the local internet connection versus tromboning through a central DC
The introduction of new services such as guest or citizen internet access
It is imperative that the WAN service characteristics match the user’s needs, so the following technical
considerations should be noted when considering Internet based transport.
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 16 of 31
Table 4. Internet based Transport Considerations
Advantages of Internet Transport Technical Considerations
Lower cost compared with, for example, a Multi-Protocol Label
Switching (MPLS) IP VPN service.
Speed and quality of the Internet connection. In general, quality has
increased but there are still large discrepancies in speed and reach.
Simple to transfer Service Providers (SP). Works over an Internet
connection so not tied to a single SP and can easily roam out of
region.
Maintenance contract on Internet connections. Most private networks
have very high SLAs associated with line and equipment fix. Typically
even with business Internet connections this is lower than when using a
private network particularly on line fixes.
Availability good enough particularly for sites that need
reasonably low speed.
Service SLAs. Private networks usually offer delay and packet loss on
a per QoS basis. Internet services typically don’t offer QoS and will not
offer any on-going guarantee associated with packet loss or end to end
delay.
DIA from the branch offers optimal traffic flows for users. Cloud
Service adoption is on the increase, so many businesses are
looking at local Internet breakout at the branch office to offer
optimised on-premise and cloud hosted solutions.
Ensure that the VPN created over the Internet is encrypted to the right
level for the organisation.
How will the data-in-transit security be applied without an Assured
underlying transport? CPA Foundation Grade?
Could deploy for example, MPLS as primary and Internet as
backup to take a risk averse approach and lower costs.
Internet based threats and DoS attacks - Increased number of Internet
PoPs at the branch opens up the scale of Internet threats significantly.
Many points of control versus a smaller number of controlled and
monitored Internet Gateways.
Easy for SMEs to provide. Lose control over traffic flow and predictability - Internet connections
are often asymmetrical in nature which may impact some sites. Internet
traffic can also be asymmetrical in nature.
Cheaper services mean more sites may opt for dual-links. IWAN
may offer greater service resilience and application performance.
Limited (or no) QoS and impact on voice and video calls.
Faster provisioning from the SP’s, e.g. 10 days for Fibre to the
Cabinet (FTTC) Internet versus > 60 working days for L3VPN.
Place additional pressure on Core SP Networks - heightened during
Emergency Response Incidents.
Sites can be carrier independent. Data Sovereignty - some UK Internet traffic may route via other
countries - limited control.
Shorter contracts available vs Managed WAN. Cheap copper/fibre-based services will be delivered from the same
serving telephone exchange so true resilience/ carrier diversity requires
a circuit (e.g. fibre) to another PoP.
Protection from DDoS attacks through obscurity. On their DIA
connections, the branch sites only require a single public IP
address which would typically be supplied by DHCP from the
ISP’s address range. Providing the IP is not registered in DNS,
the identity of the branch site would be hidden from attackers.
Branches using DIA to access cloud applications could still be
working even if the organisation’s central internet connection was
experiencing an outage or DDoS attack.
Multicast and IPv6 support is lacking or non-existent on native
broadband.
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 17 of 31
Shared Workplace Network Designs
Shared Wireless SSID and Wired LAN
The shared workplace infrastructure relies on the creation of a new common SSID (e.g. GovRoam), which allows
all users in the multi-tenant buildings to connect automatically and follow the process of 802.1 x authentication
using EAP-TLS mutual authentication methods. Utilising these methods ensures that the connection is seamless to
the user, a secure connection to the wireless network is established and there is no requirement for captive portals.
Once authenticated, wireless and wired users will be dynamically placed onto a VLAN dedicated to their
organisation from where they will be able to reach shared resources and also their organisation’s wider network via
an overlay VPN or Common DNSP WAN connection.
When compared to broadcasting the SSID of each tenant’s corporate network at every site, creating a single
shared SSID has the following advantages.
Table 5. Shared SSID advantages
Shared SSID Distributed SSID’s
Manageability
Two Wi-Fi profiles to manage on End-User Device
One additional SSID to configure and advertise
One SSID per-tenant may exceed guidance of 4
SSID’s per-AP which prevents management
traffic impacting on bandwidth available for user
traffic
Scalability One SSID to configure and advertise One SSID per-tenant may exceed guidance of 4
SSID’s per-AP
Simplicity User education required No change for users
At small sites, a single VLAN per-tenant may be sufficient to accommodate wireless and wired users and each
VLAN can be trunked or bridged to the WAN router which provides L3 services. However, at large sites with
potentially hundreds of users from each tenant, a single VLAN would create a prohibitively large broadcast domain.
In this case, multiple VLAN’s should be created for each tenant in conjunction with VRF-lite on the LAN switches
and the traffic routed to the WAN router. Users can be spread over the VLAN’s based on the switch or wireless
access point to which they are connecting. This will be controlled by the user and device policy management
server (Identity Services Engine - ISE).
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 18 of 31
Wireless Coverage
If each department procured their wireless LAN infrastructure independently, there could be a number of
challenges with regards to RF coverage, interference and roaming, especially, if a common SSID is advertised at
both locations.
Consider a multi-floor building, with Tenant ‘1’ on floor 1, and Tenant ‘2’ on floor 2.
Tenant 2 – Wireless Management LAN
Tenant 2
WLC
Tenant 2 RF Roaming Domain
Tenant 1 – Wireless Management LAN
Tenant 1
WLC
Tenant 1 RF Roaming Domain
Tenant 2 Occupied Floor
Tenant 1 Occupied Floor
Shared Area /
Canteen, etc
Shared Area /
Canteen, etc
Common
SSID
Common
SSID
Common
SSID
Common
SSID
Common
SSID
Common
SSID
Common
SSID
Common
SSID
Common
SSID
Common
SSID
Common
SSID
Common
SSID
Tenant 1
User
Figure 8 – RF coverage, interference and roaming
If the same common SSID were advertised in both departments wireless architecture, a visiting trusted user
connected to the wireless within Tenant 1 on the first floor may potentially have visibility of the same SSID
advertised by Tenant 2 on the second floor.
As it is the decision of the client as to when it roams, there is always a potential for the trusted visiting client to
inadvertently roam onto the Tenant 2 advertised SSID, that will certainly impact upon the user experience. As
these two wireless implementations are discreet systems with no RF roaming capability or interaction, this would
be a hard roam for the client, resulting in a complete new 802.1x authentication, new IP address and potentially
new or different user policies, as per the local department security policy. This will cause delay, disruption and
impact upon any connections that client may have established, impacting upon the user experience.
Equally, the two systems may see each other as ‘Rogue’ networks, advertising the same SSID as their own
implementation, thus creating alarms. Also, they will both be attempting to utilise the same channel allocation,
potentially causing co-channel interference.
Therefore, strong consideration should be given in this scenario to the RF bleed between floors and the potential
for the impact to the user experience.
There are a number of features in the Cisco wireless LAN controller that may assist in mitigating this scenario,
such as turning off lower data rates, utilising Radio Resource Management (RRM) features to control the transmit
and channel allocation, optimised roaming feature, RX-SOP features, High Density Experience (HDX), clientlink
etc… but these are no substitute for an on-site RF survey, together with appropriate positioning and number of
access points.
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 19 of 31
Network Separation
Many questions arise around the connectivity of wireless LAN access points direct to the ‘OFFICIAL’ infrastructure.
It is good commercial practice to connect the wireless Access Points (AP) directly to the corporate infrastructure,
and indeed there are departments that have adopted this approach, either as a result of legacy deployments or due
to budget constraints during the design stages, avoiding separate infrastructure, but it is the most commonly
deployed method.
In evaluating your departments’ business need for wireless LAN connectivity, the risk mitigating factors should be
understood to ensure that it is acceptable for your department to attach AP’s directly to your trusted environment.
The diagram below attempts to outline some areas that could be considered in this approach. Other areas to
consider may be the type of traffic you are carrying over the wireless connections, such as corporate only, or
corporate plus trusted visitor or potentially the addition of open guest access.
WLC
Switch
Access
Point
Encrypted Control
CAPWAP tunnel
(FlexConnect or
Central Mode)
Data CAPWAP tunnel
(optional DTLS
encryption for Central
mode)
Data Traffic, local
drop off at switch
(FlexConnect)
Tunneling Options:-
CAPWAP DTLS from AP to WLC for
control traffic for both Central mode and
FlexConnect mode
CAPWAP from AP to WLC for Data
traffic – termination direct to WLC for
data traffic termination in central mode
Data traffic from AP to switch for
FlexConnect local traffic only
CAPWAP termination at directly
connected Catalyst switch for
Converged Access only
Optional DTLS for data traffic
Switchport Connectivity Options:-
Authenticate access point to
infrastructure using 802.1x for access
point to switch
Authenticate access point to wireless
controller using simple user name
password
Authenticate the access point to
controller using certificates
Options:-
Mutual Authentication
WPA2 AES encryption
EAP-TLS authentication
Backend RADIUS / PKI
(optional) Client VPN overlay – traffic
encrypted, what about management
frames?
PMF – Protected Management Frame
Wireless Risk?
Rogue Device detection
Noise source / interferer detection
Wireless Intrusion Prevention
Location tracking
Allow access from identified locations
only
Figure 9 – Network Separation Considerations
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 20 of 31
Network Access Control (NAC)
Client network access control (NAC) can be enforced on wireless and wired LAN infrastructure via 802.1x
authentication using Cisco Identity Services Engine (ISE), which will authenticate and authorise the client upon
connectivity to the network. ISE provides a granular level of control e.g. allow the client to only connect when at a
certain location, time of day, using only Apple devices and based upon being a member or an Active Directory
group. An access control list can be pushed to the edge to enforce connectivity for that client session, which will
only allow access to identified resources or internet only traffic.
The client device would utilise 802.1x mutual authentication against department RADIUS servers, utilising EAP-
TLS and department PKI digital certificates, thus ensuring confidentiality and integrity for the wireless connection.
Upon completion, the wireless session will be secured with a WPA2 AES encrypted session on a per-client/per-
session basis between client and access point. If adopting a local mode termination of data traffic, all client traffic
will be encapsulated within a CAPWAP tunnel to the controller, where this traffic will terminate. Optionally, the
CAPWAP data traffic can be enhanced with DTLS encryption, although it is assumed that this tunnel will be over a
trusted environment at this point anyway.
Wired 802.1x Solution Overview
IEEE 802.1X provides an authentication mechanism to devices wishing to attach to a wired or wireless LANs. It
involves three components: an authenticator, an authentication server and a supplicant.
Client
(Supplicant)
VoIP
(Supplicant)
Switch
(Authenticator)
Radius
(Authentication Server)
802.1X RADIUS
802.1X RADIUS
Figure 10 – Solution Components Overview
Authenticator
The authenticator is the switch that controls physical access to the network based on the authentication status of
the supplicant. The authenticator acts as an intermediary (proxy) between the supplicant and the authentication
server. The authenticator requests identity information from the supplicant via 802.1X, verifies that information with
the authentication server via RADIUS, and then relays a response to the supplicant based on the response from
the authentication server.
Authentication Server
The authentication server performs the actual authentication of the supplicant. By examining the information in the
encapsulated EAP messages relayed from the authenticator, the authentication server validates the identity of the
supplicant and notifies the switch whether or not the supplicant is authorised to access the LAN.
The user database is where user credentials used in 802.1X authentications are stored. This function can be
integrated into the authentication server or it can be an external server (i.e LDAP) to which the authentication
server has access.
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 21 of 31
Supplicant
A supplicant is an 802.1X client that runs on an edge device (workstation, laptop, phone). The job of the supplicant
is to request access to the LAN and respond to requests from the authenticator (the switch). The supplicant
communicates with the authenticator via 802.1X-encapsulated EAP packets its credential. Examples of IEEE
802.1X-compliant supplicant software include the Cisco AnyConnect Secure Mobility Client or the build-in
supplicant within Cisco IP Phones.
Wired 802.1x Data & Voice Design Considerations
Multi-Domain Authentication (MDA)
Multi-Domain Authentication (MDA) host mode is a feature that allows a Cisco switch to modify the default IEEE
802.1X requirement that only a single device can connect to a switch port while retaining the security and visibility
that IEEE 802.1X provides.
When properly enabled for MDA, the switch divides the switch port into two virtual “domains” (a domain is
equivalent to a VLAN on a wired network). The switch independently and asynchronously authenticates the phone
and the device behind the phone. When the phone authenticates successfully, it is given access to the voice
domain. When the device behind the phone is authorised, it is given access to the data domain.
Mac Authentication Bypass (MAB)
One of the challenges linked to any 802.1x implementation is related to agent less devices or devices that haven’t
been provisioned or configured with the needed credentials to authenticate to the network.
MAB initiates only after an 802.1x timeout. MAB would then require a variable amount of time to learn the MAC
address of the end station. It has to wait until the device try to send some traffic to the network in order for the
switch to learn its MAC address. Once this has occurred, a RADIUS exchange is initiated to the backend server
asking whether the MAC address should be allowed network access.
Web Authentication
WebAuth enables a Cisco Catalyst switch to check a user’s credentials submitted through a web login portal on the
switch.
Inaccessible Authentication Bypass
If an IEEE 802.1x authentication fails because the AAA server is unavailable, the switch can be configured to allow
clients access to a special VLAN (sometimes called the “Critical VLAN”) that provides configurable access to the
network. The Critical VLAN can be any VLAN except for the voice VLAN.
Inaccessible Authentication Bypass for Voice
Inaccesible Authentication Bypass for Voice feature will authorise the switch to accept tagged traffic with the voice
Vlan on the port and will place the device in the configured voice Vlan of the port in case the AAA are down.
Open Authentication (Silent Run)
By default, IEEE 802.1X drops all traffic prior to a successful IEEE 802.1X (or MAB) authentication or WebAuth
initialisation. This is sometimes referred to as closed mode (enforce mode or active mode). Cisco switches can be
configured for open-access mode, which allows all traffic (in both the data and voice VLANs) prior to successful
authentication.
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 22 of 31
Access by user enrolment (Guest Wireless Overlay Model)
In addition to the shared SSID, guest wireless LAN access will be required for visiting users who:
are trusted visitors from public sector organisations that are not participants in the shared infrastructure
service;
are untrusted users (guests).
Guest network deployments generally consist of an open network SSID, thus DNS / DHCP would need to be
controlled to allow wireless client connectivity.
Once connected the guest wireless user will be challenged via a web authentication page to control the guest
user’s access. User authentication, authorisation and network policies can be simplified by the use of Cisco Identity
Services Engine (ISE) with the controller conducting Central Web Authentication.
A tailored portal on a per-department or on a per-site location can be presented to the guest user for access into
the guest network. A series of criteria can be defined in ISE to be entered by the guest and captured within ISE, as
well as accepting the Acceptable Use Policy (AUP) before they are successfully allowed access.
ISE has the flexibility to allow users self-registration; self-registration with pin access (e.g. user creates a username
/ password, but must still obtain a pin code from reception for example); self-registration with sponsor approval and
sponsored guest access, each of which can be sent to the user via email, sms or print.
Upon completion of authentication, the authorisation profile can be used based upon client location; time of day;
how they are connecting; what type of device it is; or who they are, allowing a policy to be defined centrally in ISE
to control network access at the edge. For example, you only want apple devices, connected in the shared area
location to gain network access during 9am to 5pm weekdays, and to the Internet only.
For ensuring that the guest traffic is logically separate and non-reachable or routable from the corporate
infrastructure, the most commonly deploy architecture is to adopt a guest anchor wireless controller in an Internet
DMZ. All guest traffic in this instance will be tunnelled from the access point the central controller, then immediately
encapsulated within a tunnel from this controller to a DMZ based controller where this traffic will terminate. At no
point is the guest traffic within exposed to the corporate network, as such the point of presence from a network
perspective will be within the DMZ. This also allows additional controls to be placed upon this traffic at a single
central location, instead of many distributed touch points across the network. It also allows a single point for any
additional monitoring or logging of traffic as necessary.
To ensure your corporate traffic is not affected by bandwidth utilisation of the guest traffic on the wireless network,
there are measures that can be taken in the controller to ensure air time fairness of corporate SSID over guest
SSID, together with steps such as rate limiting and utilising application visibility and control to prioritise applications
or drop others.
For information around the different types of web authentication available via the wireless LAN controller, please
refer to the following document:
http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wlan-security/115951-web-auth-wlc-guide-00.html
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 23 of 31
IP Addressing
As there will be no direct routing between the VLAN’s of the different tenants, the IP subnets to be used to address
the devices on each VLAN should be supplied from each tenant’s own internal addressing schemes. This avoids
the complexity of having to find an RFC1918 address range which is unique across all tenants.
DHCP & DHCP Relay
Once an authenticated user has been placed onto the appropriate VLAN, the user’s device will attempt to obtain an
IP address via DHCP.
At smaller sites, the WAN router can provide DHCP service by either:
Running a vrf-aware IOS DHCP server to offer IP configuration locally;
Running DHCP Relay on the VLAN sub-interface to unicast the DHCP request to a central DHCP server
at the user’s home network via the DMVPN.
At larger sites, DHCP can be offered by either:
Local DHCP server(s);Running IP-Helper on the SVI interfaces of the LAN switches to unicast the DHCP
request to a central DHCP server at the user’s home network via the WAN router.
IPv6
Dual-stack is the preferred, most versatile way to deploy IPv6 in existing IPv4 environments. IPv6 can be enabled
wherever IPv4 is enabled along with the associated features required to make IPv6 routable, highly available, and
secure.
The primary advantages of dual-stack are that it does not require tunneling over the IPv4 networks and offers
processing performance advantages because packets are natively forwarded without having to account for
additional encapsulation and lookup overhead.
However, there is an associated increase in overall network utilization and workload that derives from transmitting
and processing control traffic generated by the IPv4 and IPv6 protocols simultaneously. IPv6 can also increase the
memory utilization on network devices from maintaining neighbor tables if devices are using multiple IPv6
addresses on the same interface.
In a shared building, a dual-stack deployment would allow tenants to move to IPv6 at their own pace as the IPv6
features can be enabled on their LAN interfaces and WAN devices independently of the other tenants.
The most important consideration is to ensure that any devices which are deployed in the network such as
switches have support for IPv6 in hardware.
The Dual-Stack model requires IPv6 support across the entire network from end-to-end.
IPv6 is supported by DMVPN in:
IPv6 over IPv4 transport
IPv6 over native IPv6 transport
EIGRP supports IPv6 in VRF-Lite configurations in Named configurations only.
OSPFv3 supports VRF-Lite
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 24 of 31
Table 6. IPv6 supported products
Component IPv6 Support Notes
Overlay VPN - DMVPN Yes IPv6oIPv4 & IPv6oIPv6
Overlay VPN - IWAN No PfRv3 does not support IPv6 currently
Identity Services Engine Yes
Catalyst 2960-X Yes
Catalyst 3650 Yes
Catalyst 3850 Yes
Catalyst 4500E Yes With Sup7E
Catalyst 4500X Yes
Catalyst 6500 Yes
Catalyst 6800 Yes
ISR4000 Yes
ASR1000 Yes
AnyConnect Secure Mobility Client Yes SSL VPN Only currently
2500 WLC Yes
5520 WLC Yes
8540 WLC Yes
http://www.cisco.com/c/en/us/solutions/industries/government/global-government-certifications/ipv6-certified-
list.html
IPv6 address allocation to hosts on the tenant VLAN’s can be assigned via Stateless Address Autoconfiguration
(SLAAC), static assignment or DHCPv6. DHCPv6 assignment is likely to be the predominant method and just as in
the IPv4 address assignment section earlier, DHCPv6 addresses can be delivered locally by the WAN router or
from a remote DHCPv6 server using DHCPv6 Relay.
SLAAC may be preferred if the end devices (such as older Apple products) do not have support for DHCPv6.
/64—On Tenant VLAN interfaces, it is recommended to use a /64 prefix because it is easy and consistent for
address management and a /64 is assumed for correct operation of SLAAC, SEND, and privacy extension use.
Although IPv6 does not use broadcasts and a /64 can have billions of hosts attached, it is still good practice to limit
the Tenant VLAN’s in the same way as would be done for IPv4 subnets.
IPv6 should operate correctly over WLAN access points in much the same way as IPv6 operates over Layer 2
switches.
Cisco supports the use of IPv6-enabled hosts that are directly attached to Cisco IP Phone ports, which are switch
ports and operate in much the same way as plugging the host directly into a Catalyst Layer 2 switch.
TrustSec
Cisco TrustSec provides an alternative mechanism for segmenting users on a shared network and will offer greater
scalability and operational simplicity when compared to allocating VLAN’s for each tenant organisation.
With TrustSec, instead of assigning users to specific VLAN’s as they authenticate onto the network, they
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 25 of 31
are assigned to Security Groups. Once assigned to a Security Group, each user’s traffic is marked with a
Security Group Tag (SGT) which are then used throughout the network to enforce security using Security
Group Access Control Lists (SGACL’s). SGT’s provide segmentation on a per-user level over shared
LAN’s, WLAN’s and VPN networks and simplify the application of security by divorcing security policy
from static elements such as IP addresses, subnets and VLAN’s.
At the WAN router, if SGT’s are used instead of VLAN’s, user traffic can be mapped to the correct iVRF
and WAN using SGT Based Policy Based Routing (PBR). SGT Based PBR will route packets into VRF’s
based on their SGT marking. This simplifies the network by eliminating the need to trunk multiple VLAN’s
to the WAN router or creating a L3 interface for each tenant.
One disadvantage to using TrustSec in a multi-tenant building, is the IP addressing of the shared subnets
at the multi-tenant building would need to be unique across all the tenant’s wider networks to avoid
overlaps or clashes with the tenant’s internal subnets.
Cisco has submitted the Source-Group Exchange Protocol (SXP) to the IETF as an Internet Draft. SXP is
a control plane protocol, which carries SGT to IP address bindings throughout the network and is
fundamental to the operation of TrustSec. Cisco has also made available an open source SXP
implementation for other vendors to utilize and also submitted the data plane method of carrying Source
Group Tags on Ethernet to the IETF.
Access to Shared Resources
Two possible approaches to accessing shared resources from the VLAN’s are detailed below.
Remote User VLAN’s
DMVPN Router with IOS Firewall
PSN WWW
Shared Resources LAN
Figure 11 – IOS-XE Zone-Based Firewall for Inter-VRF Routing
PSN WWW
Shared Resources LAN
DMVPN Router
Remote User VLAN’s
Figure 12 - Dedicated Firewall for Inter-VLAN Routing
Use a dedicated firewall to provide
routing and filtering between the
Remote User VLAN’s and the Shared
Resources VLAN.
The DMVPN router can use ICMP
redirects to send traffic for shared
resources to the firewall.
Or use static NAT for shared resources
so the devices appear on the Remote
User VLAN’s.
This solution is best suited to larger
locations.
Place the shared resources into their
own iVRF.
Use the Zone-Based Firewall in the
IOS-XE router to provide routing and
filtering between the tenant iVRF’s and
the Shared Resources iVRF.
This solution is best suited to smaller
locations.
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 26 of 31
Integration & Interoperability
Federated RADIUS Authentication Proxy Service
Authentication of users onto the shared SSID and wired LAN is ultimately performed by a RADIUS server located
within the user’s “home” network. This allows each organisation to maintain control and monitoring of users
accessing their network and avoids reliance on a third-party. The WLC’s and switches providing access to the
shared infrastructure service send authentication requests to a local RADIUS server within the multi-tenant building
in the first instance. The local RADIUS server uses the domain name or realm included in the user’s credentials to
identify if the user can be authenticated locally or if the request should be forwarded to the central RADIUS proxy
servers. The central RADIUS proxy servers also use the domain name in the user’s credentials to identify the
RADIUS server to forward the request to. The internal RADIUS servers and central RADIUS proxy servers must
have connectivity over the transport network to facilitate the proxy operation.
Cisco Identity Services Engine (ISE) can support up to 50 separate Active Directory domain servers if required, or
be used as the Federated Radius server, for multiple government departments. Equally, the ISE server can forward
RADIUS request from the local department site and if required, depending upon the RADIUS method deployed,
can strip both the prefix or suffix realm from the RADIUS request and direct to a federated system to authenticate
against the home network RADIUS.
When the RADIUS Accept messages are returned to the local RADIUS server via the proxy, the local RADIUS will
perform dynamic VLAN assignments by injecting RADIUS attributes (IETF64, IETF65 and IETF81) into the
RADIUS Accept messages before forwarding them to the WLC or access switch. This ensures each tenant’s
VLAN’s are only locally significant to the shared LAN infrastructure within the multi-tenant building.
Each multi-tenant building will require a standard VLAN mapping to be created for the tenant organisations.
Table 7. Example of Tenant VLAN mapping
Organisation Tenant VLAN
Tenant 1 10
Tenant 2 20
Tenant 3 30
Tenant 4 40
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 27 of 31
Transport
Tenant 1 DC Tenant 2 DC
MGMT
WLC
AAA/ISE
DMVPN
Spoke
Router
T1
DMVPN
Hub
T2
DMVPN
Hub
Firewall Firewall
AAA/ISE AAA/ISE
AAA Proxy
T1
DMVPN
T2
DMVPN
MGMT
Access
Switch
T1 User
T2 User
Shared
SSIDT1 User
T2 User
1
2
3
4
5
6
Radius Accept plus the following attributes:
IETF 64 (Tunnel Type) = VLAN
IETF 65 (Tunnel Medium Type) = 802
IETF 81 (Tunnel Private Group ID) = VLAN ID eg. 10 for Tenant 1 Figure 13 - Authentication Flow and Dynamic VLAN Assignment
Authentication Workflow
1) Radius authentication request message from WLC or access switch sent to local Radius server
2) Local Radius cannot authenticate user from its own local user list so forwards the authentication request
to the Federated Radius Proxy
3) Radius Proxy forwards the authentication request to the user’s home Radius server
4) User’s home Radius server authenticates the user and responds to the Proxy with Radius Accept
message
5) Proxy forwards the Radius Accept to the Radius server at the shared building
6) Local Radius server performs dynamic VLAN assignment by injecting Radius attributes into the Radius
Accept message before forwarding it onto the WLC or access switch
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 28 of 31
Change of Authorisation (CoA) – RFC 5176
The standard RADIUS authentication and authorisation process typically uses a “pull” model, in which the requests
originate from a network device and a response is sent from the queried RADIUS servers. RADIUS CoA requests
defined in RFC 5176 are used in a “push” model, in which external servers can request network devices to initiate
or re-initiate the authorisation process. This mechanism allows RADIUS servers to dynamically update the policy
applied to individual sessions after they have been authenticated, e.g. moving a user to a quarantine VLAN or
terminating their session in response to the detection of suspicious behaviour. Wired and wireless LAN equipment
with support for CoA / RFC5176 should be deployed at multi-tenant buildings.
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 29 of 31
Direct Internet Access (DIA) In some scenarios, organisations may prefer their remote users to have Internet access from a local connection at
the multi-tenant building rather than backhaul the traffic over the WAN network to their central Browser Internet
Gateway. This approach can benefit the user experience by:
providing a more efficient path for accessing public cloud-based applications;
preserving bandwidth on PSN MPLS links for the most critical centrally delivered applications.
At sites with local Internet connections, the WAN router can offer direct Internet access to these users by using the
IOS Zone-Based Firewall to:
route packets from the tenant iVRF’s to the shared Internet fVRF;
perform NAT or PAT of outbound internet traffic from the internal RFC 1918 addresses to a public
address;
provide stateful inspection of outbound traffic and enforce a policy that only allows:
o inbound traffic in response to sessions initiated by internal users;
o the protocols required for DMVPN tunnel establishment.
(optionally) provide content scanning of HTTP and secure HTTP (HTTPS) traffic and malware protection
services to web traffic by transparently redirecting HTTP and HTTPS traffic to the Cisco Web Security
cloud;
(optionally) provide caching and pre-positioning of web-based content which preserves internet bandwidth
and improves performance by serving content locally using Cisco WAAS and Akamai Connect features.
Note: – Cloud Web Security, WAAS and Akamai Connect require the addressing in each iVRF to be non-
overlapping for correct operation with VRF’s.
Tenant VLAN
DMVPN Router with
IOS Firewall
PSN WWW
Primary WAN
- to central DC -
DMVPN Backup
- to central DC -
Internet & VPN
Tunnel Traffic
Figure 14 – Direct Internet Access Schematic
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 30 of 31
Solution Components
Table 8. Available platforms for high-density, large campus2
Component Enterprise Mission Critical Best In-Class
Overlay VPN DMVPN iWAN Base
(DMVPN & PfRv3)
iWAN Advanced
(Base + AVC & WAAS/AKC)
WAN Router ISR4000 ISR4000 / ASR1000 ISR4000 / ASR1000
Wireless LAN Controller 8500 or 5500 (AireOS) 8500 or 5500 (AireOS) 8500 or 5500 (AireOS)
Access Points 1700 2700 3700
Access Switches Catalyst 2960X Catalyst 3650,3850 & 6800IA Catalyst 4500E & 6800IA
Distribution Switches Catalyst 3850 Catalyst 6880-X Catalyst 6807-XL Sup-2T
Core Switches Catalyst 6800 Catalyst 6800 Catalyst 6800
Authentication ISE ISE ISE
802.1X Supplicant AnyConnect Secure Mobility Client AnyConnect Secure Mobility Client AnyConnect Secure Mobility Client
Management Prime Infrastructure 3.0 Prime Infrastructure 3.0 Prime Infrastructure 3.0
2 From Cisco Campus LAN and Wireless LAN Design Summary, October 2015
© 2016 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public. Page 31 of 31
Q&A
Q. Can the service expand to accommodate additional members?
A. Yes. Each new participant will require a new Remote User VLAN, iVRF and DMVPN overlay network in
addition to configuration required to make their internal AAA server reachable from the central AAA proxy
Q. What ISR/ASR models and software are suitable for DMVPN?
A. The ASR1000, ISR G2, ISR 4000 and selected 800 series models support DMVPN. DMVPN requires the
Security feature license
Q. What ISR/ASR models and software are suitable for MPLS over DMVPN?
A. For MPLS support on the ISR range, the AppX and Security feature licenses are required. The AX bundles
will support MPLS over DMVPN. On the ASR1000, the Security or VPN feature license is required.
For More Information
We would welcome the opportunity to discuss secure mobility solutions with you and to review the contents within
this guide. Please contact your Cisco Account Manager to discuss your requirements in more detail. Alternatively
read more about Cisco DMVPN, ISE or Mobility via www.cisco.com.
Author
This document and the solutions contained within are the work of Lee Davies, a Systems Engineer within the UK &
Ireland Public Sector team. In his role, he has worked extensively across the public sector in Wales and with UK
PSN Connectivity Service Providers. The concepts outlined in this document were initially developed with Welsh
local authorities and health boards in response to a requirement for social care employees to work jointly and
cooperatively within each other’s buildings.
Disclamier
Although the author has attempted to provide accurate information throughout this document, Cisco assumes no
responsibility for the accuracy of the information. Cisco may change the programs or products mentioned at any
time without notice. Mention of non-Cisco products or services is for information purposes only and constitutes
neither an endorsement nor a recommendation.
Printed in USA CXX-XXXXXX-XX 20/20