Contact Free trial Login

Enable Inbound Traffic on Anypoint Runtime Fabric

Runtime Fabric provides load balancing to manage inbound traffic to Mule applications and API proxies. Network traffic is balanced across multiple replicas of an application, which by default are deployed across different worker VMs.

Runtime Fabric can be shared across multiple environments. After installation, configure one or more environments for each Runtime Fabric to enable application deployment. You must associate at least one environment with each Runtime Fabric to be able to deploy Mule applications or API gateways.

Applications deployed to a production environment must be deployed to a instance of Runtime Fabric that is separated from non-production applications.

By default, inbound traffic is disabled to prevent consuming unnecessary resources. To allow Mule applications or API gateways to listen on inbound connections, enable inbound traffic. Inbound traffic is disabled by default and must be manually enabled before inbound requests can be received by Mule applications and API gateways.

Before enabling inboud traffic, you must provide a valid TLS certificate. The certificate must require a passphrase and be set with a Common Name (CN) which specifies the domain for each application deployed to Runtime Fabric.

  • If the Common Name contains a wildcard, the endpoint for each deployed application takes the form {app-name}.{common-name}.

  • If the Common Name does not contain a wildcard, the endpoint takes the form {common-name}/{app-name}.

External Load Balancer Requirements

Each controller VM runs a replica of the internal load balancer and is configured to listen on port 443. When running multiple controller VMs, you must have an external load balancer outside Runtime Fabric to front each of the controller VMs. The external load balancer must support TCP load balancing. The load balancer must be configured with a server pool containing the IP addresses of each controller VM. A health check must also be set up on the external load balancer, listening on port 443.

This configuration of the external load balancer:

  • Maintains high availability

  • Protects against failures

  • Gracefully handles automated failover if a replica of the internal load balancer restarts or is evicted and rescheduled on another controller VM.

Controller VMs are virtual machines dedicated to run the components which power Anypoint Runtime Fabric.

All inbound traffic entering Anypoint Runtime Fabric is encrypted using TLS. The following procedures describe how to configure and use a TLS certificate to enable inbound traffic. Once enabled, HTTP requests sent to Runtime Fabric will receive a 301 response to redirect to HTTPS on port 443.

Assign Required Roles and Permissions

  1. Determine the environment you want to use for applications that run in your Runtime Fabric.

  2. Ensure you have the necessary permissions.

    It can take up to 5 minutes for any permissions you gain to propagate.

    1. From Anypoint Platform, select Access Management.

      If you do not have access to Access Management, request access from your system administrator.

    2. Select Users

    3. Locate the row with your username, then select the blue link.

    4. On the Runtime Manager tab, enable the Manage Runtime Fabrics permission for your Runtime Fabric environment.

    5. On the Secrets Manager tab, enable the Manage Secret Groups, Write Secrets, and Read Secrets Metadata permissions for your Runtime Fabric environment.

Generate a Certificate-Key Pair

You need a certificate-key pair for the internal load balancer in Runtime Fabric. If you have one already, both files must be of the .pem type, your keystore must have a passcode, and your common name should match the domain you use in your Runtime Fabric.

RSA keys are the most common type of keys. RSA keys of 2K length offer the best compromise between security and performance.

RSA keys larger than 2K protect against brute force cracking and are appropriate for certificates that have expirations of many years. However, whenever key length is doubled, for example, from 2k to 4k, performance is reduced by a factor greater than 6.

ECDSA keys are also supported. In most cases, ECDSA doubles the performance of a 2K RSA key. Supported curves are:

  • secp521r1 (P-521)

  • secp384r1 (P-384)

  • secp256r1 (also known as prime256v1 (P-256))

Use the following steps to generate a certificate-key pair for evaluation purposes.

  1. Run the following command on your machine to generate a certificate-key pair:

    openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365
  2. Type a passphrase for your key.

  3. Fill out the requested information (Country, State, etc). When you’re asked for a Common Name, supply the domain you’ll use in your Runtime Fabric.

If you use a wildcard for example, * in your Common Name, your application URLs use the following format: {app-name} Otherwise, your application URLs use the format:{app-name}.

Create a TLS Context

Follow these steps to include your certificate-key pair in a TLS context and store it in Secrets Manager. This will be used later to encrypt inbound traffic to your Runtime Fabric.

  1. Navigate to Secrets Manager from the Anypoint Platform homepage.

    Make sure you’re in the right business group and select your Runtime Fabric environment in the sidebar on the left.
  2. Select Create Secret Group.

  3. Under General, type the name of your secret group.

  4. Select Save.

  5. Select Keystore in the sidebar and create your keystore:

    1. Select Add Keystore.

      If you don’t see the Add Keystore button, ensure that you are viewing your secret group in edit mode. Return to Secret Groups, then select Edit next to your group.

    2. Enter a name for your keystore.

      This name identifies the keystore when you add it to your TLS context below.

    3. Under Certificate File, select Choose File and then select your .pem certificate` file.

    4. Under Key File, select Choose File and then select your .pem key file.

    5. Enter your key passphrase.

    6. Optionally, upload a separate certificate file containing a CA path.

    7. Select Save.

      If you receive an unknown error, it might be due to your Certificate file containing a CA path. You must move the CA path into its own file and upload it separately before continuing.
  6. Select TLS Context, then perform the following:

    If you do not see Add TLS Context, ensure you are viewing your secret group in edit mode. Return to the Secret Groups page, then select Edit next to your group.
    1. Type a name for your TLS context. This will identify it when you apply it to your Runtime Fabric later.

    2. Use the default TLS version (TLS 1.2).

    3. Under Target, select Anypoint Security. This configures your TLS context so it can be applied to a Runtime Fabric.

    4. Under Keystore, select the name of the keystore you configured previously.

    5. Select Save.

  7. After saving your TLS context, select Secret Groups, then select Finish. This enables TLS Context for your Runtime Fabric.

Enable Inbound Traffic

The Runtime Fabric internal load balancer supports OpenSSL 1.1.1 and TLS 1.3, which provide the following security enhancements and performance improvements over TLS 1.2:

  • 2x or greater TLS 1.2 connection performance throughput boost versus prior Runtime Fabric internal load balancer running on OpenSSL 1.0.2.

  • Reduction of one round trip in full handshake for TLS 1.3 vs. TLS 1.2.

  • Added TLS 1.2 and TLS 1.3 ChaCha20-Poly1305 ciphers for better mobile and IoT device support.

  • TLS 1.3 protection against downgrade attacks.

  • Continued support for both RSA and ECDSA keys.

  • TLS 1.3 removes obsolete and insecure features from TLS 1.2 and TLS 1.1. Refer to the Anypoint Security Edge Release Notes for a complete list of supported and deprecated ciphers.

The TLS 1.3 protocol is enabled by default for those clients that support it.

After creating a TLS context, enable secure incoming traffic by applying the TLS context to your Runtime Fabric:

  1. Navigate to Runtime Manager and select Runtime Fabric.

  2. Select the name of your Runtime Fabric to open the management page.

  3. In the Associated Environments tab, ensure your Runtime Fabric environment is associated with your Runtime Fabric.

  4. Select Inbound Traffic and turn on the Enable inbound traffic toggle.

  5. Select Basic Configuration, then perform the following:

    1. Set the number of replicas to run the internal load balancer with.

      A minimum of 2 replicas is required for production environments. These replicas only run on the controller VMs.
    2. Determine the amount of CPU and memory to allocate for each replica of the internal load balancer.

      TLS termination is computationally expensive. Allocate more CPU to increase throughput and decrease latency.
  6. Under TLS Configuration:

    1. From the Environment menu, select your Runtime Fabric environment.

    2. From the Secrets Group menu, select the secrets group containing the TLS context created earlier.

      If your secrets group does not appear, ensure you have the Manage Runtime Fabrics permission on your account.
    3. From the TLS Context menu, select the TLS Context to be used for your Runtime Fabric.

  7. Select Deploy to deploy the internal load balancer. If successful, a message appears in the bottom-right of the page. The deployment may take up to a minute. You can view the deployment status at the top of the form. When the status transitions to Applied, the internal load balancer is successfully deployed and inbound traffic enabled.

When deploying a Mule application to Runtime Fabric using the Runtime Manager UI, only the first domain that is used in the internal load balancer’s certificate is selected to create the application endpoint. Other domains specified in the certificate via the Subject Alternative Name or Common Name are not used.

Verify that Inbound Traffic is Enabled

To resolve the Common Name (CN) of applications deployed on Runtime Fabric, DNS must be configured to map the CN to the IP address of the external load balancer or of each controller VM. To test inbound traffic for applications before configuring DNS, send a request to the application using the IP address and a host header set to the domain.

The structure of the domain depends on whether a wildcard was used in the CN of your certificate, for example:

  • A CN with a wildcard (e.g. * uses the following request header format: Host: {app-name} Use the following cURL command to verify:

    curl -Lvk -XGET https://{ip-address}/{path} -H 'Host: {app-name}'
  • A CN without a wildcard (e.g. uses the following request header format: Host: Use the following cURL command to verify:

    curl -Lvk -XGET https://{ip-address}/{app-name}/{path} -H 'Host:'`

After Enabling Traffic

Runtime Fabric must be configured to route incoming traffic to each enabled application. To complete in order for clients to send requests to deployed applications:

  • Configure an external load balancer to load balance HTTPS traffic between each controller VM on Runtime Fabric.

  • Review the advanced options described below when adding an external load balancer.

  • Configure DNS before using the Common Name obtained from the TLS certificate. DNS is required to send requests to applications or API gateways deployed to Runtime Fabric. An "A record" should be added to your DNS provider to map the Common Name to the IP address of the external load balancer or controller VMs.

When deploying new applications or managing existing applications on Runtime Fabric, the Ingress tab is enabled. This tab allows you to specify if inbound traffic should be allowed. After enabling inbound traffic, the default behavior switches to allowed for new application deployments. If there are applications deployed to Runtime Fabric before enabling inbound traffic, they will not receive inbound requests until this setting is enabled.

Additional Configuration Options

The following table describes additional configuration options you might need to set for your environment. In this case, Source IP refers to the client making the request.

Value Description

Max Connections

The maximum number of simultaneous connections to allow.

Default value: 512 connections

Max Requests per Connection

The maximum number of requests per connection to allow.
Because this value determines how much reuse a connection allows, consider the amount of CPU required to terminate and reestablish a TLS-encrypted connection when lowering this value.

Maximum allowed: 1000 requests per connection

Default value: 1000

Connection Idle Time-out

The maximum amount of time allowed for an idle connection.
This value helps you terminate idle connections and free up resources.
This value should always be higher than your Read Request Time-out.

Default value: 15 seconds

Read Request Time-out

The maximum amount of time spent to read a request before it is terminated. This value enables requests with large payloads or slow clients to be terminated to keep resources available. This helps guard against connection pool exhaustion from slow requests or from clients who don’t close connections after a response is sent.

If a Mule application takes longer to respond, the connection is automatically closed. This value should always be lower than the Connection Idle Time-out value previously configured.

Default value: 10 seconds

Read Response Time-out

The maximum amount of time spent to initiate a response before the connection is terminated. This value enables requests with large payloads be terminated to keep resources available.

Default value: 300 seconds

Write Response Time-out

The maximum amount of time spent from the end of the request header read to the end of the response write before the request is terminated.

Default value: 10 seconds

Max pipeline depth

The maximum amount of requests to allow from the same client.
This value defines how many simultaneous requests a client can send.
If a client exceeds this number, the exceeding requests are not read until the requests in the queue receive a response.

Default value: 10 requests per client

Source IP header name and enable proxy protocol

Set these configurations if Runtime Fabric is behind a load balancer.

The values to configure here depend on your scenario:

  1. Runtime Fabric is not behind a load balancer.
    Runtime Fabric is not deployed behind a load balancer, these values should not be configured.

    Source IP header name: blank
    Enable proxy protocol: Unchecked

  2. Runtime Fabric is behind an AWS Load Balancer with a Proxy Protocol configured.
    If Runtime Fabric is deployed behind an AWS load balancer with a proxy protocol enabled, you must select the enable proxy protocol option.

    Source IP header name: blank
    Enable proxy protocol: checked

  3. Runtime Fabric is behind a non-AWS load balancer.
    If Runtime Fabric is deployed behind another type of load balancer, such as F5 or nginx, the source IP header name will need to be provided. Two common source IP headers are:

    • Forwarded: An RFC7239 compliant IP header.

    • X-Forwarded-For: Non-standard pre-2014 header containing one or more IPs from a Load Balancer (For example: “,")

      Source IP header name: non-blank
      Enable proxy protocol: unchecked

Default value: blank and unchecked.

Internal Load Balancer Logs

You can define the log levels for the internal load balancer. Runtime Fabric supports the following log levels, listed in descending order of verbosity:




  • INFO




The more verbose log levels, WARNING to TRACE, consume more CPU resources for each request. Consider this when adjusting the log level and allocating resources for the internal load balancer.

By default, the activity across all IPs addresses behind your endpoint are logged. To help reduce CPU consumption when using more verbose log levels, add IP filters to only log specific IP addresses. This feature also reduces the quantity of logs when debugging a connection for a specific or limited number of IP addresses.

Configuring Internal Load Balancer Logs

  1. From Anypoint Platform select Runtime Manager.

  2. Select Runtime Fabric.

  3. From the Inbound Traffic tab, select the "Logs +" link.

  4. Select Add Filter.

  5. In the IP field, enter a single IP address or subset of addresses using CIDR notation.

  6. Select the log level to apply for this IP filter.

  7. Select OK.

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub