Applies To:

Show Versions Show Versions

Manual Chapter: Creating Services Service Chains and Classifier Rules
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next 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 you create inline services, complete the sections in the General Properties tab.
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 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 then click the Inline Services tab.
    A screen opens showing the network diagram and the Inline Services settings.
  2. For the What is the IPv4 (CIDR/19) subnet-block base address? field, type in the address block.
    For IPv4, 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.
  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 field, select the IP address pairs of the Layer 3 devices.
  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:
    • Address: 198.19.x.61 through 68 (for each of the load balanced Layer 3 devices)
    • Netmask: 255.255.255.128
    Outward Interface:
    • Address: 198.19.x.161 through 168 (for each of the load balanced Layer 3 devices)
    • Netmask: 255.255.255.128
    Routes:
    • Default Gateway: 198.19.x.245
    • Gateway to internal networks: 198.19.x.10 (unless SNAT is used)

    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 SSL Orchestrator.
After creating more than one service, you can now create a service chain.

Creating ICAP services

Before creating ICAP services, complete the sections in the General Properties tab.
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 SSL Orchestrator configuration utility to load balance across them.
  1. On the Main tab, click SSL Orchestrator > Configuration , and then click the ICAP Services tab.
    A screen opens showing the network diagram and the ICAP Services settings.
  2. Click Add.
  3. In the Name field, type a name for your configuration.
  4. For ICAP Devices, type an IP address and port number.
  5. Click Add.
  6. From the Headers list, select Default or Custom for the mode.
    To edit the headers, use Custom.
  7. 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.
  8. For Request and Response, type the ICAP request and response URI, defined by RFC3507, that are related to the ICAP server.
    For example,icap://${SERVER_IP}:${SERVER_PORT}/REQMOD.
  9. For Preview Max. Length (bytes), 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 you configure receive-only services, complete the sections in the General Properties tab.
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 SSL Orchestrator configuration utility.
  1. On the Main tab, click SSL Orchestrator > Configuration , and then click the Receive Only Services tab.
    A screen opens showing the network diagram and the Receive Only Services settings.
  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 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 then click the Policies tab.
    A screen opens showing the network diagram and the Service Chain settings.
  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.
  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 then click the Policies tab.
    A screen opens showing a network diagram and the TCP Service Chain Classifiers settings.
  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 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, either or
    • Select IP Address and type the required IP address in the Value field.
    • Select Data Group and select the name of your data group from the Value list.
  7. In the Destination setting, select a Mode, a Type, and 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.
    • From the Mode list, choose 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 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. 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.
    • Bypass lets the connection go to its destination without traversing any service chain.
    • Reject terminates the connection.
    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 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).
  9. Click Finished.
  10. From the What should happen to unmatched connections? list, select how the system should handle unmatched connections.
  11. 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 then click the Policies tab.
    A screen opens showing the network diagram and the UDP Service Chain Classifiers settings.
  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 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.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)