Introducing SteelConnect
This topic provides an overview of SteelConnect. It includes these sections:
Overview
Browser support
Network service architecture
SD-WAN controller overview
Secure overlay tunnels
Overview
SteelConnect provides on-premises or cloud-based management system software for SD-WAN gateways, WiFi access points, and Ethernet switches. It connects your entire company using a new approach for managing your network. Instead of opening a box, figuring out how to log in to whatever complex product is inside, and then trying to get it operating in your network, SteelConnect lets you plan, store, and visualize your entire network first. Then you simply activate smart hardware (gateways, switches, and access points) that acknowledges the network components, and the SteelConnect Manager (SCM) brings the enterprise into production.
Key features
Unified connectivity and management across the WAN, remote LAN, and cloud networks
SteelConnect manages a software-defined connectivity fabric that spans WANs, remote office LANs, and cloud infrastructure networks through a line of physical, virtual, and cloud-based WAN gateways, as well as remote LAN switches and enterprise-grade WiFi access points.
Full-mesh VPN connectivity ensures application delivery from WAN to LAN that works over any network underlay such as Multiprotocol Label Switching (MPLS) and the internet.
After building secure overlay tunnels, SteelConnect can leverage the internet by sending internet-bound traffic straight to the internet from a branch site.
You can leverage the internet to access corporate applications that reside in the corporate data center through the secure overlay. High-priority, low-latency applications can still be steered over the corporate WAN.
Data center workloads
The SteelConnect SDI-5030 gateway offers enterprise-class SD-WAN for large-scale deployments. The 5030 gateway is designed for higher throughput to accommodate data center workloads.
Because the 5030 gateways are placed physically out of path from the data flow, you can deploy them with no network downtime. The system relies on either traffic redirection or route injection to receive SD-WAN services. The SteelHead Interceptor 9600 provides traffic redirection. You can also use route injection to redirect traffic to the data center gateways without the SteelHead Interceptor 9600 appliance.
WAN optimization
The SteelHead SD gateway models deliver the benefits of SteelHead WAN optimization, application intelligence, and SteelConnect SD-WAN while providing the flexibility of a single box solution. For details, see the SteelHead SD Installation Guide.
Cloud-based management
SCM provides an intuitive graphical user interface that supports an agile and intent-based workflow for managing networks.
Use SCM to design every aspect of a distributed network before deploying any hardware.
Business-aligned orchestration
SteelConnect provides policy-based orchestration using language aligned with business priorities: applications, users, locations, performance service-level agreements, and security requirements.
You no longer need to configure individual appliances. All appliances are managed through SCM.
The graphical user interface eliminates all CLI coding.
Business intent-based policy
SCM lets you manage a network centrally using a single business intent-based policy.
A central policy for all branches enables direct translation of business needs.
You can enforce a policy based on user identity—not just the IP address—for the same experience on all the user devices.
You can easily align all aspects of application delivery to improve performance.
Universal policy automation
SteelConnect empowers IT to evolve the infrastructure without having to revisit the policy.
A universal policy enables cohesive and automated change management.
Because you can use the same application groups, applications, and web categories for the policy engine and reporting, you can directly convert the reported results into policy rules.
Zero-touch provisioning
SCM provides instant deployment of physical devices into a network.
The configuration and reconfiguration of edge devices is automatic. Plug the cable into the WAN port of the device and the device will configure itself automatically using internet access.
Automatic provisioning reduces or eliminates the need for on-site IT in remote facilities.
Intelligent traffic steering
You can steer SaaS and web applications out to the internet directly, and if the internet link becomes unavailable, a traffic rule in SCM will route the traffic over the MPLS link to still be able to access the internet. The QoS priority can also be modified or set if desired.
Traffic can be steered not only by application: for example, VoIP, Facebook, WebEx, or Office 365, but also by site, user, host, or subnet. SCM also allows very granular control on how traffic is steered as well as native integration into Zscaler, a cloud access security broker, and Cloudi-Fi, a a guest WiFi provider that partners with Zscaler.
Visibility
SCM provides a unified view of users, devices, and groups of either.
You can quickly identify what traffic is consuming bandwidth.
Because SCM automatically detects new devices and users, you can minimize security risks.
SCM has integrated launch points for SteelCentral Insights for SteelConnect (Insights) for more granular network visibility. Insights enables performance monitoring and visibility for all applications, devices, sites and users in your SCM realm. With this information, you can make policy decisions, use it for monitoring or deployment decisions, and troubleshoot performance issues.
High-level architecture
SteelConnect resides in the global Amazon Web Services (AWS) cloud public infrastructure and orchestrates a series of services hosted by Riverbed. Each service has dependencies that function as a part of the collective SteelConnect infrastructure. These services include:
Management console
SD-WAN controller
Global certificate authorities (CAs)
Network Time Protocol (NTP)
Dynamic Domain Name System (DNS)
IP address reflectors, a simple mechanism for all gateways to find their public IP address per uplink and report the address to SCM
Structured Query Language (SQL) relational databases that keep track of which SCMs are associated with which organizations, sites, and devices
SteelConnect appliances (gateways, switches, and access points) connect to SCM, and the services associated with it. Each SCM communicates through various services for any updates regarding the appliance registration and management changes. All communication between the appliances and SCM, as well as all interoperating services inside of SCM, are authenticated through x509 certificate validation. These Riverbed-owned certificates are exchanged and validated for authenticity.
We preassign appliances to your organization in the factory.
SteelConnect registration and communication
With the exception of agent VPN clients, all communication is sourced from the site out to the SteelConnect management service. There’s no need to set up elaborate firewall or forwarding rules to establish the dynamic full-mesh VPN or to gain connectivity to the cloud. After you register an appliance, it receives its assigned configuration automatically.
For a list of the UDP and TCP ports that are sourced from the sites out into the cloud to connect to SCM, see Ports for UDP, TCP, and ICMP connections.
Appliances
Gateways
Gateways can be categorized into hardware and software appliances. They automatically map into connected network segments, called zones, to:
provide basic network services.
handle one or more uplinks, either by concurrent use or as backup.
enable policy enforcement.
enforce security.
enable extended reporting for connected zones.
connect multiple sites with a secure, full-mesh virtual private network (VPN) without tedious manual configuration using Automated VPN (AutoVPN). For details on the different ways to enable AutoVPN, see AutoVPN modes.
This table lists the common use cases for SteelConnect gateways by model.
Gateway model
Use case
SDI-130
Small branch and retail
SDI-330
Medium branch
SDI-1030
Medium to large branch
SDI-5030
Campus and data center
Access points
SteelConnect offers a line of enterprise-grade access points to provide network access to WiFi clients. Using XMS-Cloud and SCM to manage the access points, you can easily set up the SSIDs that your users can connect their devices to. After configuring access points in XMS-Cloud, SCM adds the discovered access points to the relevant sites in an organization and automatically creates an appropriate profile in XMS-Cloud corresponding to all sites using access points. For details, see WiFi Manager.
For a complete list of access point models, see Supported appliance types.
Switches
Enable plug-and-play multizone Layer 2 connectivity.
Provide power over Ethernet (PoE) to PoE-enabled appliances, including third-party devices.
SCM manages all appliances, including all firmware upgrades. For firmware upgrade details, see Upgrade overview.
Hardware versus software appliances
SteelConnect hardware appliances, such as a gateway, come with a serial number that activates the appliance in the organization. SteelConnect also supports a virtual gateway running in AWS or any hypervisor like VMware, Hyper-V, KVM, or Xen.
To help you identify an appliance without unmounting it, unregistered appliances with an organic LED (OLED) display (Gateway G100, Switch S24, and Switch S48) show their serial numbers on the screen until you register the appliance with SCM.
Browser support
SCM supports the latest versions of Firefox, Chrome, and Internet Explorer. For best performance, we recommend using the latest Chrome browser.
We strongly recommend using the latest Chrome browser with the WiFi planner.
SCM requires a minimum screen resolution of 1280 x 720 pixels.
 
Network service architecture
The SteelConnect network service architecture is built on two distinct layers:
Underlay
Overlay
Underlay
The underlay provides traditional physical Layer 2 and Layer 3 connectivity between appliances (gateways, routers, switches, and so on) in the network. The underlay allows all network nodes to communicate with other sites, even if the site doesn’t have a SteelConnect gateway.
A SteelConnect gateway in the branch typically provides underlay services, such as gateway routing, DHCP client, DHCP server, and DNS.
When there is a SteelConnect gateway in the data center, it uses the information it receives about the underlay to provision the overlay. The data center gateway doesn’t provide major underlay services, but it participates in (and observes) the underlay. The vertical lines in Transport overlays: internet and MPLS illustrate the relationship between the overlay and underlay networks.
Transport overlays: internet and MPLS
Overlay
The overlay augments the underlay and provides the powerful ability to select a WAN path based on traffic rules. For details, see Balancing traffic using traffic rules.
The overlay doesn’t replace the underlay. Sites that don’t have SD-WAN installed, perhaps during an initial migration, communicate across the underlay. Fully SD-WAN-enabled sites communicate across the overlay.
The software-defined WAN (SD-WAN) controller provides overlay creation and overlay routing. The overlay forms encapsulated tunnels between nodes in the network that carry the traffic within the SD-WAN.
SD-WAN controller overview
The SD-WAN controller provides critical functions within the SteelConnect solution. Both SCM and the SD-WAN controller reside within the Riverbed-hosted cloud environment. The controller takes charge of the important, frequent, and dynamic SD-WAN functions shown in SD-WAN controller responsibilities and interactions and described in What does the SD-WAN controller control?.
The SD-WAN controller architecture decouples the management plane (which controls the user configuration), from the control plane (which contains the routes, tunnels, and other information), to work independently. This distributed architecture allows the SD-WAN controller service to run separately for each organization configured by SCM.
SD-WAN controller responsibilities and interactions
The controller does not use a persistent state but is run-time state driven.
SCM continues to handle all policy processing, including the traffic rules, firewall rules, application rules, and the interface configuration.
What does the SD-WAN controller control?
The SD-WAN controller controls these important frequent and dynamic SD-WAN functions:
Building the overlay topology for an organization based on the cluster, site, and uplink configuration and generating route commands to reach subnets from any given site. Based on master and leaf properties, the controller builds an overlay to connect the sites with tunnels and defines security parameters to encrypt the traffic when sent over the overlay. The tunnels are unidirectional and are built using the uplinks configured with a common WAN present.
The controller also prepares route commands for every site that identify all the remote subnets and creates the associated tunnels needed to reach the subnets.
Listening to configuration changes to an organization made by the user through the SCM, such as adding new sites, zones, data center clusters, and uplinks. The controller reacts to any configuration changes and, if required, builds new routes and tunnels between the branch gateways and the data center gateway cluster to account for the changes.
After the initial synchronization between the controller and an appliance that involves sending the entire configuration, subsequent changes are sent dynamically when changes occur. Instead of sending a complete configuration down the data path to the SteelConnect appliance, the controller sends only incremental changes to an impacted area. This means that not every appliance will receive every change. For example, if an uplink IP address changes, the controller will update only those tunnels that require the new IP address.
Owning and managing all centralized VPN keys that safely encrypt the traffic to secure the overlay between all SteelConnect appliances. For details, see Secure overlay tunnels.
Performing routing management for both static and dynamic routes to respond to events and data from the field and appliances without user intervention. For example, when a SteelConnect appliance learns about any network on the LAN side discovered through OSPF, it sends a route update message to the controller. The controller then uses the route update message to generate a route overlay message and sends it to all sites. The sites can then route the traffic over secure tunnels.
Handling graceful restarts.
Secure overlay tunnels
SteelConnect establishes secure overlay tunnels between SteelConnect gateways, including both data center and branch gateways. The overlay tunnels are secured using centralized virtual private network keying (C-VPN-K). Traffic is encrypted by the Advanced Encryption Standard (AES) cipher algorithm in Cipher Block Chaining (CBC) mode using a 256-bit key. For secure authentication, centralized VPN keying uses the hash message authentication code (HMAC) secure hash algorithm (SHA512).
Inbound and outbound tunnels
The SD-WAN controller builds two unidirectional tunnels for each uplink present over the same WAN. For example, suppose you configure site 1 and site 2 with an internet uplink. The controller creates a tunnel from site 1 toward site 2 that acts as the outbound tunnel for site1 and the inbound tunnel for site 2. The other tunnel created from site 2 to site 1 acts as an outbound tunnel for site 2 and inbound for site1.
The first outbound tunnel from site 1 to site 2 is used to encrypt traffic toward site 2. A second inbound tunnel is created to decrypt the traffic coming in from site 2. In a deployment where each site has two uplinks, the controller creates four tunnels for each site: two tunnels for the internet WAN (1 outbound and 1 inbound) and two tunnels for the MPLS WAN (1 outbound and 1 inbound).
Unidirectional tunnels built between site 1 and site 2 with an internet uplink­
Secure tunnel keys
The SteelConnect SD-WAN controller generates an array of seven security parameters index (SPI) keys for each tunnel per appliance. The SPI key is a unique number associated with a tunnel. If the key changes based on the rekeying interval, a new SPI is set. The rekeying interval for C-VPN-K is every four hours. VPN keys are transmitted to each appliance over an encrypted management channel between the controller and the appliance. VPN keys are held within process memory and are never stored in the file system or elsewhere in the appliances or SCM.
The VPN key array contains these keys, which are valid for four hours:
Key 0 - This key is the expired key from four hours ago, held within process memory in case the tunnel is published to both sites but one of the sites is not running the current time and is not synchronized with the other site. The out-of-sync tunnel can continue to use the expired key to decrypt any traffic sent by the other site.
Key 1 - This key activates when the tunnel is built and published to both sites.
Keys 2 through 6 - These keys are created in advance in case the appliance becomes disconnected from the controller. If an appliance is disconnected, it can continue to use the secure overly for traffic for the next 24 hours.
By default, centralized keying is turned on for all AutoVPN deployments. Both branch gateway-to-branch gateway and branch gateway-to-data center gateway (5030) tunnels within a realm use centralized keying.
When centralized keying is off, such as when Classic VPN tunnels are in use, gateway-to-gateway tunnels are established with IKEv2 using the same encryption and authentication algorithms as centralized keying.
Secure overlay tunnels use centralized VPN keying
Deployment considerations
For centralized keying to work, you must enable encryption for all WANs, including MPLS. For details, see WAN settings.
We recommend using NTP time synchronization to synchronize the branch and data center gateways. Complete this procedure on each branch and data center gateway in the deployment.
Deployments support mixed C-VPN-K and ClassicVPN tunnels.
To synchronize the date and time using NTP servers
1. Choose Organization.
2. Select the Networking Defaults tab.
3. Under NTP settings, specify the local Network Time Protocol (NTP) servers of your choice, one per line. We recommend that you configure your own internal NTP servers; however, you can leave the field blank to use these default Riverbed-provided NTP servers:
0.ocedo.pool.ntp.org
1.ocedo.pool.ntp.org
2.ocedo.pool.ntp.org
3.ocedo.pool.ntp.org
4. Click Submit.
Key management, retrieval, and rotation
The SD-WAN controller generates VPN keys every four hours and transmits them to the appliances. VPN keys expire every four hours and each appliance holds up to six key pairs so that if the appliance were to lose connectivity to SCM temporarily, the network is not impacted. Should an appliance lose connectivity for more than a day, tunnels will go down as all stored keys will expire after 24 hours without connectivity to SCM. This feature provides additional security over traditional VPN gateways.
The data center gateway receives the encryption keys from the controller through an SSL connection on TCP port 3904. TCP port 3904 must be open on the corporate firewall in order for the gateways to pull the keys securely.
The 5030 gateways must connect to the SD-WAN controller with their management port. When a 5030 gateway cluster is configured, the SD-WAN controller generates unique VPN keys for each tunnel.
The branch gateways already have a secure connection to the controller in the cloud and use this connection. You don’t need to open an additional port on the firewall for the branch gateways.
The gateways store the keys locally for use until the rekey interval expires.
The keys are changed every four hours or when a new tunnel endpoint (TEP) appears.
The gateways change from the old to the new keys during a rekeying event and apply the new keys to the existing tunnels.
Each gateway is only aware of the keys used to secure its own tunnels.
Key resiliency
SCM services related to centralized keying are fault tolerant and don’t affect AutoVPN connectivity when restarted.
The centralized keys are resilient to complete loss of connectivity to SCM for extended periods (about one day).
The keys are resilient to asymmetric loss of connectivity to SCM, such as when only one gateway receives a configuration update.