Subscribe for our Newsletter

In order to comply with privacy regulations in the European Union we’ll need you to provide consent before confirming you to our email list:

I consent to receive newsletter emails about our content and services.

We’ll send you occasional emails about new episodes, blogposts, partnerships and they might contain promotional content.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Traffic Back Hauling

November 13, 2020
Evgeniy Kharam
VP of Solution Architecture

The following number of short articles will describe several options of modern architecture to secure users’ traffic to the internet and back to the corporate office or company Datacenters (DC). In each scenario, I will describe the PROS and CONS with each, Identity Access Management (IAM) consideration and point important architecture nuances that one should be aware of during design or High-level architecture.

Part 1: Traffic Back Hauling

The picture below shows a traditional backhauling architecture where users connect back to the main environment remotely. In most cases, users need this connection to perform day by day work if they work remotely or travel. Another popular reason is that customer policy dictates that all the traffic has to go back to the mainland for inspection before it hits the internet and SaaS applications.

Technical terminology for such connection will be “full tunneling”, when all the traffic is forced to the main DC and “split tunneling” when only traffic that is work-related is forced to the DC. In full tunneling, there is an option to enable “Always on” mode that basically means that the moment end-user device has an internet connection, it will automatedly connect without user prompt.

Basic authentication will be done using username and password, while most of the companies adopted the multi-factor authentication as a standard a long time ago. In most cases, the second factor is a certificate deployed on the end-user machines, hard tokens, or soft tokens on the phone. There is also an additional check that can verify the machine and not just the user by “host checker”. In this case, the Remote Access VPN GateWay/Firewall will check certain configurations on the client machine, and only then allow it to connect to the network. Popular checks are: if the Antivirus (AV) up to date if the device is part of a company domain and/or if the device is patched.

From protocols perspective, majority of the remote access products will use Secure Sockets Layer (SSL) where there is no need to deploy a permanent client and Internet Protocol Security (IPsec) that uses full client on the customer environment


  • Simple well-known architecture
  • Customer owns all the parts of the architecture
  • SLA (Service-level agreement) and Availability are depend on the customer
  • For “Always on” customer maintains the same security controls as in-office and therefore the same security policy


  • Traffic latency could be high, depends on where, geographically, the end-user connects and where the user browses the internet
  • User Experience could suffer because of traffic latency
  • When traffic goes to the Datacenter and then to the internet, it uses double the bandwidth and also impacts the firewall load
  • Not good for “ Bring your own device” BOYD in most cases

Popular Vendors in this space

  • All the main Firewall vendors: Cisco, Palo Alto Network, Checkpoint, Fortinet
  • All the main Load Balancer — F5, Citrix (NetScaler)
  • Dedicated Remote access platforms, such as Pulse (Former Juniper)