alexfray ZPA, Zscaler

Zscaler – Disaster Recovery using ZPA

zpa-casestudy

Over the years we have designed and implemented a variety of Disaster Recovery (DR) environments and processes for customers to meet their requirements. These DR projects have ranged from Active/Active data centres or Primary/DR data centres to application specific DR.

The latest DR project we were involved in was for a government department who host their applications in Microsoft Azure. The requirement was that in the event of a disaster at their primary Azure Region to be able to spin up their applications and infrastructure in another Azure region within their DR Recovery Time Objective (RTO).

For the customer’s external facing applications we used native Azure front-door functionality such as Azure Traffic Manager to failover DNS between regions so this was relatively straight forward to redirect traffic once the application had been spun-up. However for the internal applications we needed another method to fail traffic over because these applications were not exposed to the Internet.

Enter Zscaler Private Access (ZPA). ZPA is a cloud service from Zscaler which provides Zero-Trust Network Access (ZTNA) to internal applications hosted on-premise or in the public cloud. We had already deployed ZPA for the customer 18 months ago to provide users access to internal applications in Azure. So to provide DR for internal applications we leveraged the customer’s existing investment in ZPA.

One of the key customer requirements was for zero infrastructure costs in the DR Azure region so for DR testing or for an actual DR event we would spin up the infrastructure on-demand. Another requirement was that the RTO for their applications must be within 3 hours.

We were able to stand up a configured Zscaler connector within 30 minutes and fail all traffic that currently traversed the Zscaler connectors in Azure region A to the DR Zscaler connector in Azure region B.

Using ZPA for disaster recovery of the customer’s internal applications allowed us to achieve their key DR requirements for cost and RTO whilst also providing an easy set of steps for DR testing or an actual DR event. Another requirement we were also able to achieve was per-application DR, which was desirable but not a mandatory requirement as the customer did not think we would be able to achieve because of duplicate IP addressing. The fact that ZPA is not a network based VPN enabled us to achieve per-application DR.

If you’d like to talk Zscaler Private Access get in touch.

Alex

 

 

alexfray SD-WAN, VeloCloud

SD-WAN – VMware SD-WAN by VeloCloud – Part 2

velocloud-casestudy

VeloCloud is a leading SD-WAN product which was procured by VMware 2 years ago and has since been rebranded VMware SD-WAN by VeloCloud. VeloCloud along with Viptela were the first pure players which really kick started the SD-WAN revolution so its no surprise really that both were scooped up by VMware and Cisco respectively.

Note. For background info on VeloCloud please read my Part 1 blog.

Cisco’s purchase of Viptela was a no-brainer with Cisco’s I-WAN effort not really making the cut but VMware’s purchase of VeloCloud seemed odd to me at the time. What is the virtualization giant going to do with a WAN product? Turns out it was a great purchase. VeloCloud comes as a hardware or virtual appliance and is supported on Azure, AWS and GCP. VMware have now partnered with all three of these public cloud providers enabling VMware customers to move their virtual machine workloads from on-premise to the cloud and also between cloud providers, enabling customers to optimize workloads. And what can you use as the transit mechanism for this? Yep, you’ve guessed it, VMware SD-WAN by VeloCloud.

The key advantages of using SD-WAN and the Internet as transit when you are moving workloads to the cloud are:

  • Single WAN platform – Using SD-WAN you have one platform to manage as opposed to using a combination of products, VPNs and circuits (e.g. expressroute and direct connect) which often don’t interoperate. This also creates a routing nightmare with a mix of dynamic and static routing and often manual intervention. Using SD-WAN means you have any-to-any connectivity (Mesh VPN) between all your sites and cloud environments, simplifying your WAN.
  • Time to Deliver – One benefit I have seen first hand of using SD-WAN and the Internet as transit is that when I have introduced a new cloud region, for example in Azure, I have deployed a virtual VeloCloud Edge in the new VNET and within minutes the VNET is part of my VPN overlay and routable from any site and cloud environment. It finally feels like you can deploy a network as easily as you have been able to deploy virtual machines for all these years.
  • Multi Cloud Strategy – If you are planning on a multi-cloud strategy and by this i mean multiple public cloud providers and potentially private cloud in the mix then it really doesn’t make sense to use expressroute or direct connect circuits. The Internet is the next corporate network. Wedding yourself to your MPLS network/provider by installing expressroute or direct connect circuits shouldn’t even be entertained in most instances (there are always exceptions).
  • Internet is the next corporate network  – Now if you have already started using Software as a Service such as Office 365 then you have already started to adopt this premise. If you are using a mixture of on-premise, SaaS and IaaS then using the Internet as your corporate network starts to make sense as the balance starts to shift as you migrate applications from your on-premise data centres to the cloud. SD-WAN is an enabler to use the Internet as your corporate network by securing your sites and enabling connectivity between them and your cloud environments. Want proof? You don’t see Service Providers investing in MPLS anymore they are partnering with VeloCloud and Viptela, among others, to provide managed SD-WAN solutions.

Using VMware SD-WAN by VeloCloud has enabled me to design solutions which are optimal for hybrid and mutli cloud deployments and deliver real business and technical benefits. For more information about why SD-WAN and vendor selection please see my other blogs.

Alex

SD-WAN – A New Hope

SD-WAN – Vendor/Platform Selection

alexfray Cisco

Cisco ASAv Firewall – FaQ

Frequently asked Questions

VPN NAT behind the VPN Gateway Public IP

This sounds like inception to me. In some instances 3rd parties do not accept a VPN connection using an RFC-1918 source IP address, for example SAP and some banks due to the amount of customers they have. As such you either need to use a public IP range in your DMZ or NAT your source traffic behind the public IP of your firewall. This always confused me, how can you configure a VPN connection using a public IP, for example 1.1.1.1 and then define the local encryption domain as 1.1.1.1. Would this work? I had such a requirement recently and it does in fact work with a Cisco ASAv (might not work with all VPN vendors).

# Create network groups and define your local networks and NAT address
object-group network LOCAL-NETWORKS
network-object 10.0.0.0 255.255.255.0
!
object-group network LOCAL-NETWORKS-VPN-NAT
network-object host 1.1.1.1
!
# Define the interesting traffic in the ACL using the NAT address as the source
access-list VPN-TO-SAP permit ip object-group LOCAL-NETWORKS-VPN-NAT object-group REMOTE-NETWORKS
!
Make sure that the VPN traffic is NAT'd. This is processed before VPN encryption
nat (inside,outside) 1 source static LOCAL-NETWORKS LOCAL-NETWORKS-VPN-NAT destination static REMOTE-NETWORKS REMOTE-NETWORKS

NAT-T

Using Cisco ASAv in AWS or Azure is possible. However be aware that the firewall is unware of the public IP address you assign to the outside interface. If you are going to use the Cisco ASAv for a VPN this is also possible as NAT-T is on by default so the firewall will source traffic from the public IP and access IKE traffic destined to the public IP. Ensure you permit the NAT-T protocol (4500/udp) and that the remote end of the VPN supports NAT-T.

Cisco ASAv Smart Licensing registration issue

By default the Cisco ASAv management interface is not part of the firewall routing table so cannot route directly to the Internet. The Smart licensing process uses the management interface by default. There is documentation on how to configure a proxy for this traffic but if you want to route directly you will need to configure the Smart Licensing to use the external interface (un-documented).

Check VM and licensing information
ciscoasa# show vm - shows the vm details (vcpu, memory, hypervisor)
ciscoasa# show version - shows the model
ciscoasa# Show license status - show your current licensing status

Configure DNS resolution
ciscoasa(config)# dns domain-lookup outside
ciscoasa(config)# domain-name networkjigsaw.local
ciscoasa(config)# DNS server-group Default
ciscoasa(config)# name-server 8.8.8.8
ciscoasa# ping tools.cisco.com - test DNS resolution

Configure Smart Licensing
ciscoasa(config)# license smart
ciscoasa(config-smart-lic)# feature tier standard
ciscoasa(config-smart-lic)# throughput level {100M | 1G | 2G}
ciscoasa(config-smart-lic)# exit
ciscoasa(config)# license smart register idtoken {token} {force}

Verify license has applied
Ciscoasa# show vm
Ciscoasa# show license usage

If this fails at this point, try changing the call-home interface (which smart licensing uses) to the outside interface.

alexfray Azure

Azure Firewall

Microsoft’s Firewall as a Service offering, Azure Firewall, was released in 2018. A bit late in the day in my opinion as early adopters of Azure would have already procured Network Virtual Appliances such as Checkpoint or Palo Alto but if you haven’t adopted Azure yet or are re-evaluating your perimeter security then Azure Firewall might be the solution for you.

Azure Firewall is a Firewall as a Service which means you get built-in high availability, scalability and no requirement to maintain or upgrade appliances which is a real business benefit. What does it give you over a Network Security Group (NSG)? Well quite a lot, you get a dedicated public IP address so you appear as a consistent address on the Internet, you can also create inbound rules if you desire. The key benefits though are automation, FQDN based rules and Azure tags, which provides simplified management and scalability over an NSG’s 5 tuple approach.

Microsoft have baked in a raft of Azure tags so you don’t need to define rules/FQDNs for Azure AD, Azure Backup, Windows Updates, Azure Key Vault and other Azure services which makes deploying and securing Internet connectivity for Windows VMs very quick and easy. This also makes management overhead of your rulebase very low, even when compared to a Network Virtual Appliance (NVA).

If you haven’t already invested in an NVA or are re-evaluating your Azure perimeter security then Azure Firewall is a viable option,  however there are some drawbacks.

  • There is no SSL inspection which means the rules are based on the FQDN for HTTP sites or the Certificate CN for SSL based sites. This can make creating rules for SSL sites a bit tricky if SAN or wildcard certificates are used so be prepared to use Wireshark.
  • Logging. You will need to use a Log Analytics workspace to view logs which is ok and the workspace stats are quite snazzy for reporting. Bear in mind unless you use a free workspace which has limitations this will incur additional costs either per host or per GB. For live troubleshooting using log analytics just isn’t an NVA log viewer like Checkpoint Smart tracker or similar. This blog written by Thuan Soldier has some good info and log query samples https://thuansoldier.net/7805/
  • NGFW Capabilities. Limited layer 7 protection features commonly referred to as Next Generation Firewall protection such as IPS, Application Awareness, Anti-Virus etc. Currently the only NGFW feature is threat intelligence which dynamically blocks known malicious IPs/Domains (in preview). This means limited visibility of your traffic, considering 70% of websites are now SSL you want to ensure your environment is protected from advanced threats or malware where possible.
  • Cost. Its not cheap, over a year, an Azure Firewall will cost over £7k. which is equal to or more than most NVA’s (depending on your discount). So you are paying a lot for the ‘as a Service’ benefits (HA, scalability and minimal management overhead). Coming soon you will be able to de-allocate/allocate the Azure Firewall to pause the cost so for dev/test environments you could automate this to lower the cost for environments which are not 24/7.

We have deployed Azure Firewall for clients and it is very easy to deploy. The only prerequisites are that you need a dedicated subnet to deploy the Azure Firewall called AzureFirewallSubnet; and the subnet must have a /26 mask. Its also easy to script to repeat the process for multiple release process environments.

From a network design perspective, deploy the Azure Firewall in your hub or transit VNET so you can leverage it for all your VNETs. You can deploy the Azure Firewall without impact existing traffic flows as you need to create User Defined Routes to force traffic through the Azure Firewall so it is easy to integrate into an existing environment subnet-by-subnet to limit the impact and also provide rollback if your rules aren’t quite right.

No doubt Microsoft will continue to develop Azure Firewall and introduce more NGFW features so I am sure some of the technical limitations above will be addressed. Azure Firewall is a solid alternative to secure your Azure environment, especially if you have a small IT support team, but consider your current and future requirements as an NVA may be a better fit. One cloud benefit is that you don’t have to sweat assets, as there is no hardware or capital purchase involved, so you could always migrate to an NVA if your requirements change, environment scales or requires Next Generation Firewall capabilities.

Microsoft’s documentation is excellent for Azure components, for documentation on Azure Firewall see here.

Alex

alexfray Azure

Azure VPN Gateway

More and more we are asked by clients to configure site-to-site VPN tunnels from on-premise VPN gateways such as Checkpoint and Cisco to Azure using the native Microsoft Azure VPN Gateway.

The Azure VPN Gateway is a very compelling alternative to procuring a dedicate Network Virtual Appliance (NVA) in Azure, High Availability is built in, it scales, you don’t have to upgrade or maintain the appliance so for most clients it will do the job. However, a few things to consider:

  • Authentication, you can only use pre-shared keys (PSK), this may not be an issue but if you are required to use certificate-based authentication then you will need an NVA.
  • Troubleshooting, this is not particularly easy with the Azure VPN Gateway in comparison to an NVA which provides all information regarding tunnel negotiation. In my experience you are in the hands of the person or 3rd party configuring the on-premise end of the VPN to get it correct and troubleshoot. Now if that person is yourself or a competent engineer then this may not be an issue, however I have spent many an hour troubleshooting with inexperienced engineers configure VPNs.
  • No ACLs, you cannot apply rules to VPN tunnels or the Gateway subnet to limit what traffic or protocols can access services in your VNET/subnet(s). You can do this further up the stack on your destination servers or subnets but ideally you want to do this as close to the source as possible (best practice).

I think the Azure VPN Gateway is a decent offering but does lack the granularity of a Network Virtual Appliance. The choice will depend on your requirements, in-house network skills and budget.

Below is the powershell commands to create an object representing the on-premise VPN gateway and how to create and modify the VPN tunnel parameters. A prerequisite to this is downloading the Azure Powershell Module (i’m using AZ which replaced AzureRM)

logon to your Azure subscription (handy if you have multiple subscriptions)

#login to azure account
Login-AzAccount

#lists all the subscriptions in a form to choose from
$subscriptionId = 
(Get-AzSubscription |
Out-GridView `
-Title "Select an Azure Subscription …" `
-PassThru).SubscriptionId

Select-AzSubscription -SubscriptionId $subscriptionId 

# if error occurs opening subscriptions try
Set-ExecutionPolicy Unrestricted

Create the on-premise VPN gateway, referred to as a local gateway

#VPN variables
$RG1 = "existing-rg"
$Location1 = "uksouth"
$GWName1 = "Azure-VPN-GW"
$LNGName6 = "Onpremise-GW1"
$LNGIP1 = "1.1.1.1"
$LNGprefix1 = "192.168.1.0/24"
$connection16 = "3rd-Party-VPN"

#Create remote VPN Gateway object
New-AzLocalNetworkGateway -Name $LNGName6 -ResourceGroupName $RG1 `
-Location $Location1 -GatewayIpAddress $LNGIP1 -AddressPrefix $LNGprefix1

Create a VPN policy with your desired encryption, hashing algorithms and SA timeouts. Note the Phase 1 SA timeout cannot be changed from 28800 seconds.

#vpn parameters. Note phase 1 SA timeout cant be changed from 28800 seconds
$VPNPolicy-3rdParty = New-AZIpsecPolicy -IkeEncryption AES256 -IkeIntegrity SHA256 -DhGroup DHGroup14 -IpsecEncryption AES256 -IpsecIntegrity SHA256 -PfsGroup None -SALifeTimeSeconds 14400

Create the VPN Tunnel and bind to your gateways

#create vpn connection
$vnet1gw = Get-AZVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1
$lng6 = Get-AZlocalnetworkgateway -Name $LNGName6 -ResourceGroupName $RG1
New-AZVirtualNetworkGatewayConnection -Name $connection16 -ResourceGroupName $RG1 -VirtualNetworkGateway1 $vnet1gw -LocalNetworkGateway2 $lng6 -location $Location1 -ConnectionType IPsec -IpsecPolicies $VPNPolicy-3rdParty -SharedKey 'thisisyourpresharedkey'

Show your VPN policy settings

#show ipsec parameters for a policy
$connection6 = get-AZvirtualnetworkgatewayconnection -name $connection16 -ResourceGroupName $RG1 
$connection6.ipsecpolicies

Show your local and Azure VPN Gateway settings

#show vpn gateway local gateways defined
Get-AZvirtualnetworkgateway -resourcegroupname existing-rg
Get-AZlocalnetworkgateway -resourcegroupname existing-rg

When you create a VPN tunnel with a remote encryption domain, for example 192.168.1.0/24, this is automatically added to your system routing table so you don’t need to create User Defined Routes which is pretty neat.

Alex

 

alexfray SD-WAN, VeloCloud

SD-WAN – VMware SD-WAN by VeloCloud – Part 1

I’ve been using VMware NSX SD-WAN by VeloCloud (and that mouthful for the remainder of the post will be referred to as VeloCloud), for the last 4 months. I thought it would be useful to provide an unbiased technical evaluation of the product with a lot of network architects and engineers beginning to dip their toe into the SD-WAN market either this year or next hardware refresh.

I’ve covered why SD-WAN in another blog but in short the key driver for SD-WAN is Cloud service adoption. The shift of traffic patterns from on-premise data centres to the Internet (SaaS/PaaS/IaaS) and SD-WAN’s ability to provide simple deployment, VPN and secure local Internet breakout either by itself, Virtual Network Function (such as a Palo Alto) or service chaining to a cloud security service such as Zscaler.

Product Features

VeloCloud stood out to me when compared to rivals for a few reasons. I’ve covered SD-WAN product selection in another blog so these are the features having now productionised an SD-WAN environment that I think VeloCloud excels at.

Deployment – Once you have designed and piloted your SD-WAN environment deploying branch VCEs is simple. It takes the stress out of a site migration for an engineer and time to deliver is much quicker. In one instance I arrived at small branch site, migrated, tested and left in less an hour. This isn’t always the case as with larger or more complex branch sites requiring more testing but the VeloCloud deployment was never the issue and in most cases I could deploy the VCE in parallel of the existing WAN so that the downtime was minimal when cutting across.

QoE (Quality of Experience) – If you intend to use multiple WAN links for all or some of your branch sites, the QoE monitoring and VeloCloud’s Dynamic MultiPath Optimization (DMPO) protocol is seriously impressive. DMPO enables per packet steering across the best WAN link and QoE reports on why it moved the traffic whether it detected packet loss, increased latency or jitter. It also has the ability to buffer, duplicate packets or perform error correction on the fly. Sounds good right? I’m currently running Voice over IP over the Internet, granted my bandwidth and latency are good but this is typically a reason why enterprises are looking to deploy SD-WAN in hybrid mode (Internet and MPLS), my experience so far is that even with contention on the WAN links there has yet to be any call degradation.

QoS (Quality of Service) – Referred to as the business policy, this has application recognition and the ability for an administrator to move applications to different queues to fit the customer’s traffic pattern. VeloCloud kindly provide a starter policy which to be fair doesn’t need that much altering to get you started. The VOIP traffic as mentioned above is categorized as Real Time Protocol and put in the realtime queue which gives it outbound and inbound priority over other traffic, so even if you only have a single WAN link the VCE will still perform error correction. buffering, duplication and QoS.

Monitoring – Having used CA Spectrum and SolarWinds for years network engineers are used to fairly basic monitoring systems. The VeloCloud monitoring is mind blowing. You get all your typical statistics on bandwidth, latency, jitter etc however you also get appflow data to see what applications are being used and how much bandwidth they are using so you can see how much bandwidth a SQL query takes up one hour to the extent that you can see how much bandwidth Windows Updates have used over a year. That’s right almost instantly you can go back up to a year to that level of granularity. And then you can do something about it, for example I could see Windows updates continually using a significant amount of Internet bandwidth so instead of letting it impact users I created a business policy rule for Windows updates and put it in the low priority queue, I did this at the profile level which meant once I finished, the rule got pushed out by the Orchestrator to all branch VCEs. This visibility into the WAN and simplicity to implement application layer QoS is awesome and will benefit many enterprises.

Product Integration

VeloCloud was bought by VMware just over a year ago. In terms of product integration, there doesn’t seem to have been many announcements. I Instantly think of Viptela’s integration with Cisco and how it is already available as a container on the Cisco ISR router. But is this like-for-like? Yes and no, VMware doesn’t do routers so that was never going to be their market, so I can only surmise that VeloCloud will integrate with their existing NSX portfolio to improve their workload management capabilities between on-premise, private and public cloud providers.

While VeloCloud’s integration into VMware appears a bit slow, its integration with Microsoft and their Azure Virtual WAN has been quick. Azure Virtual WAN offers an alternative to spinning up a VeloCloud Edge virtual appliance in Azure which if you are already using Virtual WAN or a have a mixed bag of WAN solutions maybe worth investigating. Myself, I prefer a full stack, having VeloCloud throughput provides end-to-end QoS (within the VPN) using the Business Policy and excellent traffic visibility in a single dashboard. However if you have many Azure locations or subscriptions this might not be cost effective in which case Azure Virtual WAN should be strongly considered.

If I had to ask for an integration feature I would like the ability to use an external Identity Provider (IdP) such as Azure AD or Okta to control management access to the VeloCloud Orchestrator, leveraging an existing identity source and conditional based access policies.

Product Development

VeloCloud is still a developing product, like all SD-WAN products out there. I am currently using the latest version as it allows me to have direct IPsec tunnels from a branch site VeloCloud Edge (VCE) to a Cloud Security Service (Zscaler). Before this release the tunnel to Zscaler was from the cloud hosted VeloCloud Gateways (VCG). The idea of a single, resilient egress point from your VPN overlay to your cloud security service seems like a good design however, remember that IPsec tunnels to Zscaler are limited to 200Mbps so depending on the size of your organisation this may not be suitable. To be fair this isn’t a VeloCloud issue but it is something to be mindful of if you are integrating with a Cloud Security Service. Direct Tunnels from a VCE to Zscaler allow me to pick and choose which sites should use Zscaler and whether it should be used as the default route (using the Zscaler Cloud Firewall) or just for web traffic. The profile functionality of VeloCloud is very good for this and enables you to configure at scale.

One area that still needs improvement is the tunnel failover, which is planned to use IP SLA soon (IP SLA is used if using the Cloud Gateway method today).

Having used earlier versions of the code it does seem to have stabilized which is good with more emphasis on stability as opposed to rushing new features into a release, which shows a maturing product. Getting hold of release notes however was not easy, it would be good if these were made available publicly or in the VeloCloud Orchestrator.

Product Documentation

When down selecting VeloCloud it was very difficult to find any technical documentation, just the sales and solution briefs on the website which made it hard to compare the product to its rivals; although Cisco made a good mess of their website with a mix of I-WAN and Viptela (now resolved). The technical documentation is located in the VeloCloud Orchestrator which is great once you have access but trying to ascertain whether the product met a customer’s technical requirements prior to an evaluation was a bit painful and may put off some potential customers if they can’t find the information.

Now the help documentation is a mixed bag. I hold the Zscaler help documentation to be one of the better public help document repositories as it is easy to navigate and the instructions, whether is be design, implement or troubleshoot are clear and inline with the current version at that time. The VeloCloud technical documentation needs some work.

Product Support

VeloCloud Support are very responsive and the engineers I have dealt with so far are very knowledgable about the product. In some scenarios I wish I was able to SSH into the VCEs like the support engineers do to troubleshoot but then I remember this isn’t a Cisco router, its a cloud managed service. It would be good to have a cloud health status page and I believe that service providers have this kind of visibility but for enterprise customers it would be good to know if there are live issues with the underlying cloud service.

Summary

The above is my opinion based on my experience of the VeloCloud ecosystem. I look forward to see how it evolves and i’m sure my minor gripes will be resolved at some point. If you would like to discuss SD-WAN or VeloCloud please reach out to me.

Alex

alexfray SD-WAN

SD-WAN – Vendor/Platform Selection

Choosing an SD-WAN vendor/platform has become increasingly difficult as the WAN edge market rapidly expands. This blog provides a summary of my thought process when down selecting SD-WAN vendors/platforms.

SD-WAN Vendors/platforms typically fall into one of four categories:

  • Pure Players – are start-ups such as VeloCloud and Viptela which are the two main disrupters in the WAN edge market. Both start-ups were acquired by VMware and Cisco respectively and lead the Gartner magic quadrant for WAN edge 2018.
  • WAN Optimization – This category includes companies such as Riverbed, Silverpeak and Citrix, essentially businesses which out of necessity to survive have diversified from the dying WAN Op market to SD-WAN. In my opinion Riverbed should have bought Silverpeak to boost there market share as Silverpeak has a decent amount of customers and a very solid platform. That’s not to say Riverbed’s acquisition of Ocedo was bad as the Riverbed platform is pretty good from what I have evaluated and will get better over time. However unless you already have a Riverbed WAN Op deployment would you consider Riverbed over a pure player which is designed from the ground up to be cloud driven SD-WAN not WAN OP with a SD-WAN bolt-on.
  • Security – This category includes traditional security vendors such as Barracuda, Fortinet and Palo Alto Networks. NGFW’s already have VPN capabilities so SD-WAN is a natural feature to provide. What puzzles me is why Checkpoint haven’t ventured into the fray when the other NGFW leaders have. While these vendor offerings will be secure they lack a mature cloud management platform and similarly to the WAN Op category feels like a bolt-on feature to try and maintain existing customers.
  • Managed Service – As organisations start to move away from MPLS, providers are pivoting to provide managed SD-WAN services. Now this is an interesting and valid proposition depending on your business requirements and operating model. Orange Business Services offer some good solutions here if you are looking at a managed service (Note. I don’t work for OBS). The managed services I have seen are using Viptela or VeloCloud under the hood which I think says a lot about the strength of the pure player category.

Your existing network architecture and/or experience in some of the above vendors may influence your decision or at least help narrow down the field. However your decision should be based on which vendor/platform meets your business and technical requirements. I’ve pulled together some key technical requirements below when evaluating SD-WAN vendors/platforms. This is not an exhaustive list by any means.

  • Virtual Appliance – Whilst all SD-WAN vendors will have a physical appliance available, ensure that their range of appliances meet all your site and bandwidth requirements. However not all SD-WAN vendors have a cloud based appliance. Most organisations will have a public cloud presence so it is important to ensure your SD-WAN vendor has an appliance available in the respective cloud’s marketplace. VeloCloud and Viptela both support both AWS and Azure so it is relatively easy to extend your WAN to the cloud. If your SD-WAN vendor doesn’t have a public cloud appliance then what are your options? Well from a Microsoft perspective they have recently released Azure Virtual WAN which integrates with a number of SD-WAN vendors such as Citrix, Riverbed and VeloCloud among others so you don’t need a dedicated virtual appliance. The downside is that you don’t get complete visibility of your SD-WAN environment, you loose out on network and application visibility statistics and any QoS or application prioritization you may want to configure. I see this integration for smaller enterprise customers or perhaps Dev/Test and Pre-Production environments to reduce cost.
  • VPN Throughput – Typically most SD-WAN vendors have a range of physical appliances which will fit most organisation’s bandwidth/throughput requirements however their respective virtual appliance can often be quite poor with regards to VPN throughput. Now if your public cloud deployment is quite large then is a key requirement. I have been provided with some truly terrible solutions (workarounds by Vendors) by spreading the load across multiple appliances using IP prefixes which would be a routing nightmare in Azure or AWS and this is just masking their problem.
  • Cloud Management – You would assume this was a given but even big players like Citrix don’t have a cloud management platform. My main considerations around cloud management are typically, where is it? Working in the UK/EU you want to ensure that your cloud management is in the same region to ensure data compliance. Most vendors will host you on your nearest Orchestrator, for example VeloCloud’s EU Orchestrator is hosted in AWS in Frankfurt and I believe London is on the road map but if you are a multi-national organisation you may want to consider which region you want your orchestrator. The next consideration is what data is held and does this have GDPR implications. Ensure your SD-WAN vendor has GDPR information available and that you engage your legal department to ensure you are compliant.
  • Cryptography – Having evaluated a number of leading SD-WAN vendors, I was surprised how lacking some were in terms IPsec variables such as IKE version, encryption and hashing algorithms. Typically I hold NCSC’s IPsec foundation profile as the benchmark. VeloCloud can meet this profile which is a big tick if you are working with UK defence and public sector customers. Not only does it meet the criteria but some parameters are meet the PRIME profile which is like the unicorn of crypto security.

NCSC Foundation Profile – IKEv1, AES-128 CBC, SHA-256, DH group 14 and Certificate based authentication.

Most secure VeloCloud Profile – IKEv2, AES-256 GCM, SHA-256, DH group 14 and Certificate based authentication.

https://www.ncsc.gov.uk/guidance/using-ipsec-protect-data

  • PKI – Use of certificates for authentication requires a PKI. Certificate based authentication is the preferred method of authentication because it is more scalable and secure than pre-shared keys. Most organisations will have a PKI (of sorts) however it is doubtful this will be exposed to the Internet, assuming your SD-WAN will be configured in Internet or hybrid mode. The VeloCloud Orchestrator has a CA baked in which makes deploying certificate authentication very easy. Upon activating a VeloCloud Edge device the Edge is issued a 90 day RSA 2048 bit certificate. This certificate is renewed at 80% to ensure continued connectivity. You can revoke certificates in the Orchestrator or by deleting an Edge the certificate is also revoked.

You can use a mix of PSK and Certificates in the VeloCloud platform if you wish, sometimes integration with 3rd parties doesn’t allow for certificate authentication so you can fallback to PSK. VeloCloud give you the option of Certificate disabled, Optional or Required. Disabled is fairly obvious but Optional means a VPN device/edge using PSK can communicate to Edges using PSKs or Certificates which allows for flexibility but does reduce security somewhat. Required means that if an edge uses certificate authentication it can only communicate to other edges that use certificates, this is very secure but not as flexible so really depends on your requirements.

  • Ease of Deployment – One of the big selling points of SD-WAN is the ease of deployment. Most Pure Players and WAN Op SD-WAN vendors offer this. What I have found though is that when you do have deployment issues they have very little local troubleshooting capabilities which is very frustrating when you can’t even run a ping to your gateway or do a DNS lookup.
  • Service Chaining – Depending on which SD-WAN vendor you’ve chosen and how you are going to break out to the Internet this may or may not be a consideration for you. However if you already use a cloud security service like Zscaler then tunnelling your local branch Internet traffic to the Zscaler cloud is a no-brainer as it is no additional cost (depending on your bundle). Large enterprises like Siemens do this as opposed to running local branch firewalls or VNFs. With over 2200 branch sites that’s a very scalable solution.
  • Dynamic Routing – As I have said before SD-WAN appliances are not Cisco routers. If you need routing resilience or integration with your Interior Gateway Protocol (IGP) be sure your chosen SD-WAN vendor supports your IGP fully. Viptela and VeloCloud supports OSPF and BGP but a lot of SD-WAN vendors have pretty poor IGP support so ensure you research this. In particular when they say OSPF supported it is typically only in passive mode, yeah thanks for that.

There are lots of other considerations when choosing an SD-WAN vendor/platform, there is no one-size fits all so spend your time building your requirements, engaging with vendors and do a or multiple proof of concepts. What the vendor says and how the platform performs can differ considerably.

Alex

alexfray SD-WAN, VeloCloud, Zscaler

SD-WAN – A New Hope

The latest trend in the network world is Software Defined WAN (SD-WAN). By 2023 Gartner predicts 80% of organisations will have moved to SD-WAN so it’s worth taking note. So why SD-WAN? What are the drivers to bin your trusty Cisco routers and even your MPLS network.

Key Drivers

  • Applications have moved to the cloud. Traffic patterns have changed, Apps and data are moving from your on-premise data centre to the cloud, whether that be Infrastructure, Platform or Software as a Service (IaaS/PaaS/SaaS). The biggest game-changer here is Office 365.
  • Office 365 adoption is a global phenomenon. Every business is either thinking, designing or implementing their Office 365 strategy. Office 365 provides a variety of services but the key ones from a network perspective are Exchange Online, Skype for Business, Sharepoint Online and Azure AD. The problem is that most businesses neglect the network and assume it will just work with the current network and security infrastructure that they have. Typical problems include, but are not limited to:
    • Forward Proxy – Exchange Online uses multiple connections per user, typically two per mailbox and calendar. Average user probably requires 6 TCP connections. Doesn’t sound like much but times that by the number of concurrent users, then how many shared mailboxes and calendars and this can be a vast amount. Problem is your firewalls and proxies can only do between 25k to 50k NAT translations per IP so often you get port exhaustion. Note. I know the theoretical limit is 64k but check what your appliances can actually handle, its probably a lot lower when you take into account reservations. This problem is compounded as half of these connections are persistent and remain open for large periods of time not like typical web browsing behaviour. Add your general web browsing on top of this traffic and you have got between 20-30 connections per user.
    • Bandwidth – Exchange Online is hungry. On average I’ve seen 1000 users require 50Mbps of Internet bandwidth just for exchange online. Times this by the number of concurrent users in your organisation and that could be a significant amount of bandwidth and potential uplift in network and security infrastructure.
    • Microsoft best practice – Microsoft say not to proxy Office 365 traffic, no authentication, no SSL inspection as it adds latency which Exchange Online in particular does not like. If Outlook performance is poor and you raise a call with Microsoft and you have traffic traversing proxies they instantly blame your infrastructure. The only approved forward proxy is Zscaler and their one-click configuration. Microsoft also recommend 1 public IP address per 2000 users, this can also be an issue for some organisations and i’m not sure if this is still relevant now that Outlook 2013 SP1 and above uses MAPI-over-HTTPS as opposed to that piece of crap protocol RPC-over-HTTPS, so do your diligence on this point.

SD-WAN

A new hope… We have been building data centres and centralising IT infrastructure for the last 20 years. The next IT cycle is a form of network decentralisation. This is in the form of local branch Internet breakout. For years we have backhauled Internet traffic to data centres, have it traverse expensive and complex network and security infrastructure (load balancers, forward proxies, DLP, AV, SSL inspection, NGFW) before the traffic even hit the Internet. Local Internet breakout and SD-WAN offer a decentralised solution to meet the business demand for utilising cloud services, reduce cost and reliance on on-premise data centres.

Benefits

  • SD-WAN enables local Internet breakout at branch sites. Leveraging local Internet  improves latency, reduces data centre infrastructure costs and removes potential bandwidth bottlenecks attributed with backhauling.
  • The Internet is the new corporate network. MPLS circuits are typically very expensive and have a long lead time. If most of your apps are moving or are already in the cloud why should you buy an MPLS circuit? Organisations can look to buy commodity Internet or broadband services cheaper and quicker to provide access directly to cloud services. SD-WAN helps your journey from MPLS to Internet by using a hybrid deployment (MPLS and Internet) or Internet only deployment., if you need to keep your MPLS circuits for certain traffic types such as on-premise VOIP or certain business applications you could run in hybrid mode until you completely transition to an Internet-only deployment. Most organisations see this as a phased approach but it really depends on your business requirements and existing traffic flows. If you can, move to Internet-only, it’s a lot simpler from a routing perspective and you can present a good saving in the move.
  • SD-WAN can (in some Vendors) prioritise traffic. Vendors like VeloCloud, Silverpeak and Riverbed can prioritise traffic using application recognition so you can prioritise Office 365 traffic over productivity-loss applications like youtube. VeloCloud is particularly good at prioritising realtime traffic, measuring jitter and latency it will duplicate packets to fill the gaps and make the voice or video call smoother.
  • Service Chaining. Most SD-WAN vendors do not bake a Next Gen Firewall into their product. Why would they when so many are on the market. VeloCloud for example allows a Palo Alto Networks NGFW as a Virtual Network Function (VNF) on an edge device so you could have a local NGFW firewall. This doesn’t really do it for me though, imagine you had 100+ sites, that’s 100+ NGFWs to manage. What is cool, is integration with cloud security services like Zscaler. You establish a tunnel (GRE or IPSEC depending on vendor) to the security service and all your Internet traffic is tunnelled via their security service. One policy to manage, no VNF to manage and maintain, now that’s cool.
  • Bring QoS back from the dead. Yes, I know QoS is a key requirement for VOIP and Video but when we started moving to web apps and encrypting web traffic using SSL, WAN Optimization and QoS started to lose their value because all traffic looked the same, so how can you prioritise it at the network level? You can’t. SD-WAN, however can as it does it at layer-7 using application recognition and its also very easy to do using a business policy and profile as opposed to QoS which is just overly complex.
  • Simplified management. Most SD-WAN vendors provide a cloud management platform which make it very easy to manage and deploy a new WAN. The key seller here is zero-touch deployment. This makes me cringe a little bit because its not like the DHL van man can rock up at your branch site and install it. Someone need to migrate your existing LAN/WLAN equipment to the SD-WAN appliance and inevitably some backend routing/firewall changes would be required so its not really zero touch its just perhaps you don’t need a CCNP certified engineer to attend and install at each site.
    • Profiles. From a VeloCloud perspective, profiles allow you to configure a profile with a lot of standard settings that can be applied to all or a subset of edge devices so that there is minimal effort to get a new edge device up and running. Only unique config is required such as static WAN IP and VLANs.
    • Integrated PKI. Having designed and implemented Cisco PKI’s in the past, I have a sigh of relief that your SD-WAN’s PKI can be handled automatically by the SD-WAN Orchestrator. Certificates are generated on activation, can be revoked and update much more frequently without having to worry about maintaining a PKI.
    • Crypto. I reckon I’ve configured over 500 VPN tunnels over my career and the amount of time I’ve spent troublehooting mis-matched crypto settings with 3rd parties makes me sad. Not an issue with SD-WAN your crypto is set at the policy/system level so all the edge devices use the same IKE version, encryption, hashing and SA timeouts.
    • In-sourcing. Another driver for simplified management is in-sourcing. A lot of organisations are moving away from big outsourced contracts and using their in-house IT department. Now, this team might not be Cisco DMVPN experts, so SD-WAN can really help them effectively manage the WAN with very little network skills. It does help if you have some though.
    • Netflow. I love Netflow it gives some really good analytics into bandwidth usage. This is baked into the SD-WAN platform so you can see top talkers, applications used and then create your business policy to reflect conditions such as prioritising business collaboration applications and lowering file sharing applications to the bulk queue.
    • Packet Capture. On VeloCloud Edges you can perform packet captures up to 120 seconds and download them from the Orchestrator and open the pcap in Wireshark to troubleshoot any issues. That’s handy.

Negatives

Yes there are some negative to SD-WAN.

  • Product Maturity. The code is riddled with bugs. The amount of code issues I have had on VeloCloud and Riverbed platforms makes me pine for my trusty Cisco router. Vendors need to focus on stability rather than more and more features to how do the competition. If it ain’t stable, i’m not putting into production. The only saviour here is that most code issues I have identified are fixed in days not months like traditional network vendors so they are a lot more agile.
  • Expensive. Most SD-WAN vendors try and sell their product based on you reducing or removing your MPLS circuits for cheap Internet circuits. Fact is, you are unlikely to go and get broadband at all your sites its likely to be decent Internet circuits which aren’t that cheaper than MPLS circuits. SD-WAN appliances aren’t as cheap as a Cisco router. They typically have an OPEX model so you will typically buy a 3 or 5 year service as opposed to a one-off purchase of a router. Most license based on bandwidth so it really depends on the size and amount of  circuits your organisation has.
  • Service Chaining limits. Zscaler has a soft limit of 200Mbps for each IPsec tunnel and 1Gbps for each GRE tunnel. Bear in mind when choosing an SD-WAN vendor that most of them only do IPsec tunnels (Cisco Viptela, VeloCloud and Riverbed). Zscaler’s solution is to load balance tunnels if you require greater bandwidth. Now this may not be an issue for you, but some of my customers have 2000+ users in a campus so this is going to be an issue.
  • Couldn’t I just do split-tunnel DMVPN with my Cisco routers? Yes you could, but as per the benefits I’ve mentioned, SD-WAN is not just split tunnelling. I’ve not even gone into the detail about bonding multiple Internet links, 4G resilience etc. You could change your DMVPN to some kind of IWAN type solution but even Cisco is ditching this so why design a solution that even the vendor is moving away from. Cisco’s proposition is Viptela for Service Provider and Large enterprise and Meraki for small to mid enterprise. If your business has no cash and you want to be a hero with an A-Team type solution then by all means “do up the van” 🙂
  • Not everyone will be onboard. Believe it or not, not everyone is in love with the cloud. You really need key stakeholders on board for SD-WAN as it is a drastic change to typical enterprise network design. Some people want to hold onto their castle and moat network designs. This is no longer fit for purpose. Why protect the castle if your apps are outside of it?

Summary

It is very likely that your next WAN upgrade will involve SD-WAN, whether that be in hybrid mode or Internet only. Network design needs to evolve to user centric and not data centre centric. When making your product decision, make sure you gather your business and technical requirements. Not all SD-WAN vendors are the same, make sure they can do decent crypto, PKI, integration with routing protocols etc. Don’t assume anything, these device are not Cisco routers.

alexfray Zscaler

Zscaler – Zenith Live 2018 – Roadmap / Best Practices

Throughout the event I will be speaking to employees and product managers from Zscaler to get information on the next big thing, hopefully some best practices and also push for some feature requests.

Keynote from Jay Chaudhry, CEO of Zscaler

Jay talked about the cloud journey that we are all on but also the move from network centric architectures to user centric and I think that is key for businesses and engineers to understand to succeed in cloud transformation.

Zapp

Spoke to David Creedy, product manager for Zapp about current forwarding issues and roadmap for Zapp.

Roadmap – Zapp will be changing its tunnel mode from TCP to DTLS which will make it much more lightweight and improve user performance. No date on this yet.

Roadmap – Zapp user interface is being revamped and will provide the user more information. This looks more like a mobile app and shows ZIA and ZPA status in parallel which is really nice.

IMG_7953

Roadmap – Currently if you are using Zapp on-premise with no GRE/IPSec tunnelling you are NATing all clients behind a single public IP address so all clients will hit the same ZEN node, no load balancing. Coming soon you will be able to modify the PAC file to distribute the load in this scenario to multiple ZENs.

IMG_7948

Roadmap – Zapp will be able to forward all ports and protocols to the Zscaler cloud in Q1 2019 as opposed to currently where only HTTP and HTTPS traffic is forwarded. This is pretty cool for a split tunnel solution as we can now protect/restrict all ports from a device from any location. Would I want to retrospectively implement this? I’m not sure, it would take a lot of UAT to ensure we don’t break any existing connectivity. Think about it your localised SMB traffic gets thrown to the cloud, might cause some issues. Look forward to testing this though.

IMG_7951

David talked about forwarding modes for Zapp. Zscaler seem to have changed their minds on best practice from ‘tunnel with local proxy mode’ to ‘tunnel using the packet based filter’ which is a new addition in version 1.3.1 of the Zapp. The key advantage is that all system context traffic is captured and only for HTTP and HTTPS so is more optimal. Where as ‘tunnel using routing mode’ captures all traffic and can cause issues, as I have experienced in the past. This best practice also depends on the customer’s environment and if they are using an existing VPN RAS solution like Cisco AnyConnect or PAN Global Protect when you would need to use Tunnel with Local Proxy mode for traffic when off-network or on VPN. Forwarding decision definitely take some testing.

Best practice tip – Forwarding PAC – By-pass URLs in the forwarding PAC as opposed to the App Profile PAC so the browser deals with the PAC and not the Zapp as browsers are better at handling this.

Best practice tip – Zscaler also saying you should disable Zapp on trusted network and let it route over your tunnel to the Zscaler cloud. This seems debatable as how would the authentication work without the Zapp? You would have to open a browser first before Outlook for example as Outlook is not cookie aware so would appear as unauthenticated traffic which in some environments may not be allowed. Can’t see users liking this experience. I’m still in favour of tunnelling within a tunnel, so Zapp on and via a tunnel, ok there is some additional overhead but the user experience is much better.

Feature Request – Zapp Pre-Login Gina. I asked David whether it was on the roadmap for Zapp to start pre-login. Zscaler are looking to develop this which is awesome as it makes ZPA a real contender against PAN Global Protect if users can reset password with AD, GPO updates etc via pre-login. They are looking to start development on this so don’t expect it anytime soon as they need to work on a machine context for Zapp as everything is currently in the user context.

Feature Request – Zapp for Citrix Session Based Compute. Currently I use PAC files on Citrix SBC which works ok but has limitations, such as websites using connect method strips the authentication cookie. Zscaler are also looking into Zapp for session based compute so multiple users on the same server have their own Zapp context/tunnel.

Zscaler Internet Access

I visited the ZIA user interface booth and gave a load of feedback for UI improvements such as referencing CVEs in their threat library, exclusion searches and more Office 365 statistics, hopefully some of these will make it into the next release. Some cool new reports and dashboards being rolled out across the Zscaler clouds, for example a quarterly business powerpoint which is cool for senior stakeholders and you can edit it so really nice feature.

Attended the keynote from Microsoft which was really interesting as most of my customers use Azure AD and Office 365. Microsoft demo’d the CASB integration with Zscaler which is a really nice feature whereby using the Microsoft App Security portal you can effectively block access to cloud apps like dropbox by just clicking on it and this updates your Zscaler policy via an API call. This is really useful for Information and Security officers who perhaps are not hands on but want to instantly block user traffic to file sharing apps or other.

Roadmap – I have issues with a customer who uses 3rd parties which permit access via Source IP, sigh. Using Zscaler, obviously your IP comes from a pool of shared IP addresses so often the 3rd party won’t allow you to use this. As a work around, if you are luck, you can do a proxy chain in the PAC file back to your existing on-premise Proxy, but if you’ve got rid of that then you’ve got a problem. Now, really you should talk to the business and the partner about changing this control to something a bit more modern and user based like SAML but if that’s not going to happen Microsoft are baking a new feature into Azure AD Conditional Access which will allow you expose your location IP address as opposed to the Zscaler IP address, this is going to really help in these scenarios.

IMG_7954

What was also cool to see was the Microsoft network map and their peerings with Zscaler. Zscaler is peered with Microsoft in London, Paris and Amsterdam which is three data centres which I use the most which means very low latency.

IMG_7955

Attended a session where the company SFK presented their Zscaler solution using regional Internet breakouts as opposed to local Internet breakouts, using key locations where Zscaler, Akamaii and Microsoft were located such as London and Paris in Europe. SFK also used Zapp when users are On-Network so they were doing tunnel (Zapp) within a tunnel (GRE), which is a solution i’m looking to deploy, so good to know its works and performance is good.

IMG_7946

SFK also talked about routing out through the Great Chinese Firewall which was really interesting the issues you will have trying to egress out of china, especially around latency and packet loss as if the great firewall is overloaded, scary stuff.

IMG_7947

Roadmap – The Cloud Firewall if you have the advanced license does IPS for all ports. Coming soon is SNORT integration and a bit later the ability to add your own SNORT rules which is handy if you get advanced notification of threats from people like NCSC. In the meanwhile you can send Zscaler the SNORT rules and they will implement them for you.

Tech note – Skype traffic was brought up regarding latency as Zscaler can add up to 100ms latency. This is obviously unacceptable from a voice/video perspective so is not as inspected as web traffic to provide better latency to this type of UDP traffic.

Tech note. sub locations and countries. So one customer I have wanted to preface the data centres that could be used by clients. So in the PAC file you can change the $gateway setting to a specific data centre like lon3.sme.zscalerone.net. The reasoning is to ensure traffic is traversing a DC in a trusted country. However you don’t get the geo-location so users working in a different country would have a poorer experience because of the increased latency. Now you could introduce rules in the PAC file to combat this but if their travel is dynamic then this is not scalable. A solution for this is for Zscaler to allocate you a sub-cloud. This is purely a whitelist of ZEN nodes you can use, so you can raise a ticket and say I want London, Paris and Amsterdam only and change your PAC to customerdomain_$gateway. That’s pretty cool. Another alternative is to use the following $gateway_country. This parameter doesn’t chose the ZEN via geo location or lowest latency but by what country you are in which gives you more control with very little config.

I got the PAC file information from Yogi at Zscaler, that guy knows his stuff, if you ever get to meet him you can get a lot of answers and put your requests to him.

Network Transformation – Hub and Spoke to a Hybrid network

When we talk about hybrid networks we are talking about local Internet break-out at branch sites and SD-WAN and how goliaths like Siemens have moved to the model of Internet as the Corporate Network. Why are we changing from hub and spoke to SD-WAN? Because workloads are moving to the cloud. in the 90s/00s all the apps were in the data centre but now companies are migrating apps to SaaS, Public Cloud and Private cloud, the traffic pattern has shifted to the Internet and the network needs to adapt to reflect this.

Some interesting points made at the network transformation session around the types of Internet circuits being procured at branch sites. Circuits ranging from carrier grade to broadband, how do you procure these internationally, who makes the decision on the grade of circuit. These are business decisions, but it is rare to get a customer to make these decisions. This needs to be driven technically and justified to the business.

Siemens and Orange Business Services presented their network transformation journey using Zscaler and SD-WAN. The project plan below is really good and could be applied to most customer deployments.

img_7944.jpg

alexfray SD-WAN, Zscaler

Zscaler – Zenith Live 2018 – SD-WAN

We are at Zenith Live at Heathrow this week to check out the latest Zscaler features and roadmap as well as to give them some grief on some of the issues we’ve had on customer implementations.

21/10/18 – SD-WAN Integration Training

Spending my Sunday configuring IPSec VPNs to Zscaler from Cisco Viptela and Riverbed SD-WAN appliances, now that’s dedication. I’m at the SD-WAN training session today to get a feel for other SD-WAN providers and see how they compare to VeloCloud.

Roadmap – Zscaler allows SD-WAN vendors to link in via API calls. Both Riverbed and VeloCloud should have this integration in Q1 2019. What does this give you? Well it means the VeloCloud Orchestrator can automatically configure the VPN Credentials and Location in the Zscaler admin portal using an API call. Another provisioning step automated.

Riverbed Lab

13:04 Brandon Carroll, Senior Technical Evangelist from Riverbed is up next. I’m excited to hear the visionary imaginearing he’s been doing in his role 😀 To be fair Riverbed are pushing SD-WAN hard, and so they should or they will fold with the WAN Optimisation market dying, if not already dead. Companies who have already invested in Riverbed will probably be looking at their platform but I can’t see why you would otherwise.

Initial thoughts, the Riverbed Steelhead Manager, which is the Riverbed Orchestrator, looks pretty good. Their network map shows all the sites status and the VPN tunnels between the sites, which is really neat when compared to the VeloCloud network map which is really basic and lacking info. The map might get messy on a large deployment but does look cool and handy to see established tunnels. The Zscaler configuration is very simple and you get a lot of information such as events and latency to the chosen Zen nodes. There is a balance here, the manager is rather cluttered and overwhelming with tabs and options, there is a lot going on but also a lot of useful information so it really depends on what you want. It looks very complicated in comparison to VeloCloud however I do wish VeloCloud had more information and stats.

The Riverbed lab was pretty good to get some hands on the Riverbed SD-WAN. Like VeloCloud it is very easy to connect to Zscaler. The dashboard is pretty slick to be fair (screenshot below).

river-1.png

Ok speaking to the evangelist, its starting to fall apart. The Riverbed solution is full mesh only or to the hub only. Now this means in full mesh mode the smallest site would need to connect to every site. So the hardware spec of your smallest site depends on how many sites you have so you may need a large appliance at a small site because you have so many sites/tunnels to support. That doesn’t seem very scalable for a large deployment. How much branch-to-branch traffic do you really have? Its only voice these days really so why not make it dynamic tunnels to reduce the overhead.

Cisco Viptela Lab

15:02 No representative from Cisco to push Viptela which is a shame but nonetheless we deep dive into Viptela configuration. If you want an SD-WAN solution which is pretty much the same as configuring a Cisco ISR router then this is for you. Personally I don’t see the point. One of the main goals of moving to SD-WAN is to simplify branch site administration and yes I know you can use templates but there are a lot of templates. If you need this type of granularity then maybe this is for you. Viptela is really aimed at Service Providers / Large Enterprises and it has the price tag to match. It is cool to see exactly what code is being pushed to the devices instead of just hitting a button and just hoping the magic happens as with VeloCloud and Riverbed and the Cisco geek in me loves to reminisce over DMVPN rollouts and CLI but I just don’t see it for SMBs or small to mid enterprises.viptela-1

The integration with Zscaler was fairly easy but a lot more convoluted then VeloCloud and Riverbed. I had to create two feature templates and modify my routing feature template then bind to my device template. When you have more templates than devices the dynamic is wrong.