3.2. Creating an Inline Layer 3 Service¶
3.2.1. What it is¶
An inline layer 3 service is defined by the following primary characteristics:
Layer 3: It assigns IP addresses to network interfaces and participates in traffic routing.
Inline: It has physically or logically separate inbound (to-device) and outbound (from-device) interfaces.
Many modern security products fit into this category, including products by Cisco, Palo Alto, Fortinet and Checkpoint. Inline layer 3 devices route traffic, and can modify or break (i.e. reset, drop) that traffic in real time. The SSL Orchestrator routes traffic to the service from one VLAN, and the service will typically gateway route the traffic back to the F5 BIG-IP on another VLAN.
3.2.2. How to build it¶
Either from a topology workflow or directly under the Services tab in the SSL Orchestrator user interface, click the Add button to create a new inline layer 3 service.
Inline Layer 3 Service
Choose an inline layer 3 service from the catalog or select the “Generic Inline Layer 3” service and click the Add button.
Provide a name for this service.
Optionally provide a description.
Choose between IPv4 and IPv6.
Auto Manage Addresses
When enabled the Auto Manage setting provides a set of unique, non-overlapping, non-routable IP addresses to be used by the security service. If disabled, the To Service Configuration and From Service Configuration addresses must be defined manually. It is recommended to leave this option enabled (checked).
To Service Configuration
This setting defines how traffic flows to the inline service, by which VLAN and IP subnet. The IP address assigned here represents the F5 BIG-IP VLAN self-IP and the to-service side subnet to be used on the layer 3 device.
Service Down Action
Optionally select an alternate service down action. This setting defines what happens if all devices in a service pool are down and will either ignore (skip this service in the chain), reset, or drop the traffic.
This setting defines the entry point IP address of the layer 3 service, defined on its “to-service” interface. Multiple IP addresses can be assigned here to load balance multiple layer 3 devices. Click the Done button to add each device.
Optionally define an alternate monitor. In most cases the default gateway_icmp monitor is preferable for inline layer 3 services.
From Service Configuration
This setting defines how traffic flows back to the F5 BIG-IP from the inline service, by which VLAN and IP subnet. The IP address assigned here represents the F5 BIG-IP VLAN self-IP and the from-service side subnet to be used on the layer 3 device. This IP address will also be the gateway IP address on the layer 3 device.
Enable Port Remap
Enable port remapping for detected HTTPS traffic. This will remap any decrypted HTTPS traffic to the chosen port.
Manage SNAT Settings
Optionally enable source address translation across this service.
Optionally insert additional iRule processing. No additional iRules are required.
Click Save & Next to proceed.
The workflow will proceed to the Service Chains page to allow adding of this new service to a service chain. Once complete here, if in a topology workflow click Save & Next to continue. If adding the service directly, click the Deploy button.
3.2.3. How it works¶
An inline layer 3 service routes traffic through physically or logically separate interfaces. Unlike a layer 2 device, layer 3 devices expose IP addresses and participate in routing. And unlike passive TAP devices, are able to affect the traffic in real time. They may, for example, drop/reset a traffic flow, rewrite/scrub content, or generate blocking page actions. The SSL Orchestrator dynamic service chain mechanism freely allows all of these actions to work as expected. If an inline service resets the traffic, that reset action will cascade out to the client and server. If the inline service generates a blocking page, that page will be sent to the client.
Service Properties - the Service Properties page represents a Service Catalog of validated product integrations and represents each of the five security product types. If your security product is not listed, there are also “generic” service icons at the bottom of the catalog.
Auto Manage Addresses - in environments where SSL Orchestrator is introduced to existing security devices, it is a natural tendency to want to leave these devices where they are. While SSL Orchestrator certainly allows this, by not moving the security stack into “protected enclaves”, you run the risk of exposing sensitive decrypted traffic to other devices that may be connected to these existing networks. It is therefore highly recommended, and a security recommended practice, to re-locate and isolate these security products. The SSL Orchestrator service configurations provide this isolation through sets of unique, non-overlapping, non-routable IP addresses. The Auto Manage Addresses option enables and disables this protection feature. When enabled, the service configuration defines the internal RFC2544 addressing that the services will use. When disabled, IP addressing must be defined manually.
To Service Configuration - with the Auto Manage Addresses option enabled, this IP address will be pre-defined, therefore the to-service interface of the service must match this IP subnet. SSL Orchestrator uses an RFC2544 internal, non-routable address space (198.19.x.y/19). With the Auto Manage Addresses option disabled, the IP addresses must be defined manually. This assigned address specifies the F5 BIG-IP VLAN self-IP from which traffic will be flowing to the service.
Service Down Action - a security service defines a pool of one or more load balanced and monitored devices. Depending on the state of the monitor, a different action may be taken. It may be most appropriate, for example, to simply bypass a failed service (i.e. all of the members are down) in order to maintain availability.
Security Devices - an inline layer 3 service may be defined as the load balances set of multiple devices on the same IP subnets. Minimally one device IP must be defined.
Device Monitor - as stated, the service configuration builds a layer 3 path to an inline layer 3 device. Thus, a typical monitor for this type of device sends a health check directly to the device.
From Service Configuration - with the Auto Manage Addresses option enabled, this IP address will be pre-defined, therefore the from-service interface of the service must match this IP subnet. SSL Orchestrator uses an RFC2544 internal, non-routable address space (198.19.x.y/19). With the Auto Manage Addresses option disabled, the IP addresses must be defined manually. This assigned address specifies the F5 BIG-IP VLAN self-IP to which traffic will be flowing from the service back to the F5 BIG-IP. This IP address should also be the gateway routing address on the layer 3 service to ensure all traffic is sent back to the F5 BIG-IP.
Enable Port Remap - most modern security products will define a set of “default” actions for traffic arriving on different known ports. For example, traffic arriving on port 80 will be assumed to be unencrypted HTTP and inspectable. However, port 443 will normally be encrypted HTTPS, so will not be inspected. Should the SSL Orchestrator decrypt HTTPS and continue to send that unencrypted traffic on port 443 to the inline service, that service may continue to ignore it. Or worse, a policy change would be needed to allow it to inspect 443, and any other possible port that HTTPS traffic may be on. The Enable Port Remap option provides a mechanism to simply and temporarily remap the destination port of decrypted HTTPS traffic passing across this service. For example, you might set this to remap HTTPS to port 8080 to allow the service to see this as inspectable HTTP.
Manage SNAT Settings - this optional setting enables source address translation across the layer 3 service. It is unusual to enable source address translation however this setting is most useful when a single layer 3 service is shared between non-HA SSL Orchestrator appliances. The setting would apply a unique source IP address from each SSL Orchestrator appliance to aid in policy routing.
iRules - iRule logic can be defined at multiple strategic points within an SSL Orchestrator configuration. An iRule attached at the service level specifically targets traffic flowing across this service. iRules are an extremely powerful tool for manipulation and observation of real time traffic flows. You could, for example, insert an iRule to produce additional logging, insert or remove headers, or to inspect and/or act on some values in the request or response. Keep in mind here that an iRule inserted at a service is interacting with the flow at that service and should not be used to control flow, though it could be used to generate a reset or blocking page. iRules used here are intended to work primarily at the application layer (ex. HTTP).
3.2.4. Routing Considerations¶
Within the SSL Orchestrator service chain, and in the absence of SNAT, a layer 3 security service will consume IP traffic sourced from the true client IP and destined for the true destination IP. The layer 3 security service must have a route to pass all unknown traffic (i.e. traffic to the Internet in a forward proxy scenario) to its outbound interface. And unless it possesses some form of layer 2 “return-to-sender” function, it may also require a separate route to send return traffic (to the client’s IP) through its inbound interface. As an example, take the following scenario:
Client IP subnet: 10.1.10.0/24
Service inbound subnet: 198.19.64.0/25 (F5 self-IP is 198.19.64.7)
Service outbound subnet: 198.19.64.128/25 (F5 self-IP is 198.19.64.245)
The service’s route table should minimally look like this to send Internet-bound traffic to the service’s outbound interface (eth1), and return traffic to the service’s inbound interface (eth0).
Destination Gateway Genmask Flags Metric Iface
default 198.19.64.245 0.0.0.0 UG 0 eth1
10.1.10.0 198.19.64.7 255.255.255.0 UG 0 eth0
The above example is dependent on the configured traffic flow. For forward proxy, Internet-bound traffic would normally be the request (internal client request to Internet server). For reverse proxy, Internet-bound traffic would normally be the response (internal server response to Internet client). Configure the above routing according to desired traffic flow.
3.2.5. Additional Information¶
For traffic to traverse an inline layer 3 service in a manner that provides full and native load balancing and active health monitoring, the SSL Orchestrator configuration defines a routing path to the layer 3 service. Address translation is disabled across the listener virtual servers to allow traffic to flow without manipulation of source and destination addressing (no SNAT or NAT). Destination port translation is enabled or disabled for decrypted HTTPS via the Port Remap option, otherwise destination ports also do not change. Source ports are only changed if the inline service is behind an explicit forward proxy topology. Packets are routed to the to-service interface of the layer 3 service, which then (gateway) routes the traffic back to the F5 BIG-IP on its from-service interface. A layer 3 security product will usually also support 802.1Q VLAN tagging, thus physical port connectivity can be reduced by creating logically separate tagged VLANs across a single physical interface.