What type of transaction exist in Cloud SWG and which transactions are saved in the access logs?
Article ID: 278633
Updated On:
Products
Issue/Introduction
The Cloud SWG pods are based on Edge SWG secure-web gateways (aka proxy devices).
In the Edge SWG devices many type of transaction exist how not all of them are visible in the Cloud SWG access logs.
In this KB article we will create a list of possible transaction (relevant for the customer flows) and indicate which are stored in the access logs, how and when.
Environment
Cloud SWG
Resolution
Edge SWG transactions are anytime a service is handling a client request:
- "tcp.tunnel" transactions are created when a transparent proxy request is received
- "http.proxy" transactions are created for all standard http requests including explicit proxy connect requests
- "ssl.tunnel" transactions are created to handle the SSL flow from the client to the proxy (in case of intercept) or to the server
- "ssl.intercept" transactions are created to validate if interception should take place or not
- when TLS interception is needed the ssl.tunnel transaction creates the TLS interception and forwards any request form the TLS session to the https proxy
- when TLS interception is bypassed the ssl.tunnel transaction is used to forward the TLS handshake to the destination server
- "https.forward-proxy" transactions are created for any new request received within a TLS session
All of this information is of great interest to understand the request processing on the device and for troubleshooting policies but the access logs are recording transactions that are "relevant" to the client-server exchanges only, namely:
- tcp or http.proxy connect requests are logged
- ssl tunnel transactions are logged if TLS interception is bypassed
- https transactions are logged for all TLS intercepted requests
Additional Information
The access logs are written at the end of the transaction (once it is complete) so with the tcp and ssl tunnel or https transaction time it is possible to approximate a specific request duration.
For example you can see 2 downloads in [1] where the "tcp://" (http.proxy transactions as the request was running from an Explicit proxy locations) time indicate the approximate download start and the "https://" (https.forward-proxy transaction) indicates the approximate download end.
Looking at the data in [1] we have:
- download start time of 12:23:37 for the netboot file
- download end time of 12:23:48 for the netboot file
- download start time of 12:18:29 for the desktop file
- download end time of 12:22:54 for the desktop file
And we can then calculate
- netboot file download duration of ~12s (using the least favorable case: 48.999 - 37.000 = 11,999)
- netboot download throughtput: (117.8 * 8) / 12 ~78 Mbps
- desktop file download duration of ~266s (using the least favorable case: 22:54.999 - 18:29.000 = 04:25,999)
- desktop download througtput: (4.8 * 1024 * 1024 * 8) / 266 ~147Mbps
The above calculation actually match the curl output for both files downloads:
curl --insecure -o /dev/null -x proxy.threatpulse.com:8080 https://releases.ubuntu.com/23.10/ubuntu-23.10.1-desktop-amd64.iso
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 4934M 100 4934M 0 0 18.5M 0 0:04:26 0:04:26 --:--:-- 28.8M
curl --insecure -o /dev/null -x proxy.threatpulse.com:8080 https://releases.ubuntu.com/23.10/ubuntu-23.10-netboot-amd64.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 111M 100 111M 0 0 9712k 0 0:00:11 0:00:11 --:--:-- 15.8M
[1] Access log view from the Cloud SWG portal for tcp and https transactions to download an Ubuntu ISO
Feedback
