4.20. Implementing Service Control Channels

4.20.1. What it is

The service configuration for inline L3, inline HTTP, and off-box WAF inspection services incorporates a service control channel definition, enabling you to create service control channel pathways. When a security device requires an explicit connection to external resources, the service control channels allow device-initiated traffic to egress to the Internet. When you deploy a service configuration with a service control channel, the required destination-side listener (a virtual server) is created, and it is auto-bound to the destination-side VLAN of the service. The typical use case for a service control channel is when an inspection service needs direct access to Internet resources. This may be, for example, when a proxy device needs access to external DNS, or an inspection device needs to “phone home” to ensure active licensing and/or to retrieve software and malware signature updates. Under normal conditions, SSL Orchestrator maintains state information for all traffic moving through inspection services. If a service initiates its own traffic, that traffic would not have applicable state information, thus would not be allowed. A service control channel sets up a listener configuration for specific flows to enable service-initiated traffic to escape to defined targets.

4.20.2. How to build it

In the inline L3, inline HTTP, and off-box WAF inspection service configuration pages, the service control channel settings provide entries to define flow patterns. For each pattern, you can specify some combination of:

• Source IP and subnet mask - typically the outbound IP address of the inspection service(s)

• Destination IP and subnet mask - typically the discrete destination

• Destination port

• Protocol - TCP or UDP

• SNAT pool/SNAT settings - whether or not to apply SNAT to this outbound traffic

• Gateway pool - the routed path for this outbound traffic

Figure 107: Service Control Channels

As the image illustrates above, a service control channel pattern is defined as the inspection service’s source address, going to 8.8.8.8 for UDP-based DNS on port 53. This outbound traffic requires SNAT, and may either specify a separate gateway pool, or use a system-defined gateway.

Note that it is important not to define these patterns too wide, so that regular client-server traffic does not unintentionally pass through the service control channel. For example, setting the source address to a wildcard (0.0.0.0/0) and destination port to 80, might incorrectly allow unencrypted HTTP client-server traffic to enter the service chain, but then attempt to exit through the service control channel. A common pattern would be to define the IP address of the inspection service (outbound IP) as the source address, assuming the inspection service does not apply SNAT (source IP translation) on traffic passing through it. In this case, the service control channel would correctly only catch traffic originating from the inspection service.