Introducing SteelConnect

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.

•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.

•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.

•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.

•SteelConnect provides policy-based orchestration using language aligned with business priorities: applications, users, locations, performance service-level agreements, and security requirements.

•You can enforce a policy based on user identity—not just the IP address—for the same experience on all the user devices.

•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.

•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.

•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.

•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.

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:

•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.

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.

Gateways can be categorized into hardware and software appliances. They automatically map into connected network segments, called zones, to:

•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

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.

SCM manages all appliances, including all firmware upgrades. For firmware upgrade details, see Upgrade overview.

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.

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.

The SteelConnect network service architecture is built on two distinct layers:

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.

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.

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.

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.

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.

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).

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).

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.

•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.

•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.

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:

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 keys are resilient to asymmetric loss of connectivity to SCM, such as when only one gateway receives a configuration update.