How to: Create an Application with an Outbound Gateway Mode Policy¶
Overview¶
The outbound gateway topology in F5 SSL Orchestrator is designed to manage and secure outbound SSL/TLS traffic from internal clients to external servers. In this topology, the SSL Orchestrator acts as an transparent forward proxy, intercepting and inspecting outbound traffic to enforce security policies, detect threats, and ensure compliance. This setup enhances visibility and control over encrypted traffic, providing a robust security layer for outbound communications.
Note: When SSL Orchestrator provisioning is removed in BIG-IP Next Central Manager, traffic to applications that are using SSL Orchestrator features such as SSL forward proxy, service chain, and security policy is blocked.
Procedure¶
To deploy an Outbound Gateway Application Service using Central Manager GUI:
Log in to BIG-IP Next Central Manager as admin.
Click the Workspace icon next to the F5 logo, and then click Applications.
If this is the first application service you are adding to BIG-IP Next Central Manager, click Start Adding Apps. Otherwise, at the top of the screen, click Add Application.
Select From Template.
For Application Service Name, enter a name for the application service.
Click Select Template.
Select sslo-outbound-gateway-topology from the Application Template drop-down list.
Click Start Creating.
Add a description for the application service.
If no virtual servers are added, click Start Creating. The Virtual Servers tab of the Application Service Properties screen opens.
For the Virtual Server Name, specify a name for the virtual server.
For the Virtual Port, specify the port number to use to access the virtual server. For Outbound application, the default virtual port is 0.
Click the edit icon under Protocols & Profiles. The Protocols screen opens.
Select Enable SSL Forward Proxy.
Click Add to specify the forward proxy for the application. The TLS Instance Property Window appears.
Enter the following General Properties in the Client-side Cipher & Protocol Properties and Server-side Cipher & Protocol Properties sections:
Ciphers/ Cipher Strings: Before establishing a secure channel with SSL/TLS, clients and servers must exchange and agree on a set of security parameters to ensure confidentiality, authentication, and message integrity. A ‘Cipher Suite’ represents a combination of these parameters in the following OpenSSL-compatible format: Key Exchange - Authentication - Bulk Cipher [-Block Cipher Mode*] - MAC.
Key Exchange: The algorithm used to negotiate the session key for bulk encryption.
Authentication: The asymmetric encryption algorithm used to sign certificates and verify the identity of the server and, optionally, the client during the SSL/TLS handshake.
Bulk Cipher [-Block Cipher Mode*]: A symmetric encryption algorithm used for bulk encryption, which secures the channel after all security parameters have been agreed upon. This may include a key length. Optionally, a block cipher like AES or DES may specify the mode of operation, such as CBC (Cipher Block Chaining) or GCM (Galois Counter Mode). If not specified, CBC mode is implied for block ciphers.
MAC (Message Authentication Code): Ensures message integrity by creating a message digest or cryptographic hash of each message exchanged in the secure channel. This is specified as the hash algorithm used with HMAC (Hash-based Message Authentication Code). Note that AEAD ciphers, like AES-GCM, have built-in message authentication and do not use the cipher suite’s MAC during bulk encryption.
Security parameters used to negotiate secure communication are represented in a single string. A ‘Cipher String’ specifies a combination of Cipher Suites, separated by colons (‘:’).
The default cipher string is: ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-CBC-SHA:ECDHE-RSA-AES256-SHA384:AES256-GCM-SHA384.
DH Group: Enter the Elliptic Curve groups (ECDHE), Finite Field groups (FFDHE), and Brainpool curves used in the TLS key agreement algorithm to determine the strength of the key in the key exchange process. These groups are only applicable to Diffie-Hellman key agreements. The algorithms are listed and separated by colons (“:”).
For example: P256:X25519.
Available DH Groups include: P256, P384, X25519, BRAINPOOLP256R1, BRAINPOOLP384R1, BRAINPOOLP256R1TLS13, BRAINPOOLP384R1TLS13, FFDHE2048, FFDHE3072, FFDHE4096, FFDHE6144, FFDHE8192.
The DEFAULT DH Group cipher string includes: P256:X25519:P384:FFDHE2048:FFDHE3072:FFDHE4096.Signature Algorithms: Enter the digital signature methods used for authentication. Each algorithm is a combination of a hashing algorithm (e.g., SHA256) and a cryptographic signing algorithm. The signing algorithm could be RSA (with PSS or PKCS padding), DSA, Elliptic Curve, or SM2/3. The algorithms are separated by colons (“:”).
For example: RSA_PKCS1_SHA256:ECDSA_P256_SHA256. Available Signature Algorithms include: RSA-PKCS1-SHA256, RSA-PKCS1-SHA384, RSA-PKCS1-SHA512, ECDSA-SHA256, ECDSA-SHA384, ECDSA-SHA512, ECDSA-BRAINPOOL256-SHA256, ECDSA-BRAINPOOL384-SHA384, RSA-PSS-SHA256, RSA-PSS-SHA384, RSA-PSS-SHA512, ED25519, ED448, RSA-PKCS1-SHA1, ECDSA-SHA1, DSA-SHA1, DSA-SHA256, DSA-SHA384, DSA-SHA512, SM2-SM3.
The DEFAULT Signature Algorithm cipher string includes: RSA-PKCS1-SHA256:RSA-PSS-SHA256:ECDSA-SHA256:RSA-PKCS1-SHA384:RSA-PSS-SHA384:ECDSA-SHA384:RSA-PKCS1-SHA512:RSA-PSS-SHA512:ECDSA-SHA512.Enable TLS: Specify the TLS versions to be used. TLS 1.3 provides the best security and performance compared to previous versions.
Click Continue.
Enter the following SSL Forward Proxy details:
Note: If the certificates are not available, navigate to Certificates & Keys in the Applications menu to import/create certificates.
Signing CA Certificate and Key: Choose the CA Certificate and Key to be used by the SSL Forward Proxy to re-sign an origin certificate to the internal client. In an SSL Forward Proxy, a local CA certificate and key are needed to re-sign (forge) an origin certificate to the internal client. The client will receive a server certificate in the TLS handshake that mirrors the origin certificate but issued by the local authority. The client must then trust this local CA. A CA certificate must minimally have the following certificate attributes:
basicConstraint: CA=true (critical)
keyUsage extension containing keyCertSign and digitalSignature attributes
Server Certificate Template: Choose a certificate that can be used by BIG-IP Next as a template for issuing local server certificate to client. In an SSL Forward Proxy, a local CA certificate and key are needed to re-sign (forge) an origin certificate to the internal client. In the forging process, BIG-IP uses this certificate and private key as the template for issuing a local server certificate to the client.
In the Server Authentication section, select the Enable Server Authentication radio button to enable Server Authentication.
Trusted Certificate Authority: Choose a bundle of CA certificates that will be used to establish trust with the origin TLS Server Certificate. When Server Authentication is enabled, the Trusted Certificate Authorities selection should be a bundle of CA certificates that will be used to verify (i.e., establish trust) with the origin TLS server certificate. To use the default CA bundle, select ca-bundle from the drop-down list. For information on importing a certificate to BIG-IP Next Central Manager, refer to Import a Certificate
Toggle the Show Advanced radio button to display advanced options:
[Advanced] Certificate Lifespan: Enter the duration in days for which the forged certificate is valid.
[Advanced] Expire Certificate Response Control: SSL Orchestrator performs validation on remote server certificates and can control what happens if it receives an expired server certificate. The options are drop, ignore, and mask. Drop simply drops the traffic. Ignore, mirrors an expired forged certificate to the client; it allows the SSL Forward Proxy to ignore expired server certificates. Mask allows the SSL Forward Proxy to mask the expired certificate status and present it as valid to the client. The default and recommended behavior for forward proxy is to drop traffic on an expired certificate.
[Advanced] Untrusted Certificate Authority Control: SSL Orchestrator performs validation on remote server certificates and can control what happens if it receives an untrusted server certificate, based on the Trusted Certificate Authority bundle. The options are drop, ignore, and mask. Drop simply drops the traffic. Ignore, allows the SSL Forward Proxy to ignore certificates issued by untrusted Certificate Authorities (CAs) during the SSL/TLS handshake. Mask allows the SSL Forward Proxy to mask the untrusted CA status and present it as valid to the client. The default and recommended behavior for forward proxy is to drop traffic on an untrusted certificate.
To specify security policies, click the edit icon under Security Policies. The Security Policies screen opens.
To specify security policies, click the edit icon under Security Policies.
The Security Policies screen opens.i. To specify an SSL Orchestrator policy:
Click Use an SSL Orchestrator Policy.
Select the SSLO Policy for the application service.
Note: The policies are listed based on the template you selected. For example, only Outbound Gateway type policies will be listed when you are creating an application from the sslo-outbound-gateway-topology template.
ii. To specify an SSL Orchestrator service chain:
Click Use an SSL Orchestrator Static Service Chain.
Click Start Adding to add an inspection service or Click + Add Row if you already selected an inspection service and want to add more inspection services to the service chain.
When you have specified the policies and/or service chains needed, click Save to return to the Application Service Properties screen.
To specify iRules, click the edit icon under iRules.
The iRules screen opens.i. To Enable iRules, click Use iRules.
ii. To specify iRules for this application service, click Add.
iii. Use the controls to specify the iRules (and version) for this application service and arrange the order in which they run.
iv. When the iRules are correctly specified, click Save to return to the Application Service Properties screen.
Add additional virtual servers as needed.
When you finish specifying settings for the application service, click Review & Deploy.
The Instance/Locations page opens.Click Start Adding and then select the instances to which you want to deploy the application service, then click Add to List.
The Deploy screen opens.For each instance/location you added in the previous step, under Virtual Address, specify the IP address(es) of the virtual server(s). Typically, you can enter a wild card 0.0.0.0/0 for Outbound Gateway Mode.
Select the edit icon in the Configure column.
Click Enable VLAN to listen on.
From the VLANS drop-down list, select the VLAN that you want your application to listen on.
Click Deploy Changes.
The Deploy Application Service screen displays a summary of the changes to be deployed.Click Yes Deploy to complete the deployment.
Create Application Service with FAST Template
To deploy an Outbound Gateway Application Service using Central Manager API:
Send a POST request to the
/v1/spaces/default/appsvcs/blueprints
endpoint.POST http://{{cm_mgmt_ip}}/api/v1/spaces/default/appsvcs/blueprints
For the request payload, use the following example, modifying the values as required.
Specify the template_name as sslo-outbound-gateway-topology and Set enable_ssl_forward_proxy to true.
Set enable_SsloPolicy to true and provide the outbound gateway policy name in ssloPolicyEnum
{ "name": "outboundapp", "parameters": { "application_description": "", "application_name": "outboundapp", "virtuals": [ { "ciphers": "DEFAULT", "enable_Access": false, "tls_c_1_1": false, "tls_c_1_2": true, "tls_c_1_3": false, "enable_TLS_Server": false, "ciphers_server": "DEFAULT", "tls_s_1_1": false, "tls_s_1_2": true, "tls_s_1_3": false, "enable_snat": true, "snat_automap": true, "enable_SsloPolicy": true, "ssloPolicyEnum": "outb2-pol", "enable_ssl_forward_proxy": true, "multiSslForwardProxyEnum": [ { "client_ciphers": "RSA", "client_namedGroups": [ "P256", "P384" ], "client_signatureAlgorithms": [ "RSA-PKCS1-SHA1", "RSA-PSS-SHA256" ], "client_tls1_1Enabled": true, "client_tls1_2Enabled": true, "client_tls1_3Enabled": false, "client_certificateLifespan": 21, "client_signingCertificates": [ { "certificate": "abc-rsa" } ], "client_templateCertificates": [ { "certificate": "abc-rsa" } ], "server_enableAuthentication": true, "server_ciphers": "RSA", "server_namedGroups": [ "P256", "P384" ], "server_signatureAlgorithms": [ "RSA-PKCS1-SHA1", "RSA-PSS-SHA256" ], "server_tls1_1Enabled": true, "server_tls1_2Enabled": true, "server_tls1_3Enabled": false, "server_expiredCAAction": "ignore", "server_untrustedCAAction": "drop", "bypassOnHandshakeFailure": true, "bypassOnClientCertificateFailure": false, "server_trustCA": "ca-bundle" } ], "snat_addresses": [], "enable_FastL4": false, "FastL4_idleTimeout": 600, "FastL4_looseClose": true, "FastL4_looseInitialization": true, "FastL4_resetOnTimeout": true, "FastL4_tcpCloseTimeout": 43200, "FastL4_tcpHandshakeTimeout": 43200, "enable_HTTP2_Profile": false, "enable_UDP_Profile": false, "UDP_idle_timeout": 60, "enable_TCP_Profile": false, "TCP_idle_timeout": 60, "enable_mirroring": true, "enable_WAF": false, "enable_iRules": false, "virtualPort": 12443, "virtualName": "vs1" } ] }, "set_name": "Examples", "template_name": "sslo-outbound-gateway-topology" }
Create an AS3 Application Service using AS3 Declaration
The basic implementation of SSL Orchestrator in Next is to attach a policy to an application AS3 declaration. The Outbound Gateway requires a few additional options compared to Inbound Application and is represented as a separate outbound application template. However, the addition of SSL Orchestrator policy is the same across all application template types:
"policySslOrchestrator": {
"cm": "my-sslo-gw-policy"
}
This document cannot be exhaustive on all the AS3 attributes available in an application declaration, but all application deployments require two steps: Create the outbound gateway application in CM, deploy that application to a BIG-IP Next instance. Full AS3 application reference can be found here:
https://clouddocs.f5.com/bigip-next/latest/schemasupport/schema-reference.html
The below example provides the bare minimum inbound application declaration.
Basic: Create Application
POST /api/v1/spaces/default/appsvcs/documents
{
"class": "ADC",
"id": "adc-canonical",
"schemaVersion": "3.43.0",
"my_tenant": {
"class": "Tenant",
"my_app": {
"class": "Application",
"my_server_tls": {
"class": "TLS_Forward_Proxy_Server",
"certificates": [
{
"certificate": "template_cert"
}
],
"signingCertificates": [
{
"certificate": "signing_ca_cert"
}
],
"ciphers": "DEFAULT",
"namedGroups": [ "DEFAULT" ],
"signatureAlgorithms": [ "DEFAULT" ],
"tls1_1Enabled": false,
"tls1_2Enabled": true,
"tls1_3Enabled": true,
"certificateLifespan": 1,
"defaultAction": "intercept"
},
"my_client_tls": {
"class": "TLS_Forward_Proxy_Client",
"ciphers": "DEFAULT",
"namedGroups": [ "DEFAULT" ],
"signatureAlgorithms": [ "DEFAULT" ],
"tls1_1Enabled": false,
"tls1_2Enabled": true,
"tls1_3Enabled": true,
"enableAuthentication": false,
"bypassOnClientCertificateFailure": false,
"bypassOnHandshakeFailure": false
},
"my_service": {
"class": "Service_HTTPS_Forward_Proxy",
"allowVlans": [
{
"bigip": "clientside"
}
],
"virtualAddresses": [
"0.0.0.0/0"
],
"virtualPort": 0,
"clientTLS": "my_client_tls",
"serverTLS": "my_server_tls",
"pool": "my_app_serverside",
"snat": "auto",
"lastHop": "auto",
"translateServerAddress": false,
"policySslOrchestrator": {
"cm": "my-policy"
}
},
"my_app_serverside": {
"allowNetworks": [
{
"bigip": "gateway"
}
],
"class": "Pool"
},
"signing_ca_cert": {
"class": "Certificate",
"certificate": {
"cm": "subrsa.f5labs.com.crt"
},
"privateKey": {
"cm": "subrsa.f5labs.com.pem"
}
},
"template_cert": {
"class": "Certificate",
"certificate": {
"cm": "template.crt"
},
"privateKey": {
"cm": "template.pem"
}
}
}
}
}
Notice that there is no pool defined in this declaration, and that “translateServerAddress” is false. The virtualAddress is a wildcard listener (0.0.0.0), and in this case the virtualPort is 0 to intercept all outbound traffic. The response to successful creation will contain a JSON payload including an ID value. That ID value is then used in the following request to deploy the application to a BIG-IP Next instance, where {{Next-Instance-IP-Address}} is the IP address of the target instance.
Basic: Deploy Application
POST /api/v1/spaces/default/appsvcs/documents/{{application_id}}/deployments
{
"target": "{{Next-Instance-IP-Address}}"
}
Curl: Create Application
APP=$(cat <<EOF
{
"class": "ADC",
"id": "adc-canonical",
"schemaVersion": "3.43.0",
"my_tenant": {
"class": "Tenant",
"my_app": {
"class": "Application",
"my_server_tls": {
"class": "TLS_Forward_Proxy_Server",
"certificates": [
{
"certificate": "template_cert"
}
],
"signingCertificates": [
{
"certificate": "signing_ca_cert"
}
],
"ciphers": "DEFAULT",
"namedGroups": [ "DEFAULT" ],
"signatureAlgorithms": [ "DEFAULT" ],
"tls1_1Enabled": false,
"tls1_2Enabled": true,
"tls1_3Enabled": true,
"certificateLifespan": 1,
"defaultAction": "intercept"
},
"my_client_tls": {
"class": "TLS_Forward_Proxy_Client",
"ciphers": "DEFAULT",
"namedGroups": [ "DEFAULT" ],
"signatureAlgorithms": [ "DEFAULT" ],
"tls1_1Enabled": false,
"tls1_2Enabled": true,
"tls1_3Enabled": true,
"enableAuthentication": false,
"bypassOnClientCertificateFailure": false,
"bypassOnHandshakeFailure": false
},
"my_service": {
"class": "Service_HTTPS_Forward_Proxy",
"allowVlans": [
{
"bigip": "clientside"
}
],
"virtualAddresses": [
"0.0.0.0/0"
],
"virtualPort": 0,
"clientTLS": "my_client_tls",
"serverTLS": "my_server_tls",
"pool": "my_app_serverside",
"snat": "auto",
"lastHop": "auto",
"translateServerAddress": false,
"policySslOrchestrator": {
"cm": "my-policy"
}
},
"my_app_serverside": {
"allowNetworks": [
{
"bigip": "gateway"
}
],
"class": "Pool"
},
"signing_ca_cert": {
"class": "Certificate",
"certificate": {
"cm": "subrsa.f5labs.com.crt"
},
"privateKey": {
"cm": "subrsa.f5labs.com.pem"
}
},
"template_cert": {
"class": "Certificate",
"certificate": {
"cm": "template.crt"
},
"privateKey": {
"cm": "template.pem"
}
}
}
}
}
EOF
)
app_id=$(curl -sk -H "Authorization: Bearer ${token}" -H "Content-Type: application/json" "https://${CM}/api/v1/spaces/default/appsvcs/documents" -d "${APP}")
Curl: Deploy Application
DEPLOY=$(cat <<EOF
{
"target": "${Next-Instance-IP-Address}"
}
EOF
)
curl -sk -H "Authorization: Bearer ${token}" -H "Content-Type: application/json" "https://${CM}/api/v1/spaces/default/appsvcs/documents/${app_id}/deployments" -d "${DEPLOY}"
For more information on the APIs, refer to Open API documentation
Ansible Reference
The following Ansible example exposes a larger set of TLS capabilities, including expanded namedGroups and signatureAlgorithms examples, and the ability control the certificate extensions in the forged server certificate.
Execute with:
export CMPASS='mypassword'
ansible-playbook -i notahost, sslo-application-outbound-gw.yaml
---
- hosts: all
connection: local
vars:
bigip_next_cm_mgmt_ip: "10.1.1.6"
bigip_next_cm_password: "{{ lookup('ansible.builtin.env', 'CMPASS') }}"
tasks:
- name: Check if BIG-IP Next Central Manager instance is available (HTTPS responding 405 on /api/login)
uri:
url: https://{{ bigip_next_cm_mgmt_ip }}/api/login
method: GET
status_code: 405
validate_certs: false
until: json_response.status == 405
retries: 50
delay: 30
register: json_response
- name: Authenticate to BIG-IP Next CM API
uri:
url: https://{{ bigip_next_cm_mgmt_ip }}/api/login
method: POST
headers:
Content-Type: application/json
body: |
{
"username": "admin",
"password": "{{ bigip_next_cm_password }}"
}
body_format: json
timeout: 60
status_code: 200
validate_certs: false
register: bigip_next_cm_token
retries: 30
delay: 30
- name: Set the BIG-IP Next CM token
set_fact:
bigip_next_cm_token: "{{ bigip_next_cm_token.json.access_token }}"
- name: Create SSLO Inbound Application
uri:
url: https://{{ bigip_next_cm_mgmt_ip }}/api/v1/spaces/default/appsvcs/documents
method: POST
headers:
Authorization: "Bearer {{ bigip_next_cm_token }}"
Content-Type: application/json
body: |
{
"class": "ADC",
"id": "adc-canonical",
"schemaVersion": "3.43.0",
"my_tenant": {
"class": "Tenant",
"my_app": {
"class": "Application",
"my_server_tls": {
"class": "TLS_Forward_Proxy_Server",
"certificates": [
{
"certificate": "template_cert"
}
],
"signingCertificates": [
{
"certificate": "signing_ca_cert"
}
],
"ciphers": "DEFAULT",
"namedGroups": [
"P256",
"P384",
"X25519"
],
"signatureAlgorithms": [
"RSA-PKCS1-SHA256",
"RSA-PSS-SHA256",
"ECDSA-SHA256",
"RSA-PKCS1-SHA384"
],
"tls1_1Enabled": false,
"tls1_2Enabled": true,
"tls1_3Enabled": true,
"certificateLifespan": 1,
"defaultAction": "intercept",
"certificateExtensions": [
"BasicConstraints",
"SubjectAltName",
"ExtendedKeyUsage",
"TlsFeature"
]
},
"my_client_tls": {
"class": "TLS_Forward_Proxy_Client",
"ciphers": "DEFAULT",
"namedGroups": [
"P256",
"P384",
"X25519"
],
"signatureAlgorithms": [
"RSA-PKCS1-SHA256",
"RSA-PSS-SHA256",
"ECDSA-SHA256",
"RSA-PKCS1-SHA384"
],
"tls1_1Enabled": false,
"tls1_2Enabled": true,
"tls1_3Enabled": true,
"enableAuthentication": false,
"bypassOnClientCertificateFailure": false,
"bypassOnHandshakeFailure": false
},
"my_service": {
"class": "Service_HTTPS_Forward_Proxy",
"allowVlans": [
{
"bigip": "clientside"
}
],
"virtualAddresses": [
"0.0.0.0/0"
],
"virtualPort": 0,
"clientTLS": "my_client_tls",
"serverTLS": "my_server_tls",
"pool": "my_app_serverside",
"snat": "auto",
"lastHop": "auto",
"translateServerAddress": false,
"policySslOrchestrator": {
"cm": "my-policy"
}
},
"my_app_serverside": {
"allowNetworks": [
{
"bigip": "gateway"
}
],
"class": "Pool"
},
"signing_ca_cert": {
"class": "Certificate",
"certificate": {
"cm": "subrsa.f5labs.com.crt"
},
"privateKey": {
"cm": "subrsa.f5labs.com.pem"
}
},
"template_cert": {
"class": "Certificate",
"certificate": {
"cm": "wildcard.f5labs.com.crt"
},
"privateKey": {
"cm": "wildcard.f5labs.com.pem"
}
}
}
}
}
body_format: json
timeout: 60
status_code: 200
validate_certs: false
register: json_response
- name: Set application ID
set_fact:
app_id: "{{ json_response.json.id}}"
- name: Deploy Inbound Application to BIG-IP Instance
uri:
url: https://{{ bigip_next_cm_mgmt_ip }}/api/v1/spaces/default/appsvcs/documents/{{ app_id }}/deployments
method: POST
headers:
Authorization: "Bearer {{ bigip_next_cm_token }}"
Content-Type: application/json
body: |
{
"target": "10.1.1.7"
}
body_format: json
timeout: 60
status_code: 202
validate_certs: false
register: json_response
- debug:
var: json_response