OneConnect with SNAT on F5

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.

Configuration Options

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.

The Source Prefix Length (One Connect Mask) determines what connections from the Reuse Pool are eligible for reuse by a new client connection.

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:

K7208: Overview of the OneConnect profile

On that page they say this:

“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.”

F5 KB Article K7208

There is then a link on that page to:

K5911: Managing connection reuse using OneConnect source mask

On that page they say this:

“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!

MSP Load Balancer

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

What is CORS?

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.

First, a quick recap on CORS. CORS is used when the browser is making an automated request to a site that is different than the one the user put in their browser. It’s a protection built-in by the browser that javascript isn’t allowed to send data all over the place. Often though, this is exactly what the application architects need to happen. In comes CORS. Basically, the site that is getting a request from a non-local origin needs to allow the request to come in.

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.

F5 BIG-IP Creating Custom Whitelists for DoS Profile

How to apply an IP whitelist to a DoS Profile. 

This is F5 BIG-IP version 13.1.1.

If you are looking at this screen trying to figure out how to add your custom address list in place of the Default list for a DoS Profile, you are not alone!

F5 does give you the ability to add addresses on the right hand side, pictured below. You can also create an address list under Security > Network Firewall > Address List.

This is an excellent feature. Now we just need to actually add this newly created list in place of the default list. As far as I can tell there is no way to do this on the GUI, but you can do this from the CLI.

SSH into the F5

Command:

tmsh modify security dos profile dos whitelist test-list

After dos profile you will enter the name of your dos profile as well as the name of your whitelist in place of test-list. After running this command, to verify that this is working you can run the command: tmsh list security dos profile dos. Hit space until you are at the bottom of the profile.

You should be able to see your whitelist inside your DoS profile.

Please comment below if this helped you or if you have any further questions!

Hope this helped!

Broken iRules Maintenance Page

Many people have been using the feature of a health monitor on LTM called “Monitor Disable String”. When the health monitor receives this string it disables the pool member. This is handy to give to application owners so they can remotely disable a pool member for maintenance or upgrades. A popular use case was to attach an iRule to a VIP. That iRule presents a maintenance page when all pool members are in a disabled state.

Continue reading “Broken iRules Maintenance Page”

How to upgrade F5 BIG-IP

Initial Steps

  1. 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
  2. Download the iso File of the version you are upgrading from Support.F5.com.
  3. 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

Upgrading

  1. Create archives on both active and standby devices.
  2. Download both archives to your local machine as a precaution.
  3. 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.
  4. 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.
  5. Force standby device offline to ensure no failover occurs.
  6. Install upgrade on standby device.
  7. 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.
  8. Once you are able to access the GUI; give the F5 a few more minutes to finish up the boot processes.
  9. 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.
  10. 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.
  11. 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.
  12. Repeat this same process with secondary device.

Importing Vulnerability Scan Results into ASM

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.

"Security

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

"Security

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.

Credential Stuffing Prevention With F5 ASM Brute Force Protection

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?

Continue reading “Credential Stuffing Prevention With F5 ASM Brute Force Protection”

F5 BIG-IP ASM Policy Creation

You heard us talk about WAFs and ASM. So now it’s time to discuss how to create a basic F5 BIG-IP ASM Policy which is a security policy using F5’s Application Security Manager (ASM). With ASM you get the flexibility to both create a negative or positive security model. Negative security model means: I will block bad stuff. Positive security model means: I will only allow known good application traffic, everything else will be blocked.

Continue reading “F5 BIG-IP ASM Policy Creation”