Manual Chapter : Initial Connections for BIG-IQ Centralized Management

Applies To:

Show Versions Show Versions

BIG-IQ Centralized Management

  • 8.2.0, 8.1.0
Manual Chapter

Initial Connections for BIG-IQ Centralized Management

Configure static routes

For details about which routes your solution needs and why, refer to
Routing considerations for a BIG-IQ solution
in the
Planning a Centralized Management & Visibility Deployment
article on
. You must have this information before you can proceed.
You need to create the static routes needed to enable communication between the components in your BIG-IQ solution. For details on how to create these routes refer to this article: K13833.

Confirm connectivity between BIG-IQ solution components

After your routes are set up and all of your components are online, you should confirm that all connections are performing correctly. Checking your connections and discovering a bad route now can spare a lot of headaches down the road.
You need to verify that there is bidirectional communication between each component in your solution. Your network administrator likely has all the tools necessary to confirm this. But F5 also has a script (accessible on a public Git repository) that you can use to determine whether each component in the solution is connected correctly. You run this script on both the primary and secondary BIG-IQ VEs, following the prompts to identify the IP addresses for each component. The script then uses
(a Unix utility) to find and report the routes it finds to that device, including the port status and (optionally) the latency encountered.
Access the F5 public Git repository using this link: f5-bigiq-connectivityChecks. Instructions for installing and using the script are in a ReadMe file, which is available at the same location.

Add a proxy for secure communication

Before you can perform this task, you must be logged in as Admin, and you must have configured a proxy server that your data collection device (DCD) cluster can access.
As a security precaution, you might want to configure a proxy to route DCD cluster communications that need to pass through your firewall. When you configure a proxy for the BIG-IQ, you designate the operations that you want to use it for communicating outside your firewall. Here are some common situations in which that communication is needed:
  • Communicate with the F5 licensing server when you use BIG-IQ to license BIG-IP devices.
  • Send iHealth data to F5 for troubleshooting help.
  • Route forwarded alerts.
  • Download alert rules from the security operations center.
  • Download ASM signature files.
To use a proxy for Fraud Protection Service, you must configure a proxy on each device (every DCD and both the primary and the secondary BIG-IQ devices) in the DCD cluster. The proxy names you specify for each node in the cluster must match exactly, but the IP address and port number for the proxy can be different from device to device.
  1. At the top of the screen, click
  2. On the left, click
  3. On the Proxies screen, click
  4. If the BIG-IQ is in a high availability configuration, you can assign the proxy to either the active or standby device. For
    Proxied Device
    , select the hostname of the device for which you are creating this proxy.
  5. For
    , type a name for this proxy.
    The proxy name must match across all devices in the cluster. The proxy addresses and port can vary.
  6. For
    , type the IP address of the proxy server.
  7. For
    , type the port that you want the proxy server to use.
  8. If the proxy server requires authentication, type the
    User Name
    for the proxy.
  9. Select the check box next to the Functions (
    ) that you want BIG-IQ to use this proxy for.
    When you create a proxy, the BIG-IQ uses that proxy when it accesses FPS alerts or ASM signature files. BIG-IQ uses this proxy any time you use a function that requires outside the firewall communications .
  10. Click the plus sign in the upper right hand corner, and then repeat the preceding 4 steps to add a proxy for each data collection device in the cluster.
    Remember, the proxy name must match across all devices in the cluster. The proxy addresses and port can vary.
  11. Click
    Save & Close
  • To use this proxy for a BIG-IQ used only as a license server, follow the task sequence laid out in
    Deploy BIG-IQ to use as a license manager for BIG-IP VE devices
  • To use this proxy to configure BIG-IQ authentication credentials for iHealth & Reports, refer to
    How do I get access to send QKView files for my managed devices to the F5 iHealth diagnostics server
If the proxy resides on a network subnet not directly connected to the DCD cluster, you must set up a static route for it. For details about configuring static routes, refer to
Routing requirements for four subnets
article in the
Planning a Centralized Management & Visibility Deployment
guide on

Replace the default SSL certificate on a BIG-IQ system

To perform the procedures discussed in this task, you must have Advanced Shell (bash) access to the BIG-IQ system with administrator credentials.
The BIG-IQ, data collection devices (DCDs), and BIG-IP devices all use SSL encryption to secure incoming communication. By default, F5 devices use a default, self signed certificate to authenticate themselves. When you use these default certificates and a component attempts to connect to the BIG-IQ, your browser may refuse to connect or trigger a warning against a potentially insecure connection.
Users who are managing devices running Web Application Security, and require added security (encrypted) to the connection between BIG-IP and Central Policy Builder (
Secure Policy Builder
enabled), must replace the default SSL certificate with a certificate issued by a trusted CA (Certificate Authority). If the SSL certificate is not replaced, the system will be unable to provide policy suggestions once Secure Policy Builder is enabled.
Users who do not enable a secure connection do not need to perform the certificate replacement task.

Configure trusted certificates for outgoing SSL connections

If you plan to use the default certificates that reside on each F5 device for SSL verification, you need copies of those certificates on the local device you use to access the BIG-IQ before you begin.
By default, BIG-IQ does not validate the certificates of the hosts it connects to. If you have not explicitly enabled SSL certificate verification, you do not need to perform this task.
When you enable SSL certificate verification, the BIG-IQ attempts to validate the certificate for every host it initiates connections to (that is, BIG-IQ HA peer, each
data collection devices
and each BIG-IP device). BIG-IQ validates the SSL certificate presented by the communicating host either against a list of certificates you provide (for example, self-signed certificates, or certificates issued by a corporate certificate authority), or against a list of publicly known CA certificates (typically the default certificates in the Java TrustStore).
For example, when SSL certificate verification is enabled, before you can add DCDs to the cluster, each DCD must present the certificate type you specify or the connection attempt fails. All the components in a BIG-IQ solution are equipped with a list of well-known certificate authorities, so if you choose that option, BIG-IQ recognizes them automatically. However, if you choose to provide your own certificates, then those SSL certificates must be available on each device that the BIG-IQ needs to communicate with (BIG-IQ HA peer, each DCD and each BIG-IP device).
  1. At the top of the screen, click
  2. On the left, click
  3. For
    Verify Hosts
    confirm that the
    check box is enabled.
  4. Use
    Verify Using
    to specify the type of certificate to use for end-user host verification.
    Well-known certificate authorities
    BIG-IQ accepts certificates issued by any CA in its default trust store. If you choose this option, your task is complete.
    Certificates I provide
    BIG-IQ accepts only the certificates that you identify and import.
    If you import the certificate of a trusted CA, BIG-IQ will trust all certificate issued by that CA.
  5. Click
  6. For
    Import Method
    , select
    Create New
  7. Type a
    for the first certificate you are adding.
    It's good practice to use a name that distinguishes this certificate from others you import. BIG-IQ stores and identifies this certificate by the name you specify here. That is, if the certificate you are importing is currently named
    , but when you import it you name it
    , BIG-IQ stores the certificate as you specified, to
  8. From the
    Certificate Source
    list, select
    Upload File
  9. Click the
    Choose File
    button, navigate to the certificate for the first component in your solution, and then click
  10. Click
    BIG-IQ adds the certificate to the list of trusted certificates it uses to validate the certificates of the hosts it connects to.
    You might have to refresh your screen display the new certificate.
  11. Repeat steps 7 through 9 to add certificates for the remaining components in your system (each DCD, each BIG-IP, and the standby BIG-IQ). As you add each certificate, use a name to help you identify which component it belongs to.
  12. Click
    Save & Close
    The SSL Certificate Verification screen lists the certificates for all of the components in your BIG-IQ solution.

Restrict BIG-IQ access to clients using high-encryption SSL ciphers and protocols

You can control which SSL protocols and cipher suites the BIG-IQ supports on incoming connection requests. This control applies to both browser-based connection requests to the user interface and to REST API calls.
By default, the BIG-IQ allows incoming requests to use a large range of SSL protocols and ciphers for clients to connect to the user interface or for REST API calls. If you require a more restricted list of SSL protocols and ciphers, offering stronger security, you can modify the default lists BIG-IQ uses. Details about how and why you might want to restrict BIG-IQ user interface access to clients using SSL ciphers and protocols offering stronger encryption are provided in this article: K17007.on