Manual Chapter : Creating Services Service Chains and Classifier Rules

Applies To:

Show Versions Show Versions

F5 SSL Orchestrator

  • 13.0.0
Manual Chapter

Overview: Creating services, service chains, and classifier rules

This section decribes how to create inline services, ICAP services, receive-only services, service chains, and classifier rules.

Creating inline services for service chains

Before creating inline services, complete all areas in General Properties. Refer to the Configuring general properties section of this document for more information.
Inline services pass traffic through one or more service devices at Layer 2 or Layer 3. You use inline services in service chains, where each service device communicates with the BIG-IP® device, on the ingress side and over two VLANs. These VLANs route traffic toward the intranet and Internet, respectively.

Layer 3 inline services requires you to provide the IP address of the service devices from the present choices in the Herculon SSL Orchestrator configuration. If you are using Layer 3 inline services, this configuration sends and receives information from the services using a pre-defined set of addresses.

  1. On the Main tab, click SSL Orchestrator > Configuration , and on the menu bar, click Services > Inline Services to view inline services settings.
    The Inline Services screen opens.
  2. Options to provide the IPv4 (CIDR/19) subnet-block base address, the IPv6 /48 subnet-block prefix, or both, will vary, whether you selected Support IPv4 only, Support IPv6 only, or Both IPv4 and IPv6.
    • In the What is the IPv4 (CIDR/19) subnet-block base address? field, type the address block. F5 recommends the default block 198.19.0.0/19 to minimize the likelihood of address collisions.
      Note: When using Layer 3 inline services, you must address your systems to match the required ranges. Even though you can change the base address of each address block (IPv4) from which subnets and addresses are assigned, changing an address block has several implications, must be done with caution, and is not recommended or supported by F5.
    • In the What is the IPv6 /48 subnet-block prefix? field, type the address block.
      Note: Each inline service goes through one or more services at Layer 2 (LAN) or Layer 3 (IP). Each service device communicates with the BIG-IP device on the ingress side over two VLANs (from BIG-IP and to BIG-IP) that carry traffic toward the intranet and the internet, respectively.
    • In both the What is the IPv4 (CIDR/19) subnet-block base address? and What is the IPv6 /48 subnet-block prefix? fields, type the necessary address block information.
  3. Click Add.
  4. In the Name field, type a name for your configuration.
    Use a short, unique name for this service. This name can contain 1 -15 alphanumeric or underscore characters, but must start with a letter. Letters are not case-sensitive.
  5. From the Service Type list, select Layer 2 or Layer 3.
  6. In the Interfaces area, select the BIG-IP system interface and VLAN tag for each VLAN pair.
    Each Inward VLAN must be connected to the same Layer 2 virtual network from every device in the Sync-Failover Device Group, and each Outward VLAN likewise, but to a distinct Layer 2 virtual network.
    If you choose to use the Ratio field, the BIG-IP system distributes connections among pool members in a static rotation according to ratio weights that you define. In this case, the number of connections that each system receives over time is proportionate to the ratio weight you defined for each pool member or node. This number must be between 1-100.
    For example, if you have five devices and you assign a ratio of 1 to the first three devices, and a ratio of 2 to the fourth device, and a ratio of 3 to the fifth device; the first three devices with a ratio of 1 each receive 1/8 of the traffic. The fourth device receives 1/4 of the traffic, and the fifth device receives 3/8 of the traffic.
  7. Under Available Devices, from the IP Address list, select the IP address pairs of the Layer 3 devices and click Add to add them to the IP Address field.
  8. From the Translate Port for HTTP Traffic list, select one of the options.
    • Use No if the connections should use their original destination ports.
    • Use Yes to Port 80 to send all HTTP traffic through port 80.
    • Use Yes to Port 8080 to send all HTTP traffic through port 8080.
    • Use Yes to Port 8443 to send all HTTP traffic through port 8443.
  9. From the Connection Handling On Outage list, select one of the following:
    • Use Skip Service to allow connections to skip the service you are configuring if all the devices in the service are unavailable.
    • Use Reject Connection for the system to reject every connection reaching the service when the service is down.
  10. Click Finished.
  11. Click Save.
    Note:

    Layer 3 devices need to follow a specific fixed addressing scheme. For each of the 10 possible Layer 3 inline services, you need to use the following configuration (with x being 0-9 representing the inline service):

    Inward Interface:
    • IPv4 Address: 198.19.x.61 through 68 (for each of the load balanced Layer 3 devices)
    • IPv4 Netmask: 255.255.255.128
    • IPv6 Address: fd06:4d61:x::41 through 48 (for each of the load balanced Layer 3 devices)
    • IPv6 Netmask: ffff.ffff. ffff.ffff. ffff.ffff. ffff.ff00
    Outward Interface:
    • IPv4 Address: 198.19.x.161 through 168 (for each of the load balanced Layer 3 devices)
    • IPv4 Netmask: 255.255.255.128
    • IPv6 Address: fd06:4d61:x::141 through 148 (for each of the load balanced Layer 3 devices)
    • IPv6 Netmask: ffff.ffff. ffff.ffff. ffff.ffff. ffff.ff00
    Routes:
    • Default Gateway: 198.19.x.245
    • Gateway to internal networks: .1

    While the base address can be changed if needed, F5 recommends leaving it set to the default: 198.19.0.0.

You have now configured an inline service for Herculon SSL Orchestrator.
After creating more than one service, you can now create a service chain.

Creating ICAP services

Before creating ICAP services, complete all areas in General Properties. Refer to the Configuring general properties section of this document for more information.
ICAP services use the RFC3507 ICAP protocol to refer HTTP traffic to one or more content adaptation devices to inspect or modify. You can add an ICAP to any TCP service chain, but only HTTP traffic is sent to the chain. Additionally, you can configure up to ten ICAP services using the Herculon SSL Orchestrator configuration utility to load balance across them.
  1. On the Main tab, click SSL Orchestrator > Configuration , and on the menu bar, click Services > ICAP Services to view ICAP services settings.
    The ICAP Services screen opens.
  2. Click Add.
  3. In the Name field, type a name for your configuration.
  4. In the ICAP Devices field, type an IP address and port number and click Add.
  5. For Headers, from the Mode list, select either Default or Custom.
    To edit the headers, use Custom.
  6. From the TCP Connections list, select F5®OneConnect™ or Separate.
    Use OneConnect to reuse the TCP connections to ICAP servers, which processes multiple transactions. If your ICAP servers do not support multiple ICAP transactions per TCP connection, select Separate. OneConnect will then be disabled.
  7. From the Type list, select either Load Balanced or Custom.
    • If you select Load Balanced, the Request and Response fields are prepopulated with keywords that will be automatically replaced by the configured active ICAP server and port at the time of the request. The specific page name for the request and response must be manually entered to complete the URI. For example, if the request URI for the ICAP servers will be “icap://10.1.2.3:1344/REQ”, you enter “REQ” in the request field.
    • If you select Custom, the Request and Response fields are empty and the entire URI content must be manually entered. In this case, Herculon SSL Orchestrator will not load balance traffic across the configured ICAP servers. For example, if the request URI for the ICAP server will be “icap://icap.example.com/request”, you enter the entire URI into the request field.
  8. In the Request and Response fields, type the ICAP request and response URI, defined by RFC3507, that are related to the ICAP server and based on whether you selected Load Balanced or Custom in the previous step.
  9. In the Preview Max. Length (bytes) field, type the number of bytes that are in the maximum length for the ICAP preview.
    Bytes of content, up to the specified number, are sent to the ICAP server as a preview of each HTTP request or response. If you set the maximum preview length to zero (0), then requests and responses are streamed through the ICAP server. The largest value currently supported is 51200 (50KB).
  10. From the Server Failure Handling list, select Reset Connection or Next Service Chain.
    • Use Reset Connection for the system to reset the connection to the client, discarding the request and response.
    • Use Next Service Chain for the system to let the request or response continue to the next service in the service chain.
  11. From the Send HTTP/1.0 Requests to ICAP list, select how to send requests to the ICAP service.
    • Use HTTP/1.0 & HTTP/1.1 to send both HTTP/1.0 and HTTP/1.1 requests to the ICAP service.
    • Use HTTP/1.1 only to send only HTTP/1.1 requests to the ICAP service. Any HTTP/1.0 requests are not inspected.
  12. Click Finished.
  13. Click Save.
You have now configured an ICAP service.
After creating more than one service, you can now create a service chain.

Creating receive-only services for traffic inspection

Before configuring receive-only services, complete all areas in General Properties. Refer to the Configuring general properties section of this document for more information.
Receive-only services only receive traffic for inspection and do not send the traffic back to the BIG-IP® system. Each receive-only service provides a packet-by-packet copy of the traffic passing through the service to an inspection device. You can configure up to ten receive-only services using the F5® Herculon™ SSL Orchestrator™ configuration utility.
  1. On the Main tab, click SSL Orchestrator > Configuration , and on the menu bar, click Services > Receive Only Services to view receive-only services settings.
    The Receive Only Services screen opens.
  2. Click Add.
  3. In the Name field, type a name for your configuration.
  4. In the MAC Address field, type the MAC address of the receive-only device.
  5. In the IP Address field, type the nominal IP address for this device.
    Each receive-only device requires a nominal IP host address to identify the device in the BIG-IP system.
  6. From the VLAN list, select the VLAN where the receive-only device resides.
  7. From the Interface list, select the associated BIG-IP system interface.
  8. Click Finished.
  9. Click Save.
You have now created a receive-only service for Herculon SSL Orchestrator.
After creating more than one service, you can now create a service chain.

Creating service chains to link services

Before you can set up service chains, you must configure multiple services such as inline, ICAP, or receive-only.
You can create service chains using previously-created services. A service chain is a list of services linked to service chain classifier rules. Service chains process specific connections based on classifier rules that look at protocol, source, and destination addresses. Additionally, service chains can include the following types of services, as well as any decrypt zones between separate ingress and egress devices:
  • Layer 2 inline services
  • Layer 3 inline services
  • Receive-only services
  • ICAP services
  1. On the Main tab, click SSL Orchestrator > Configuration , and on the menu bar, click Policies to view service chain settings.
    The Service Chain information on the Policies screen opens.
  2. Click Add.
  3. In the Name field, type a name for your service chain.
    Create a short name for this service chain. A service chain name may contain 1-15 alphanumeric or underscore characters and must start with a letter (not case-sensitive). Use spaces or commas to separate service names.
    Note: You cannot use any of the keywords "all", "bypass", "reject", or "drop", nor the name of any (inspection) service you previously configured as a service chain name.
  4. In the Services area, select a Type and Name and then click Add.
  5. Click Finished.
  6. Click Save.
You have now configured a service chain.
After you create a service chain, configure either TCP or UDP classifier rules.

Creating TCP service chain classifier rules

Before you create a TCP service chain classifier rule, you must create one or more service chains.
Service chain classifier rules determine which service chains receive traffic. Each service chain classifier rule selects the specific chain to process ingress connections. Different classifier rules can send connections to the same chain. Each classifier has three filters that match the source IP address, the destination, and the application protocol. Filters can also overlap, so the best matching classifier determines the service chain for a specific connection. Finally, classifiers can reject a connection or allow it to bypass the service chain.
  1. On the Main tab, click SSL Orchestrator > Configuration , and on the menu bar, click Policies to view TCP service chain classifiers settings.
    The TCP Service Chain Classifiers information on the Policies screen opens.
  2. In the TCP Service Chain Classifiers area, click Add.
  3. In the Name field, type a name for this rule.
  4. From the Phase list, select a phase for this classifier.
    • Use Normal if the rule may match TLS connections at TLS handshake time and possibly again, more specifically, after Herculon SSL Orchestrator exposes the plaintext of the TLS connection (so you can manage HTTPS on nonstandard ports, for example). Normal rules may also match non-TLS traffic (so, for example, a single rule can handle both HTTPS and HTTP).
    • Use No TLS if the rules match only non-TLS traffic.
    • Use Pre Handshake to have the rules match before any TLS handshake. This means the rules can allow a connection to bypass SSL inspection completely,without even trying to learn the real name of the remote server. All Dynamic Domain Bypass (DDB) rules must have Phase set to Pre Handshake.
    • Use TLS Handshake rules to have the rules match only at TLS handshake time: they will never match non-TLS traffic, and they are not checked again after the plaintext of a TLS connection becomes available.
  5. From the Protocol list, select the protocol of the connection based on the port number or protocol recognition.
  6. In the Source area, select a Type and a Value.
    This option specifies the name of the Service Chain you configured that you want to use for this classifier rule. From the Type list, select one of the following and then click Add.
    • For IP Address, type the required IP address in the Value field.
    • For Data Group, select the name of your data group from the Value list.
  7. In the Destination setting, select a Mode, Type, and Value.
    This option specifies the destination of the connection. The value of this field is based on the selection you made for the mode.
    • From the Mode list, select the mode you want to use for this classifier rule. The mode you choose determines the value you will use for the destination. You can choose one of the modes for each classifier rule:
      • For Address, the Destination filter you configure consists of one or more IP subnet or host addresses just like the Source filter.
      • For Geolocation, the Destination you configure contains 2-letter country and 3-letter continent codes against which the IP Geolocation of the destination server is compared. The continent codes are: CAF=Africa, CAN=Antarctica, CAS=Asia, CEU=Europe, CNA=North America, COC=Oceania, CSA=South. The country codes are those of ISO 3166 alpha-2.
      • For IPI (IP Inspection), the Destination you configure contains one or more IP Intelligence categories against which the destination IP address's reputation is matched. You must replace SPACE characters in names of IP Intelligence categories with underscores (_) before adding them to Destination.
      • For Port, the Protocol value must be All. The Destination contains one or more TCP port numbers or ranges like 5557-5559 (use 0 or * to match all) against which the destination port number is matched. The main use of this mode is to control non-TLS traffic such as SSH.
      • For URLF (URL Filtering), the Destination you configure is one or more URL Filtering categories against which the URL categorization of the destination server is compared. You must replace SPACE characters in names of URL Filtering categories with underscores (_) before adding them to Destination.
      • For DDB (Dynamic Domain Bypass), the Destination you configure contains one or more DNS domain names (unique or wildcard) against which the destination hostname indicated by the client in TLS SNI is matched. This mode is special because it classifies traffic before the Herculon SSL Orchestrator implementation attempts any TLS handshake with the remote server (that is, in Match Phase Pre-handshake). You may use DDB to whitelist and bypass traffic to servers which cause TLS handshake problems or that require TLS mutual (client-certificate/smart-card) authentication. For DDB, the Service Chain value you select must be Bypass or Reject.

        For security, the DDB facility ensures the destination IP address for each bypassed connection corresponds to the allowed domain. DDB may replace the destination IP address supplied by the client with one freshly obtained from DNS.

      • For Name (domain name), the Destination you will configure contains one or more DNS domain names (unique or wildcard) against which the connection's destination host name is matched.
    • From the Type list, depending on which Mode you selected, choose either IP Address, Data Group, Category, or Domain Name (or there will be no selection required).
    • From the Value list or field, depending on which Type and Mode you selected, choose a value from the list or type in the required information (hover your mouse over the field for tips on required information).
  8. Click Add.
  9. From the Service Chain list, select the name of the service chain you configured that you want to use for this classifier rule. This must be the name you gave a service chain or a special keyword:
    • All means a chain including all services: first receive-only services, then ICAP services, then in-line services.
    • Reject terminates the connection.
    • Bypass lets the connection go to its destination without traversing any service chain.
    By specifying service chain classifier rules, if more than one classifier matches a connection, the best-matching classifier determines the service chain for that connection (so the order of classifier rules in the list is not important). Classifiers can also reject a connection or let it bypass the service chain (bypass TLS interception). The default action applies to connections which do not match any classifier.
    This classifier is the element of the Herculon SSL Orchestrator implementation which selects the proper service chain to handle each connection. A connection" is a particular packet flow between client (source) and server (destination), identified by the 5-tuple of IP protocol (TCP or UDP), plus client (source) and server (destination) IP addresses and port numbers. The classifier has a set of rules for TCP connections, and another set of rules for UDP when UDP service chains are enabled. The classifier matches information describing each connection, such as its client and server IP addresses, against criteria specified in the classifier rules. For example, a classifier rule might match all connections from clients homed on a certain IP subnet. Another classifier rule might match all connections going to servers in a certain country (using IP Geolocation).
  10. Click Finished.
  11. From the What should happen to unmatched connections? list, select how the system should handle unmatched connections.
  12. Click Save.
You have now created a TCP service chain classifier rule.

Creating UDP service chain classifier rules

Before you create a UDP service chain classifier rule, you must create one or more service chains.
Service chain classifier rules determine which service chains receive traffic. Each service chain classifier rule selects the specific chain to process ingress connections. Different classifier rules may send connections to the same chain. Each classifier has three filters that match the source IP address, the destination, and the application protocol. Filters can also overlap, so the best matching classifer determines the service chain for a specific connection. Finally, classifiers can reject a connection or allow it to bypass the service chain.
  1. On the Main tab, click SSL Orchestrator > Configuration , and on the menu bar, click Policies to view UDP service chain classifiers settings.
    The UDP Service Chain Classifiers information on the Policies screen opens.
  2. In the UDP Service Chain Classifiers area, click Add.
  3. In the Name field, type a name for this rule.
  4. From the Protocol list, select the protocol of the connection based on the port number or protocol recognition.
  5. In the Source area, select a Type and type a Value.
    This option specifies the name of the Service Chain you configured that you want to use for this classifier rule.
  6. In the Destination area, select a Mode and Type, and type a Value.
    This option specifies the destination of the connection. The value of this field is based on the selection you made for the mode.
  7. From the Service Chain list, select All.
  8. Click Finished.
  9. From the What should happen to unmatched connections? list, select how the system should handle unmatched connections.
  10. Click Save.
You have created a UDP Service Chain Classifier rule.