How to: Migrate SSL Orchestrator Configuration from BIG-IP to BIG-IP Next¶
Overview¶
You can migrate your SSL Orchestrator configurations from BIG-IP to BIG-IP Next using the SSL Orchestrator configuration converter (SCC). SSL Orchestrator Configuration Converter simplifies the process of migrating your SSL configurations by taking your existing configuration and converting it into the format required by BIG-IP Next.
Prerequisites¶
SSL Orchestrator configuration converter is supported for existing configuration of SSL Orchestrator 9.0, BIG-IP 16.1.0 and above.
Ensure that you have pre-configured the required L1 Networks on BIG-IP Next Instance(s).
SCC 1.0 will convert features supported up to BIG-IP Next Version 20.1.0.
Limitations¶
SSL Orchestrator Config Converter currently supports the migration of:
TAP, ICAP, L3 Inline, HTTP Transparent Inspection Services
Service Chains
Inbound Type SSL Orchestrator Policies
Only the following policy conditions are supported:
IP Protocol
IP Version
Client Port Match
Server Port Match
Client IP Subnet Match
Server IP Subnet Match
Server Name (TLS Client)
Only the Allow and Reset flow actions are supported.
Only the Intercept and Bypass SSL actions are supported.
SSL Orchestrator Topologies, SSL Configuration, and Authentication are not migrated via SCC 1.0.
Note: If your configuration has inspection services or policies that are not supported, you can still run the SSL Orchestrator configuration converter, but you will receive the payloads only for the inspection services or policies that are supported.
The output will include the status for each object you are attempting to migrate from BIG-IP to BIG-IP Next. For detailed information on the output format, deployable, partially deployable, and undeployable objects refer to Converted Output Format.
Procedure¶
To migrate SSL Orchestrator Configuration from BIG-IP to BIG-IP Next:
1. Get the configuration from BIG-IP SSL Orchestrator¶
Get the Configuration iFile from UCS of BIG-IP SSL Orchestrator. A user configuration set (UCS) which is an archive file that contains a backup of your BIG-IP configuration data. You can execute the following command to obtain the iFile:
cachepath=$(curl -sku "admin:admin" https://<MGMT-IP>/mgmt/tm/sys/file/ifile/ssloF_global.app~SSLOiFile?options=-hidden -H "Content-Type: application/json" |jq '.cachePath' | sed -e 's/"//g') cachepath_cmd="{\"command\":\"run\",\"utilCmdArgs\":\" -c 'cp ${cachepath} /shared/images/ssloifile'\"}" curl -sku "admin:admin" -H "Content-Type: application/json" -X POST https://<MGMT-IP>/mgmt/tm/util/bash -d ${cachepath_cmd} curl -sku "admin:admin" -X GET https://<MGMT-IP>/mgmt/cm/autodeploy/software-image-downloads/ssloifile
For more information refer to Backing up and restoring BIG-IP configuration files with a UCS archive (f5.com).
2. Getting started with SSL Orchestrator Config Converter¶
Execute the docker pull command.
docker pull f5devcentral/f5-ssl-orchestrator-config-converter:latest
Create an output file using SSL Orchestrator Converter and grant write access on the file to other users including f5docker.
touch scc_output.json chmod a+rw scc_output.json
Execute the converter container using docker command:
docker run --rm -v "$PWD":/usr/app/data <IMAGE>:<TAG> -i "data/<local_ifile_path/<input_ifile_name>>" -o "data/<local_output_file_path>" -loglevel info -log "data/<local_output_log_file_path>"
3. Create iRules in Central Manager as per your requirement¶
If any of the inspection services that you want to migrate include iRules, create the required iRules in Central Manger before posting the inspection services. You can get the information about the iRules from BIG-IP Conf file in UCS.
4. Post the payloads¶
You can post the payloads using a script or you can post the payloads manually.
Post the payloads using postToCMScript.sh script
Run the docker with the below command:
docker run -it --rm f5devcentral/f5-ssl-orchestrator-config-converter:latest
Execute the following command to run postToCMScript.sh script to post the configuration to Central Manager. It will take the sccOutput.json generated by the SCC docker as the input. Provide Central Manager IP address and the SCC output file path.
<path to sourcecode>/sslo-config-converter/scripts/postToCMScript.sh -cm_ip <CM-IP> -scc_output <path>scc_output.txt
Post the payloads manually
After receiving the payloads (output from the converter), you must manually run the SSL Orchestrator Central Manager APIs with the payloads received in step 3 in order to perform the following steps:If the inspection services include iRules, replace the iRule name with the iRule UUID in the payload before posting the payloads.
Post Inspection Services to Central Manager. Refer to the respective Inspection Service topic in the Inspection Services section. Inspection Services
Add inspection service UUIDs to the service chain payload and then execute the create service chain API. Refer to How To: Configure a Service Chain
Add Service chain UUIDs obtained in the previous step to the Policy payload and then execute the create policy API. Refer to How to: Manage Security Policies
Next Steps¶
If your configuration included an ICAP service, before deploying the service, you must update the VLAN name for the service (which is set to ‘fixMe’ by the converter)
Deploy the inspections services to BIG-IP Next Instances. Refer to How To: Deploy a service to a BIG-IP Instance using CM APIs
Create Application stack with the appropriate migrated policies to simulate BIG-IP SSL Orchestrator Topologies and deploy the application stack to required BIG-IP Next instances. Refer to How to: Manage applications using BIG-IP Next Central Manager and FAST templates
Additional References¶
Converted Output Format¶
Depending on your existing BIG-IP SSL Orchestrator configuration, you will get the output JSON file that will include the payloads for Inspection Services, Service Chains, and Policies; along with the statuses (that is, Deployable, Strictly Undeployable, or Partially Deployable).
The converted output will have the inspection services, Service chains, and policies (based on your SSL Orchestrator Configuration) and each object will have the following attributes:
name: Refers to the name of the object.
status: Refers to the status of the object that is deployable, partially deployable, or strictly undeployable.
strictly undeployable: The object cannot be deployed to Central Manager and you can view the reason in
unsupportedPropertiesattribute.partially deployable: The object can be deployed to Central Manager but certain unsupported attributes may have been removed from the payload.
deployable: The object can be deployed to Central Manager.
associatedObjects: Refers to other objects it is associated with. An inspection service can have iRules as an associated object. A Service chain has inspection services as its associated object. A policy can have service chains as its associated objects.
unsupportedProperties: Also, includes the reason why an object is partially deployable or undeployable.
payload: The payload that you can post to save (inspection service, policy, or service chain) the object in Central Manager.
error: If the conversion fails due to any reason, the error message is displayed in the “error” attribute of the converted output.
Status Association¶
If an associated object has the status of “strictly undeployable,” it will override the status of the referring object, even if the referring object’s status is “deployable.” The “Partially Deployable” status is only for the Inspection Service and doesn’t impact the payload, payload is still deployable but unsupported attributes that are not critical for SSL Orchestrator will dropped in the payload. Example: If an inspection service is strictly undeployable then the corresponding service chain that includes the inspection service would also become strictly undeployable. Similarly, if a service chain is strictly undeployable then the corresponding policy that includes the service chain would also become strictly undeployable.
Conversion Mapping¶
If a policy is referenced by both Inbound Gateway and Inbound Application in BIG-IP, SCC will clone the policy in the converted output.
The cloned Inbound Gateway type policy will have the suffix ‘-gw’ added to the name (example, ‘ssloP_inb-test-gw’ instead of ‘ssloP_inb-test’). The policyType is set to ‘inbound-gateway’.
For the Inbound Application type policy, the policy name will remain the same (example, ‘ssloP_inb-test’). The policyType is set to ‘default’.
The flow action ‘Abort’ in BIG-IP Policy is converted to ‘Reset’ in the converted output .
Following is an example output format:
{
"sslo": {
"inspectionServices": [
{
"name": "ssloS_l3inline_1",
"status": "deployable",
"associatedObjects": {"iRules" : []},
"payload": {
"foo": "bar",
"test": "blah"
}
},
{
"name": "ssloS_tap_1",
"status": "partially_deployable",
"associatedObjects": {"iRules" : []},
"unsupportedProperties": [
"Port remap is not supported."
],
"payload": {}
},
{
"name": "ssloS_icap_1",
"status": "strictly_undeployable",
"associated_objects": {"iRules" : []},
"unsupportedProperties": [
"Customer created generated iRule is not supported."
],
"payload": {}
}
],
"serviceChains": [
{
"name": "sslo_sc_chain1",
"status": "partially_deployable",
"associatedObjects": {
"inspectionServices" : ["ssloS_tap_1", "ssloS_l3inline_1"]
},
"payload": {}
},
{
"name": "sslo_sc_chain3",
"status": "strictly_undeployable",
"associatedObjects": {
"inspectionServices" : ["ssloS_icap_1"]
},
"unsupportedProperties": [
"Associated Inspection Service "ssloS_icap_1"is strictly undeployable, please look at that object for more details."
],
"payload": {}
}
],
"policies": [
{
"name": "sslo_p_policy1",
"status": "partially_deployable",
"associatedObjects": {
"serviceChains" : ["sslo_sc_chain1", "sslo_sc_chain2"]
},
"payload": {}
},
{
"name": "sslo_p_policy2",
"status": "strictly_undeployable",
"associatedObjects": {
"serviceChains" : ["sslo_sc_chain1", "sslo_sc_chain3"],
"dataGroups" : [""]
},
"unsupportedProperties": [
"Associated service-chain "sslo_sc_chain3"is strictly undeployable, please look at the service-chain for more details.",
"Use datagroup inside of policy rule condition is not supported",
"condition category lookup is not supported",
"action block page is not supported"
],
"payload": {}
}
]
},
"error": ""
}
Payload Examples¶
Payload Example of an ICAP Service¶
"payload": {
"name": "ssloS_ICAP_TEST1122",
"description": "Type: icap",
"type": "icap",
"requestModificationURI": "q",
"responseModificationURI": "q",
"serviceDownAction": "ignore",
"headerFrom": "from_icap",
"host": "Host_icap",
"referer": "referrer_",
"userAgent": "User_agent",
"previewLength": 1024,
"allowHTTP1.0": true,
"oneConnect": {
"sourceMask": "::"
},
"network": {
"vlan": "fixMe",
"endpoints": [
{
"endpointType": "L4BasicEndpoint",
"address": "1.2.3.4:1344"
}
],
"snat": {
"snatType": ""
}
},
"monitor": {},
"irules": []
}
Payload Example of a Service Chain¶
Note: Before posting a service chain to Central Manager, the service names in the payload must be replaced with corresponding UUIDs.
"payload": {
"name": "ssloSC_service_chanin1122",
"inspection_services": [
"ssloS_Http_tx1122",
"ssloS_ICAP_TEST1122",
"ssloS_TAP1122",
"ssloS_L3_serv112233"
]
}
Payload Example of an Inbound Application Mode Policy¶
Note: If a policy includes a service chain, before posting the policy to Central Manager, the service chain names in the payload must be replaced with corresponding UUIDs.
"payload": {
"attachIrule": false,
"description": "converted cBIP Policy",
"id": "",
"policyName": "ssloP_inbound_appTEST",
"policyType": "default",
"trafficRuleSets": [
{
"ruleType": "traffic",
"ruleStrategy": "first-match",
"rules": [
{
"name": "Rule-1001",
"actions": [
{
"actionType": "SSL_PROXY_BYPASS"
},
{
"actionType": "SERVICE_CHAIN",
"serviceChain": "ssloSC_service_chanin1122"
}
],
"conditions": [
{
"conditionType": "L4_PORT",
"values": [
80
],
"operator": "equals",
"local": false
}
]
},
{
"name": "All Traffic",
"actions": [
{
"actionType": "SSL_PROXY_INTERCEPT"
}
],
"conditions": []
}
]
}
]
}
Payload Example of an Inbound Gateway Mode Policy¶
"payload": {
"attachIrule": true,
"description": "converted cBIP Policy",
"id": "",
"policyName": "ssloP_inb_app-gw",
"policyType": "inbound-gateway",
"trafficRuleSets": [
{
"ruleType": "traffic",
"ruleStrategy": "first-match",
"rules": [
{
"name": "Rule-1001",
"actions": [
{
"actionType": "SSL_PROXY_BYPASS"
}
],
"conditions": [
{
"conditionType": "L4_PORT",
"values": [
44,
80,
443
],
"operator": "equals",
"local": false
},
{
"conditionType": "IP_PROTOCOL",
"values": [
17
],
"operator": "equals",
"local": false
}
]
},
{
"name": "All Traffic",
"actions": [
{
"actionType": "SSL_PROXY_INTERCEPT"
}
],
"conditions": []
}
]
}
]
}
Status scenarios and unsupported fields or configurations¶
The following table lists the statuses and unsupported fields/configurations.
| Object | Strictly Undeployable | Partially Deployable |
|---|---|---|
| TAP Service |
|
|
| ICAP Service |
|
|
| L3 Inline Service |
|
|
| HTTP Transparent Service |
|
Contains the following unsupported fields configured.
|
| Service Chain |
|
|
| Policy |
|