One of the unused features of the F5 DNS product, formerly known as Global Traffic Manager (GTM) is the ability to host your DNS on F5’s high performing and hardened DNS implementation. In addition to screening or the typical GTM implementation of a delegated subdomain, DNS express actually hosts the DNS zone directly on the F5. It’s a lot faster than dealing with the on-box BIND or a remote BIND or Active Directory server. Also, I trust F5’s coding a lot more than Active Directory.
At a high level, the F5 is acting as a DNS slave to whatever master server you have configured. The Master DNS server pushes its config to the F5 slave. You can also have the master notify the F5 when it has updates. You’ll automatically get the updates on the DNS zone on the F5. Configured like this, you don’t need to change anything in your workflow to support your DNS infrastructure. You immediately get the benfit of F5’s high performance TMOS DNS implementation. At this point, you can set it as the resolver for internal or external DNS clients.
OneConnect, in F5’s BIG-IP, is a relief when your back-end servers become stressed by too many TCP negotiations. OneConnect can increase throughput by managing and reusing TCP connections created between the BIG-IP system and the back-end pool members. It works with HTTP Keep-Alives, and allows TCP connections to be held open for reuse by other clients.
With a routed configuration you are not using SNAT. Instead, you have the default gateway of all your servers set as the internal self IP address of the BIG-IP. In this scenario your back-end servers see the IP address of the clients that are connecting as the source address. When returning an answer to the client, the servers send it to their default gateway, the F5’s internal self IP. The BIG-IP then sends the response off to the client.
With OneConnect applied in this configuration you have control over what connections reuse open TCP connections from the Reuse Pool. The OneConnect mask is the mechanism to control this, also called the Source Prefix Length. The image below illustrates how this works.
Complications with SNAT
With a SNAT (Auto Map) configuration, you don’t set the default gateway on your back-end servers to be the BIG-IP. Instead, you translate the clients original IP address to that of your internal self IP. That ensures that all responses will return to the client via the BIG-IP.
With OneConnect applied to your VIP in this configuration, BIG-IP will always determine a connection to be eligible for reuse. OneConnect will apply the mask to the translated IP (which is always the same). If you are using SNAT Auto Map, you are effectively making your OneConnect Mask 0.0.0.0 without realizing it.
If instead of Auto Map you opted for a SNAT Pool or translation via iRule, your Reuse Pool could be divided by each translation IP. This might help in some corner case scenarios, but probably over complicates most situations.
Order of Operations with SNAT & OneConnect
The flow information F5 publishes on the topic is as follows:
First, TMOS performs the SNAT.
TMOS then applies the OneConnect Mask.
Finally, the system determines whether or not the address is available for a connection reuse.
We know that if you are SNATing to your internal self IP it will always use the same source address to your back-end servers. This is what the OneConnect Mask uses, so it will always reuse connections. If an application expects a single TCP connection to be a single user, that can be bad. This can be especially confusing when you think you have control over the reuse of the TCP connections.
F5 has published two KB articles with information concerning SNAT and OneConnect together:
“When a new connection is initiated to the virtual server, the BIG-IP system performs SNAT address translation on the source IP address, and then applies the OneConnect source mask to the translated SNAT IP address to determine whether it is eligible to reuse an existing idle connection.”
“If secure network address translation (SNAT) is configured, the BIG-IP system performs SNAT on the source IP address and then applies the OneConnect source mask to the translated SNAT IP address to determine whether it is eligible to reuse an existing idle connection.”
F5 KB Article K5911
Reading just the F5 documentation can put you in a loop of clicking back between those two articles. Hopefully this information has helped out and made their explanation and the issues to look for more clear. Let us know in the comments if you have other questions!
Looking for an MSP Load Balancer solution, the LBC has you covered! Whether basic help on your config or a fully managed service provider for your equipment, we can help.
Let’s face it, Load Balancers, such as our favorite, the F5 BIG-IP product line are hard devices to support. They span about as much of the entire width of technology as anything out there. Supporting them means you need to be a programmer, a security expert, an application expert, a network expert, and also a troubleshooting expert for all the technologies that go through the LB. How often is the issue something other than the F5, but the F5 team has to prove it so the other guys go fix it? A lot.
Want a subscription including management and licenses of your devices? Maybe managed security services of your on-prem devices with support? Perhaps a more traditional staff augmentation model with professional services included? We have experience with them all. With our team of certified engineers, you’ll have access to an entire group of people that focus on load balancing, but also know how to work with security, application and networking engineers. We work through our channel of partners, and you probably already have a relationship with one of our partners to integrate smoothly into your purchasing and procurement.
All of these reasons make the thought of MSP Load Balancer support contract sound pretty good. Finding engineers knowledgable in the ADC space is difficult, and training them is expensive and requires lots of downtime. Also, your team needs to understand so many different disciplines. It’s nearly impossible to find a single person that has that type of knowledge. Without an expert, you can’t use your investment in your load balancing infrastructure to its fullest.
Contact us to find out more about our team and a partner that’s the right fit for you!
F5 CORS can mean a few different things. Probably the most common, which we’ll look at here is enabling Cross-Origin Resource Sharing for the applications behind the BIG-IP. Alternatively, you can check out our article on actually enabling the BIG-IP to support CORS for the management GUI. You can also read a little bit about what CORS is. Another topic related to F5 CORS is what the ASM will allow and block when it sees CORS. Configuration of that is discussed in this F5 ASM CORS Support post here.
CORS has two types of requests, simple requests and requests that require more work. For basic requests, the browser is notified that this is OK with a simple header. For more complicated requests, you need to what’s called a pre-flight request to get some additional data before sending the actual request. What makes them complicated or simple is outside the scope of this post, but your application people should be able to tell you which of the methods you need to support.
The Mozilla CORS page gives a lot more detail if you want to get into the details of the requests.
Configuring F5 CORS
For the simple one, you just need to insert the “Access-Control-Allow-Origin:” header with the value of the domain that should be allowed to make the cross origin request. If you want any website on the internet to be allowed, just set an asterisk.
You can do this with just an HTTP profile and the header insert, or you can do it in an iRule and insert the header based on whatever conditions you want.
Preflighted requests are a bit trickier. First, you’ll intercept the OPTIONS request, and respond with the proper information for the client. Next, the client will send the actual request.
Rather than reinvent the iRule, you can take a look at this thorough example on devcentral: F5 cors iRule
One thing to note about the iRule, create a datagroup outside of the iRule as shown in one of the comments. That’s what they are there for, so use it.
Good luck, and feel free to comment if you’re having issues getting the iRule working either here or on DevCentral.
Determine the version you are upgrading from and too. Here is an excellent guide for determining if you will experience a smooth upgrade: Upgrade Path
Download the iso File of the version you are upgrading from Support.F5.com.
Learn of any new bugs that could cause issues with current configuration before updating.
Image updates are located here on the BIG-IP: System > Software Management > Image > Import
Hotfix updates are located here on the BIG-IP: System > Software Management > Hotfix List > Import > Browse > Locate > Image File
Create archives on both active and standby devices.
Download both archives to your local machine as a precaution.
Re-activate license before upgrading. Note: do not re-activate license while the unit is active — it will restart processes and disrupt traffic processing. Wait to re-activate the license on the second unit until it has been failed over.
Upload software images to both devices. If your change process allows for it, feel free to upload and install the image. It won’t affect traffic processing on the F5 and will reduce your time to completion during the actual change window.
Force standby device offline to ensure no failover occurs.
Install upgrade on standby device.
If you have access to the management console (such as on a virtual edition F5) or if you have a serial console server in the data center plugged into the F5, you can run the command, watch the shutdown and reboot processes. Once the login prompt appears, enter your local root credentials and use the following commands to monitor logs: tail -f /var/log/ltm. You’ll gain extra visibility and it’s comforting to see at what step in the upgrade process you are, rather than, staring at a circle spinning on the GUI.
Once you are able to access the GUI; give the F5 a few more minutes to finish up the boot processes.
Look at the system statistics. Check for CPU usage and Memory. It is normal for these to spike at initial boot. Watch for 3-5 minutes, compare the graphs with that over the past 24 hours, remember that your standby unit will show low utilization over the past 24 hours and you will see this increase as you fail over once you’re ready to proceed with the second unit. See if you notice any drastic changes that are not going away after about 5 minutes before moving on.
Take the unit we just upgraded out of Force Offline status. Verify that your Local Traffic configuration items (nodes, pool members, pools, VIPs) pass their health checks and maybe connect to a couple of high-priority VIPs via the F5’s CLI before failing over the active unit. Take note of the currently active unit’s connection counts in the F5 statistics, fail over and check the newly active unit’s connection statistics to make sure traffic is being processed no the newly active device. You can also check your floating traffic group in the device management section.
Cover your bases by having the load balanced applications checked out and validated independently by the app owner or business stakeholders. Ask them to sign off that the applications are still functioning correctly before moving on to the next device.
Application Security Manager gives you the ability to import a vulnerability assessment from a wide variety of scanners such as: Qualys, IBM Appscan, ImmuniWeb, Quotium Seeker, and White Hat Sentinel. Each scanning tool is configured slightly different.
First, run the scan. Once it has completed, view the report for that scan and download the XML file on your local machine. F5’s Application Security Manager only allows you to import XML files for vulnerability assessment. Login to the GUI of the active F5 that you would like to import the policy on. To do this go to: Security > Application Security > Vulnerability Assessment > Settings.
Next, we must enter which scanning tool we are using before importing the XML file. After selecting the tool used, go to: Security > Application Security > Vulnerability Assessment > Vulnerabilities
Click import on the top right and select the XML file that we just downloaded from our scanning tool. If it imported successfully, we should see the number of vulnerabilities that were discovered. After seeing the vulnerabilities, we can make changes to secure our policy.
Tweaking the Imported Results
The ASM will give you the following options to secure the newly found vulnerabilities:
Resolve and Staging: Adds the change to the policy, but does not enforce. This is helpful if the policy is in blocking mode since the change will not have the chance of blocking traffic.
Resolve: Adds the change to the policy and enforces. This will enable the change to take immediate effect. This can be dangerous if it creates a rule that restricts legitimate traffic to your application.
Ignore: Specifies that you do not want to make a changed based on the output of your scanning tool. If you chose “Resolve,” under the column “ASM Status,” you will see “Mitigated.” This means the ASM is doing its job at mitigating the vulnerability by exercising the appropriate defenses. Be sure to click “apply policy” in the upper right corner for your changes to take effect. The vulnerability assessment tool is an excellent addition to the toolset that Application Security Manager offers. However, this is not an absolute security method— these scanning tools do not always pick up on every threat. You still need to actively monitor the policies that are set in place. The scan can be automated to run anytime that fulfills your security needs and requirements.
To read more about the Qualys Community Edition scanning tool take a look at this guide: Qualys Setup.
Raise your hand if your login credentials have been stolen at some point in your internet life. I’m looking at you, EVERYBODY! 2.3 Billion credentials were stolen in 2017 alone, so if you’re on the internet, someone-somewhere has your credentials and has probably tried to use them somewhere. Nowadays, 80% – 90% of login traffic world-wide is solely from what are called, Credential Stuffing attacks. HSBC and Dunkin’ Donuts are just a couple of the more recent high-profile victims of this kind of brute-force attack. So what in the world is Credential Stuffing, and how can we protect our applications from it?
Recently, a customer wanted to have a custom F5 APM logon page branded. The GUI lets you do nothing more than just some colors or change the logo. With a little bit of web experience and a lot of F5 experience, I felt like I was up to the challenge. I started by diving into the advanced customization section of the APM module.