Implementing SSL Orchestrator - High Level Considerations
Introduction This article is the beginning of a multi-part series on implementing BIG-IP SSL Orchestrator. It includes high availability and central management with BIG-IQ. Implementing SSL/TLS Decryption is not a trivial task. There are many factors to keep in mind and account for, from the network topology and insertion point, to SSL/TLS keyrings, certificates, ciphersuites and on and on. This article focuses on pre-deployment tasks and preparations for SSL Orchestrator. This article is divided into the following high level sections: Solution Overview Customer Use Case Architecture & Network Topology Please forgive me for using SSL and TLS interchangeably in this article. Software versions used in this article: BIG-IP Version: 14.1.2 SSL Orchestrator Version: 5.5 BIG-IQ Version: 7.0.1 Solution Overview Data transiting between clients (PCs, tablets, phones etc.) and servers is predominantly encrypted with Secure Socket Layer (SSL) and its evolution Transport Layer Security (TLS)(ref. Google Transparency Report). Pervasive encryption means that threats are now predominantly hidden and invisible to security inspection unless traffic is decrypted.The decryption and encryption of data by different devices performing security functions potentially adds overhead and latency.The picture below shows a traditional chaining of security inspection devices such as a filtering web gateway, a data loss prevention (DLP) tool, and intrusion detection system (IDS) and next generation firewall (NGFW). Also, TLS/SSL operations are computationally intensive and stress the security devices’ resources.This leads to a sub-optimal usage of resource where compute time is used to encrypt/decrypt and not inspect. F5’s BIG-IP SSL Orchestrator offers a solution to optimize resource utilization, remove latency, and add resilience to the security inspection infrastructure. F5 SSL Orchestrator ensures encrypted traffic can be decrypted, inspected by security controls, then re-encrypted—delivering enhanced visibility to mitigate threats traversing the network. As a result, you can maximize your security services investment for malware, data loss prevention (DLP), ransomware, and next-generation firewalls (NGFW), thereby preventing inbound and outbound threats, including exploitation, callback, and data exfiltration. The SSL Orchestrator decrypts the traffic and forwards unencrypted traffic to the different security devices for inspection leveraging its optimized and hardware-accelerated SSL/TLS stack.As shown below the BIG-IP SSL Orchestrator classifies traffic and selectively decrypts traffic.It then forwards it to the appropriate security functions for inspection.Finally, once duly inspected the traffic is encrypted and sent on its way to the resource the client is accessing. Deploying F5 and inline security tools together has the following benefits: Traffic Distribution for load sharing Improve the scalability of inline security by distributing the traffic across multiple Security appliances, allowing them to share the load and inspect more traffic. Agile Deployment Add, remove, and/or upgrade Security appliances without disrupting network traffic; converting Security appliances from out-of-band monitoring to inline inspection on the fly without rewiring. Customer Use Case This document focuses on the implementation of BIG-IP SSL Orchestrator to process SSL/TLS encrypted traffic and forward it to a security inspection/enforcement devices. The decryption and forwarding behavior are determined by the security policy. This ensures that only targeted traffic is decrypted in compliance with corporate and regulator policy, data privacy requirements, and other relevant factors. The configuration supports encrypted traffic that originates from within the data center or the corporate network.It also supports traffic originating from clients outside of the security perimeter accessing resources inside the corporate network or demilitarized zone (DMZ) as depicted below. The decrypted traffic transits through different inspection devices for inbound and outbound traffic. As an example, inbound traffic is decrypted and processed by F5’s Advanced Web Application Firewall (F5 Advanced WAF) as shown below. *Can be encrypted or cleartext as needed As an example, outbound traffic is decrypted and sent to a next generation firewall (NGFW) for inspection as shown in the diagram below. The BIG-IP SSL Orchestrator solution offers 5 different configuration templates. The following topologies are discussed in Network Insertion Use Cases. L2 Outbound L2 Inbound L3 Outbound L3 Inbound L3 Explicit Proxy Existing Application In the use case described herein, the BIG-IP is inserted as layer 3 (L3) network device and is configured with an L3 Outbound Topology. Architecture & Network Topology The assumption is that, prior to the insertion of BIG-IP SSL Orchestrator into the network (in a brownfield environment), the network looks like the one depicted below.It is understood that actual networks will vary, that IP addressing, L2 and L3 connectivity will differ, however, this is deemed to be a representative setup. Note: All IP addressing in this document is provided as examples only.Private IP addressing (RFC 1918) is used as in most corporate environments. Note: the management network is not depicted in the picture above.Further discussion about management and visibility is the subject of Centralized Management below. The following is a description of the different reference points shown in the diagram above. a.This is the connection of the border routers that connect to the internet and other WAN and private links. Typically, private IP addressing space is used from the border routers to the firewalls. b.The border switching connects to the corporate/infrastructure firewall.Resilience is built into this switching layer by implementing 2 link aggregates (LAG or Port Channel ®). c.The “demilitarized zone”(DMZ) switches are connected to the firewall.The DMZ network hosts application that are accessible from untrusted networks such as the Internet. d.Application server connect into the DMZ switch fabric. e.Firewalls connect into the switch fabric.Typically core and distribution infrastructure switching will provide L2 and L3 switching to the enterprise (in some case there may be additional L3 routing for larger enterprises/entities that require dynamic routing and other advanced L3 services. f.The connection between the core and distribution layers are represented by a bus on the figure above because the actual connection schema is too intricate to picture.The writer has taken the liberty of drawing a simplified representation.Switches actually interconnect with a mixture of link aggregation and provide differentiated switching using virtualization (e.g. VLAN tagging, 802.1q), and possibly further frame/packet encapsulation (e.g. QinQ, VxLAN). g.The core and distribution switching are used to create 2 broadcast domains. One is the client network, and the other is the internal application network. h.The internal applications are connected to their own subnet. The BIG-IP SSL Orchestrator solution is implemented as depicted below. In the diagram above, new network connections are depicted in orange (vs. blue for existing connections).Similarly to the diagram showing the original network, the switching for the DMZ is depicted using a bus representation to keep the diagram simple. The following discusses the different reference points in the diagram above: a.The BIG-IP SSL Orchestrator is connected to the core switching infrastructure A new VLAN and network are created on the core switching infrastructure to connect to the firewalls (North) to the BIG-IP SSL Orchestrator devices. b.The client network (South) is connected to the BIG-IP via a second VLAN and network. c.The SSL Orchestrator devices are connected to a newly created inspection network.This network is kept separate from the rest of the infrastructure as client traffic transits through the inspection devices unencrypted.As an example, Web Application Firewalls (BIG-IP ASM) are used to filter inbound traffic. d. The LAN configuration for the connection to the BIG-IP ASM is as depicted below. e. The NGFW is connected to the INSPECTION switching network in such a manner that traffic traverses it when the BIG-IP SSL Orchestrator is configured to push traffic for inspection. Summary This article should be a good starting point for planning your initial SSL Orchestrator deployment. We covered the solution overview and use cases. The network topology and architecture was explained with the help of diagrams. Next Steps Click Next to proceed to the next article in the seriesImplementing SSL Orchestrator - Guided Configuration
Introduction This article is part of a series on implementing BIG-IP SSL Orchestrator. It includes high availability and central management with BIG-IQ. Implementing SSL/TLS Decryption is not a trivial task. There are many factors to keep in mind and account for, from the network topology and insertion point, to SSL/TLS keyrings, certificates, ciphersuites and on and on. This article focuses on the SSL Orchestrator Guided Configuration and everything you need to know about it. This article is divided into the following high level sections: Configuration prerequisites Deployment Topology SSL certificate and key settings Service properties Security policy Interception rule Please forgive me for using SSL and TLS interchangeably in this article. Software versions used in this article: BIG-IP Version: 14.1.2 SSL Orchestrator Version: 5.5 BIG-IQ Version: 7.0.1 Configuration Prerequisites From the BIG-IP Configuration Utility click SSL Orchestrator > Configuration.This is the default landing page when SSL Orchestrator is not configured.The configuration options are presented on this page.Notice the Required Configuration settings on the top right.For DNS click the link to configure. Enter the IP address of the DNS server you wish to use and click Add.You can add multiple DNS servers.Click Update when done. Click SSL Orchestrator > Configuration.For NTP click the link to configure. Enter the IP address or hostname of the NTP server you wish to use and click Add.You can add multiple NTP servers.Click Update when done. Click SSL Orchestrator > Configuration.For Route click the link to configure. Name it.In this example it’s default_route.Enter the correct Destination and Netmask.In this example we’re using 0.0.0.0 as this is a default route.Enter the Gateway IP Address, in this example 10.0.0.1. Click Finished. Click SSL Orchestrator > Configuration.The Required Configuration section should look like the following. Deployment Topology We are now ready to begin the Guided Configuration.Click Next at the bottom. Choose the Topology you would like to deploy.In this example we will configure an L3 Outbound Topology. Name the Topology.For the Protocol choose Any.Select L3 Outbound then click Save & Next Note: some of the available Topologies might be greyed out if not supported by your platform.As an example, virtual machines don’t support L2. SSL Certificate and Key Settings Leave the Certificate Key Chain settings to their defaults. Edit the existing CA Certificate Key Chain by clicking the pencil icon. In a previous article you installed your own private key and certificate.Click the down arrow on the right to select that Certificate and Key.Click Done. Click Save & Next Notes: The difference between the Cert Key Chain and the CA Cert Key Chain: Certificate Key Chain – the certificate key chain represents the certificate and private key used as the “template” for forged server certificates. While re-issuing server certificates on-the-fly is generally easy, private key creation tends to be a CPU-intensive operation. For that reason, the underlying SSL Forward Proxy engine forges server certificates from a single defined private key. This setting gives customers the opportunity to apply their own template private key, and optionally store that key in a FIPS-certified HSM for additional protection. The built-in “default” certificate and private key uses 2K RSA and is generated from scratch when the BIG-IP system is installed. The pre-defined default.crt and default.key can be left as is. CA Certificate Key Chain – an SSL forward proxy must re-sign, or “forge” remote server certificate to local clients using a local certificate authority (CA) certificate, and local clients must trust this local CA. This setting defines the local CA certificate and private key used to perform the forging operation. Service Properties Click Add Service You can choose from many pre-defined templates from different security vendors.In this example select Palo Alto Networks NGFW Inline Layer 2 then click Add. Give it a name.Under Network Configuration click Add. Here you define the VLANS that the Palo Alto is connected to (or will be connected to).You can use existing ones or create new VLANS.We will create new ones by choosing the Create New radio button. Give each VLAN a unique name to help remember which device it’s connected to and in which direction data flows.Select the Interface from the drop-down menu.Click Done. Enable the Port Remap option and leave the port at 80. Click Save Notes: SSL Orchestrator allows for the insertion of additional iRule logic at different points. An iRule defined at the service only affects traffic flowing across this service. It is important to understand, however, that these iRules must not be used to control traffic flow (ex. pools, nodes, virtuals, etc.), but rather should be used to view/modify application layer protocol traffic. For example, an iRule assigned here could be used to view and modify HTTP traffic flowing to/from the service. Click Save & Next Click the button to Add a Service Chain List Give it a name.Click the arrow in the middle to move the Palo Alto Service to the Selected side.Click Save. Note: When you have multiple Services in a Service Chain you can adjust the order that they are used. Your screen should like the following.Click Save & Next. Security Policy The Security Policy is next.Notice you have the option to create new or use an existing one.By default, the policy should look like this. The Name is populated automatically but can be changed.If you click the pencil icon to the far right of the Pinners_Rule you can see the contents of the rule. The Pinners_Rule checks to make sure the content is SSL/TLS.It also checks the category “Pinners” which contains websites with Pinned Certificates.Sites in the category Pinners are automatically set to Bypass decryption.It is recommended to keep this setting. Notes: If you have a URL categorization database you can also bypass decryption based on website category. Conditions can be toggled between Match Any and Match All.Actions can be to Allow or Reject.Also note the Service Chain is bypassed by default.However, you can choose to send the encrypted content through the Security Chain. Click Cancel. The Pinners Category can be viewed/edited from SSL Orchestrator > Policies > URL Categories.Expand Custom Categories and you will see the Pinners category.Click Pinners (custom) to view and/or edit the sites. Back to the Security Policy.Click the pencil icon to the far right of the All Traffic rule to edit it. Set the Service Chain to the one created previously, in this case it’s ssloSC_SecurityServiceChain.Click OK. Click Save & Next at the bottom. Interception Rule Next is the Interception Rule.For Ingress Network select the VLAN that internal clients connect through.In this example select INTERNAL and click the arrow to move it to Selected.Note that you can also create VLANS from this screen. Click Save & Next at the bottom. Notes:L7 Interception Rules – FTP and email protocol traffic are all “server-speaks-first” protocols, and therefore SSL Orchestrator must process these separately from typical client-speaks-first protocols like HTTP. This selection enables processing of each of these protocols, which create separate port-based listeners for each. As required, selectively enable the additional protocols that need to be decrypted and inspected through SSL Orchestrator. Egress Settings For the Egress Settings Click Save & Next at the bottom. Last is the Summary screen.You can review and edit any of the Configurations we just went through.Click Deploy when done.The next screen should look like the image below. Click OK and you should see something like the following: Notes: The Palo Alto Service is shown as DOWN in red.This is because we haven’t configured it yet.We’ll do that in the next article. Summary In this article you learned how to use the SSL Orchestrator Guided Configuration to do the following: Configuration prerequisites Deployment Topology SSL certificate and key settings Service properties Security policy Interception rule Next Steps Click Next to proceed to the next article in the series.Implementing SSL Orchestrator - L2 Mode Deployment
Introduction This article shows you how to deploy SSL Orchestrator in Layer 2 (L2) mode This article is divided into the following high level sections: Network Topology Requirements Best Practices Known Limitations Please forgive me for using SSL and TLS interchangeably in this article. Software versions used in this article: BIG-IP Version: 14.1.2 SSL Orchestrator Version: 5.5 BIG-IQ Version: 7.0.1 Network Topology The diagram below is a representation of the actual lab network where SSL Orchestrator was deployed and tested. Before SSL Orchestrator After SSL Orchestrator All routing configuration is static routing – no dynamic routing protocols is implemented in this design.Dynamic Routing was not considered for this article series. Example Port Object/Channel and MLAG configuration from North Switch1: interface Port-Channel511 switchport trunk allowed vlan 511 switchport mode trunk mlag 511 interface Port-Channel512 switchport trunk allowed vlan 511 switchport mode trunk mlag 512 mlag configuration domain-id mlag1 heartbeat-interval 2500 local-interface Vlan4094 peer-address 172.16.0.2 peer-link Port-Channel10 reload-delay 150 Requirements BIG-IP Version: 14.1.2 SSL Orchestrator Version: 5.5 BIG-IQ Version: 7.0.1 NGWF Version: Details are beyond the scope of this discussion – note that NGWF is configured with vWire and performs its inspection as a transparent L2 device. Adv. WAF: Details are beyond the scope of this discussion – for this implementation, the Advanced WAF module is running on a separate BIG-IP platform. Configuration of BIG-IP deployed as SSL Orchestrator can be downloaded fromherein GitLab. Demo videos are available for both Inbound and Outbound use cases: Outbound Traffic Inspection Inbound Traffic Inspection Best Practices for SSL Orchestrator Deployment BIG-IP Recommendations The following provides salient recommendations, these and others are discussed in detail in theSSL Orchestrator Document. AutoMap AutoMap is a secure network address translation (SNAT) described in Knowledge articleK7336. AutoMap should not be used where possible in BIG-IP SSL Orchestrator deployments. Please refer toK7820for SNAT uses and best practices.With BIG-IP configurations (SSLO or other modules), whenever a large number of connections are going to require SNAT, you want to make sure that SNAT pools are used to avoid port collisions (running out of ephemeral ports to initiate the connection). Debug Logging Traffic through BIG-IP SSL Orchestrator will transit through different services as defined in the service chain.Enabling debug will generate logs as traffic traverses the different services – this can be very verbose and generate large amounts of traffic. It is recommended to leverage debug logging for troubleshooting only. Security Recommendations The following recommendations can also be found in theSSL Orchestrator Document. SSL Orchestrator and Service Proximity SSL Orchestrator is almost never first in an enterprise architecture, so other security devices (proxies, firewalls, IPSs, sandboxes, etc.) are already deployed. If you ask any network and/or security admin, 99% of the time they have no interest in moving those security devices or re-architecting anything else when SSL Orchestrator is introduced. However, remember that the traffic being sent to and from the security devices is unencrypted, so sending traffic across an existing enterprise network to some security device is also sending passwords, credit card numbers, and other protected data (HIPAA, PCI, etc.), across an uncontrolled span of network where any connected device can see it in clear text. It is therefore brutally important that customers understand this, and that they do move those security devices to networks that are behind and protected by SSL Orchestrator. In a perfect situation, no traffic should be able to reach these security devices except through SSL Orchestrator. As frightening as the possibility of a data exposure is, there are going to be customers that ignore the warnings. You should therefore do your best to convey this security best practice to customers as their trusted advisor. This is the reason for the “Auto-Manage” field in the configuration for the services. It creates non- overlapping, internal, non-routable address spaces for each service and encourages customers to protect them. If disabling this, and changing the inline service IP spaces, take care to protect these. Known Limitations It is recommended to consult with the Knowledge ArticleK00805840for current known issues and workarounds. Strictness Underlying the BIG-IP SSL Orchestrator is the BIG-IP TMOS infrastructure.The BIG-IP SSL Orchestrator provides a guided configuration front-end to configure TMOS to build the services, and different policies to make the solution work as designed. If the administrator were to dive deeper in the low-level configuration of the device after building a topology, the configuration would contain BIG-IP configuration items – refer to Appendix C for sample configuration for a simple SSL Orchestrator configuration. The notion of strictness is introduced to “lock” the configured items in such a manner as to prevent the administrator to be able to modify the underlying object without using the SSL Orchestrator interface. Any attempt to modify an object that is strictly managed will result in an error message as shown below: Gossip For BIG-IP SSL Orchestrator deployed in redundant pairs, BIG-IP should be in manual/full sync mode (Device Management>>Device Group).For more information related to BIG-IP high availability (HA) configuration, refer to theuser guide. The traditional synchronization mechanism is augmented with “gossip” for the SSL Orchestrator.This synchronization mechanism is independent from typical LTM config sync.For the version of BIG-IP SSL Orchestrator used for this deployment, ”gossip” config sync is two-way automatic."gossip" uses REST API calls for the SSL Orchestrator related part of the config sync.If a change is made to one device in the pair, it is automatically propagated to the other device.This differs from the traditional BIG-IP sync behavior. SSL Orchestrator config needs to be re-deployed if a STANDALONE environment is changed to an HA environment. Also, you need to make sure VLAN configuration is the same on both the box for successful re-deployment. Summary This article should be a good starting point for planning your initial SSL Orchestrator deployment. The network topology and architecture was explained with the help of diagrams. We also went over the software requirements, best practices and known limitations. Next Steps Click Next to proceed to the next article in the series.Implementing SSL Orchestrator - L3 Mode Deployment
Introduction This article shows you how to deploy SSL Orchestrator in Layer 3 (L3) mode This article is divided into the following high level sections: Network Topology Requirements Best Practices Known Limitations Please forgive me for using SSL and TLS interchangeably in this article. Software versions used in this article: BIG-IP Version: 14.1.2 SSL Orchestrator Version: 5.5 BIG-IQ Version: 7.0.1 Network Topology The diagram below is a representation of the actual lab network where SSL Orchestrator was deployed and tested. Before SSL Orchestrator After SSL Orchestrator All routing configuration is static routing – no dynamic routing protocols is implemented in this design.Dynamic Routing was not considered for this article series. The design allows for the administrator to gradually forward services to the BIG-IP SSL Orchestrator using source-based routing rules.The end-result is to have all outbound and inbound traffic traversing the BIG-IP SSL Orchestrator solution. Requirements BIG-IP Version: 14.1.2 SSL Orchestrator Version: 5.5 BIG-IQ Version: 7.0.1 NGWF Version: Details are beyond the scope of this discussion – note that NGWF is configured with a "Virtual Wire" and performs its inspection as a transparent L2 device. Adv. WAF: Details are beyond the scope of this discussion – for this implementation, the Advanced WAF module is running on a separate BIG-IP platform. Configuration of BIG-IP deployed as SSL Orchestrator can be downloaded fromherefrom GitLab. Demo videos are available for both Inbound and Outbound use cases: Outbound Traffic Inspection Inbound Traffic Inspection Best Practices for SSL Orchestrator Deployment BIG-IP Recommendations The following provides salient recommendations, these and others are discussed in detail in theSSL Orchestrator Document. AutoMap AutoMap is a secure network address translation (SNAT) described in Knowledge articleK7336. AutoMap should not be used where possible in BIG-IP SSL Orchestrator deployments. Please refer toK7820for SNAT uses and best practices.With BIG-IP configurations (SSLO or other modules), whenever a large number of connections are going to require SNAT, you want to make sure that SNAT pools are used to avoid port collisions (running out of ephemeral ports to initiate the connection). Debug Logging Traffic through BIG-IP SSL Orchestrator will transit through different services as defined in the service chain.Enabling debug will generate logs as traffic traverses the different services – this can be very verbose and generate large amounts of traffic. It is recommended to leverage debug logging for troubleshooting only. Security Recommendations The following recommendations can also be found in theSSL Orchestrator Document. SSL Orchestrator and Service Proximity SSL Orchestrator is almost never first in an enterprise architecture, so other security devices (proxies, firewalls, IPSs, sandboxes, etc.) are already deployed. If you ask any network and/or security admin, 99% of the time they have no interest in moving those security devices or re-architecting anything else when SSL Orchestrator is introduced. However, remember that the traffic being sent to and from the security devices is unencrypted, so sending traffic across an existing enterprise network to some security device is also sending passwords, credit card numbers, and other protected data (HIPAA, PCI, etc.), across an uncontrolled span of network where any connected device can see it in clear text. It is therefore brutally important that customers understand this, and that they do move those security devices to networks that are behind and protected by SSL Orchestrator. In a perfect situation, no traffic should be able to reach these security devices except through SSL Orchestrator. As frightening as the possibility of a data exposure is, there are going to be customers that ignore the warnings. You should therefore do your best to convey this security best practice to customers as their trusted advisor. This is the reason for the “Auto-Manage” field in the configuration for the services. It creates non- overlapping, internal, non-routable address spaces for each service and encourages customers to protect them. If disabling this, and changing the inline service IP spaces, take care to protect these. Known Limitations It is recommended to consult with the Knowledge ArticleK00805840for current known issues and workarounds. Strictness Underlying the BIG-IP SSL Orchestrator is the BIG-IP TMOS infrastructure.The BIG-IP SSL Orchestrator provides a guided configuration front-end to configure TMOS to build the services, and different policies to make the solution work as designed. If the administrator were to dive deeper in the low-level configuration of the device after building a topology, the configuration would contain BIG-IPconfiguration items – refer to Appendix C for sample configuration for a simple SSL Orchestrator configuration. The notion of strictness is introduced to “lock” the configured items in such a manner as to prevent the administrator to be able to modify the underlying object without using the SSL Orchestrator interface. Any attempt to modify an object that is strictly managed will result in an error message as shown below: Gossip For BIG-IP SSL Orchestrator deployed in redundant pairs, BIG-IP should be in manual/full sync mode (Device Management>>Device Group).For more information related to BIG-IP high availability (HA) configuration, refer to theuser guide. The traditional synchronization mechanism is augmented with “gossip” for the SSL Orchestrator.This synchronization mechanism is independent from typical LTM config sync.For the version of BIG-IP SSL Orchestrator used for this deployment, ”gossip” config sync is two-way automatic."gossip" uses REST API calls for the SSL Orchestrator related part of the config sync.If a change is made to one device in the pair, it is automatically propagated to the other device.This differs from the traditional BIG-IP sync behavior. SSL Orchestrator config needs to be re-deployed if a STANDALONE environment is changed to an HA environment. Also, you need to make sure VLAN configuration is the same on both the box for successful re-deployment. Summary This article should be a good starting point for planning your initial SSL Orchestrator deployment. The network topology and architecture was explained with the help of diagrams. We also went over the software requirements, best practices and known limitations. Next Steps Click Next to proceed to the next article in the series.Orchestrated Infrastructure Security - Getting Started
Note:TheBeaconcapabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latesthere. Introduction A typical daisy-chained security stack is difficult to manage and make changes.All devices in the chain are physically wired to each other in a serial arrangement.Each device performs SSL decryption and re-encryption when needed.All devices in the chain need to have similar performance capabilities.All devices in the chain need to be properly configured to route traffic to their neighboring devices, and likely will need to be manually configured to trust SSL certificates used by neighboring devices for decryption and re-encryption. Failure of any device in the security chain brings the entire chain down.Capacity cannot be increased simply by adding another like-device (i.e. a NGFW) to the chain.Capacity can only be increased by replacing a single device with a higher capacity device. Removing or adding a device to the chain is problematic.For one, the entire security stack will need to be unavailable while removing or adding a device.Proper routing between devices must be maintained or the whole chain will not pass traffic.Certificate trust and other factors may need to be addressed as well. High availability is also problematic.The only way to ensure high availability is to create another daisy-chain, identical to the first.This chain needs to wait in standby mode until the primary chain fails or is taken down, and then the standby chain can take over for the primary. Managing a single daisy chain security stack is not easy.Managing two for high availability is significantly more complicated and overly expensive. Some security devices are deployed differently and cannot operate together in the security stack.Those devices would need their own separate deployment from the devices in the daisy chain, further complicating the configuration.As an example, it’s not an uncommon security practice to employ network TAP devices, explicit proxies, ICAP servers as well as Layer2/3 devices. All of these devices cannot be configured to properly route traffic in a daisy chain. SSL Orchestrator solves almost all of these challenges, and enables you to have a nimble security solution capable of adapting to almost any type of threat. High Level Network Topology The network topology used for this setup is below.BIG-IP-11 and 12 are deployed in Layer 2 mode. The Advanced WAF and AFM devices will also be deployed in Layer 2 and will be physically wired to the SSL Orchestrators.This is a high availability environment where there is one Active BIG-IP and one ready on Standby.The Port Objects (511 & 512) allow traffic to flow through either BIG-IP, in case of a failure.The applications being protected are represented by the Ubuntu servers connected to the South switch. BIG-IP Network Topology A zoomed in view of the BIG-IP devices is below.This shows the physical connectivity and the specific interfaces used by SSL Orchestrator, Advanced WAF and AFM devices. Summary This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability, Central Management with BIG-IQ, Application Visibility with Beacon and the protection of critical assets using F5 Advanced WAF and Protocol Inspection (IPS) with AFM.It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working. Next Steps Click Next to proceed to the next article in the series.
F5 GTM Topology - load balance one wideip with 2 datacenters
Hi DC members, I have some confusions in deploying the GTM toplogy. As from my understanding, there are 2 methods to LB using the topology : 1. WideIP Level 2. Pool Level Here is the setup : DC 1 : 2 x LTM (HA) , 1 x GTM DC 2 : 2 x LTM (HA) , 1 x GTM 2 sets of users : Country A, Country B. The requirements : Both users (CountryA & CountryB) will be using the same WideIP (ie: Scenario: User from Country A will have to connect apps in DC1 , and in the event of server failure in DC1, it will be routed to DC2, User from Country B will have to connect apps in DC2 , and in the event of server failure in DC2, it will be routed to DC1, vice versa. Below is my configurations : Wide IP : www.abc.com , PoolA : VS1 in DC1, VS2 in DC2, LB Method : Topology Topology records: Subnet A , Destination DC1, Weight = 200 | Subnet A , Destination DC2, Weight = 100 | Subnet B , Destination DC2, Weight = 200 | Subnet B , Destination DC1, Weight = 100 Does this configurations correct? Thanks in advance!
GTM and Topology
Hi, I am quite new to DNS/GTM stuff so I had no chance yet to dig into how Topology LB works and what can be done. Wonder if such configuration is possible: Setup: Two DC - DC1 and DR1 LDNS in each DC sending request to GTM (LDNS_DC1, LDNS_DR1) Servers in each DC - defined as Generic Host GTM serwing one Wide IP pointing to Servers in both DC I would like to achieve this result: When LDNS_DC1 sends request logic is: If there is any Srv active in DC1 return IP of any (based on RR) If there is no active Srv in DC1 return IP of any active Srv in DR1 (based on RR) When LDNS_DR1 sends request logic is: If there is any Srv active in DR1 return IP of any (based on RR) If there is no active Srv in DR1 return IP of any active Srv in DC1 (based on RR) So depending on which LDNS issued request logic is switched around. Is that possible without iRule using just LB available at Wide IP and Pool level? Side question: Which LB methods will work at all for Generic Host? I guess in this case all is based on analyzing communication between LDNS and GTM (no data that is provided when BIG-IP type of server is used)
GTM Wide IP Topology Based Load Balancing
Hello, I'm interested in creating an active / active GTM record that load balances at the wide IP level based on typologies. We already have a small implementation in place where I work that was setup before my time, but I've been getting inconsistent results. Basically I have a wide IP created with two pools and only one server in each pool. There is a topology record created as follows:  My source IP is 10.67.36.12 so based on the topology record defined above I should always get directed to Virtual-CGS Topology, but when I test it out I'll sometimes go to Virtual-CGS and sometimes Virtual-PD. From reading documentation it reads like this type of topology setup is more for load balancing at the pool level and not wide IP level? Is that the case? Cheers, Brian
GTM Topology - LDNS Request
Hello! I have some doubts how the GTM works in its Topology LB records. If I have the following: WIP Pool www.mydomain.com Pool A <- Prefered: Topology, Alternate: Round Robin, Fallback:Return to DNS www.otherdomain.com Pool B <- Prefered: Topology, Alternate: Round Robin, Fallback:Return to DNS www.onedomain.com Pool C <- Prefered: Topology, Alternate: Round Robin, Fallback:Return to DNS www.lastdomain.com Pool D <- Prefered: Topology, Alternate: Round Robin, Fallback:Return to DNS Order LDNS Request Source Destination Weight 1 10.20.0.0/16 Pool A 1 2 10.30.0.0/16 Pool B 1 3 10.40.0.0/16 Pool A 1 4 10.0.0.0/16 Pool D 1 My Scenario Question are: 1- If a query is made for "www.mydomain.com" from source IP 10.20.0.1, Is Pool A served? 2- If a query is made for "www.mydomain.com" from source IP 192.168.10.1, Will Round Robin be served? 3- If a query is made for "www.lastdomain.com" from source IP 10.20.0.1, Is Pool D served? Will Topology logic not catch the first line 10.20.0.0/16 > Pool A? Thank you JohnR
GTM Topology Load Balancing - Order of Operation
Two-part question: 1.) For wide IP-level topology load balancing, what takes precedence: order, weight, or prefix length? (Assuming topology load balancing is choosing between pools based on source IP subnet). 2.) This question came about due to a situation in which I'm seeing some unexpected LB results. Given the below topology configuration (11.x) 1 IP Subnet is 10.0.1.0/29 Pool is West_DC_Pool 1 2 IP Subnet is 10.0.1.0/24 Pool is West_DC_Pool 150 3 IP Subnet is 10.0.0.0/24 Pool is East_DC_Pool 1 4 IP Subnet is 10.0.0.0/16 Pool is East_DC_Pool 100 The LDNS server IP is 10.0.1.5 (there's only one LDNS server at the moment) The East_DC_Pool is being chosen every time. Based on the logs, it seems to be comparing 1 (10.0.1.0/29 with a weight of 1) to 4 (10.0.0.0/16 with a weight of 100) and therefore 4 is winning based on a weight of 100. No mention of 2 (10.0.1.0/24 with a weight of 150) in the logs. If I delete 1, then 2 (10.0.1.0/24 with weight of 150) wins so traffic is then sent to West_DC_Pool. Now re-adding 1 (10.0.0.0/29 with weight 1) causes 4 (East_DC_Pool) to win again. Is this expected behavior??? I would have expected in all cases (with a LDNS IP of 10.0.1.5) that traffic would be routed to the West_DC_Pool based on either longest prefix match(1 would win), weight(2 would win), or order (again 1 would win). But maybe there's something about the order of operation that I'm unaware of. Thanks in advance, Dave
