F5 101 – Application Delivery Controller (ADC) Part 3

20. Profiles Part 3

We use profile to learn and to affect the behavior of certain types of network traffic. Profile is also a configuration object that contains settings with values for not only learning but also controlling the behavior of network and application. There are many any jobs of profile. We have the application services, these are Http, FTP, DNS and many more. Profile can also run in layer for protocols such as TCP and UDP. Profiles can also run on triple A server such as LDAP and Active Directory. We’ve already talked about, or at least mentioned persistence. Persistence is a type of profile and later we’re going to talk about both source address and cookie persistence. There are many types of profile like used for optimization like Wan LAN or mobile optimization. Profile can also be used for SSL, web acceleration and many others. Profiles are always associated to a virtual server. We have what we call profile dependencies. This allows advanced profiles running in application to be matched with layer seven application services such as cookie persistence. Cookie persistence will not run without Http profile. An Http profile will not run without TCP profile.

So this is what we call the profile dependencies. SSL Profiles big IP accepts and terminates client requests that are sent using fully encapsulated protocol and provides a number of configurable settings for managing client SSL connections. The Big IP also use specialized hardware built for SSL acceleration to remove processing bottlenecks and encrypt data without having to change application code. It also eliminates the need to purchase SSL capable software and hardware for every single server running in our data and data center environment. The advantage of SSL termination, also known as client SSL profile, also SSL of loader is for Big.

IP performs SSL key exchange and bulk encryption versus servers. Doing all of these processing, we want to centralize not only management, but also certificate configuration and management. It offloads SSL traffic and hardware acceleration from servers. As I mentioned, we want to take the load and processing overhead from servers because BigIP can do this. Even better, we can also allow iris processing, cookie persistence, security policies, web accelerations and many more. Because if we don’t use SSL profiles, what will happen is these features will not be enabled or at least have limited features. Here in our Fib IP GUI, I’ll show you the many different types of profiles under local traffic. I will hover my mouse to profile options and as you can see, we have 1234, well eight options.

But if I hover my mouse on the first option services, you will see many different sites. We have http compression web acceleration FTP DNS. We also have authentication profiles such as Radios, LDAP. We also have application based configuration and languages such as XML, Http, Two and many more. We also have content profile here we also have persistence. As we mentioned, persistence is a type of profile. Now, there are not many options in persistence, but upon configuration you will see the many options of persistence. We also have protocol. This is where you create or configure TCP and UDP layer for protocol profiles SSL we have two options client and server. SSL we have authentication specific profiles. We have messaging, routing and other profiles and most of these are used for logging. I will now go to our Vs and will show you how we associate a profile.

Now, under here in our Http Vs under configuration, either you select Basic or Advanced. Most of the configuration options here are profile based. The first selection here protocol TCP this is our layer for protocol profile. TCP and UDP are the most common options under protocol profile, client, server. This is where you select the optimized profile LAN, mobile one and so forth. We also have Http per profile. By default, there is none associated. We also have FTP.

We also have SSL profile for a client and the server. As you go down here, we still have other profiles, content profiles and acceleration profiles. Now, if I select advanced configuration, we have many more options for profiles RTSP socks, SMTPS, SMTP, web socket, DNS diameter. There are too many to mention, but profile is a really nice feature because we allow to control the behavior of network and applications. Now, for the profile dependencies, the best example here are for the web acceleration profile. Under web acceleration profile we have Http compression and web acceleration. As you can see, it cannot be selected, it cannot be enabled.

It’s all grayed out. Why is that? Because this is dependent to Http profile. Because it’s an Http application. So I’m going to select the system defined Http profile and as we scroll down, you will see now Http, Http compression and web acceleration profile are now enabled and I can select what are the different options here http compressions one, optimization compressions. Again if I deselect http profile I will select none. Scroll down again http profile, web acceleration profile or even Http. Two profile are disabled and cannot be used without again, Http profile. If I go to protocols here and I select UDP, you will see we have less options. FTP profile Http profile is not even appearing in this configuration options.

21. Configuring Profiles Part 1

I am back in my FYB IP GUI and we’re going to test profiles under local traffic. We’re going to create first a virtual server and we’re going to test this application. I’m going to hit create. And we’re going to name our or new Vs FTP underscore Vs. And I’m going to assign an IP address of 1010 1103, listening to port 21, which is FTP application. Now, I will leave everything default and associate the FTP pool that we created from our previous lab demonstration. I’m going to click finish. And if we verify this in our network map, you will see that we have new application Ftpbs with a pool. And we only have one pool member. Now let’s test this application. I’m here in my Windows client PC and FTP.

We’re not going to use a web browser. I’m going to minimize this. Instead, I’m going to open an application file Zela. Okay. And I’m going to add a host IP address. This will be 1010 one one three. We’re also going to specify a username student with a password of student. And the port will be port 21. I will hit Quick Connect. Okay? I will just click OK from this pop up window. And as you can see, our login is successful. See that? We were able to log in, but we are not able to retrieve the directory listing. So in short, the control channels are successful, but not the data channel.

So this is what we discuss in the whiteboard. The first part of FTP can be successful, but the other establishment is not complete because, again, the data channel is failing. All right, and the reason behind this, because the big IP device by default is only allowing the initial channel, which is control channel. The data channel is blocked by default because our BS doesn’t recognize an FTP application behavior. Now, to resolve this issue, all I need to do is edit our FTP virtual server. And under FTP, under your configuration, we’ll select an FTP profile. We just selected the system defined FTP profile.

And this is enough for the virtual server to know the behavior of this application. I’m going to click update. Now let’s go back to our Windows client. And what I’m going to do is I will totally close this application and I’m going to open a new one. Going to open again FileZilla, and I’m going to specify again the virtual server IP address, which is ten 10113 with a username of student and password of the same student. The port will be port 21. And I will hit Quick Connect. Click okay. And there you go. We are logged in. Not only that, we see the same files that we verify when we use our fi big IP to log into this FTP server. We have README text and test text.

Now what I’m going to do is I am going to download test text to my desktop. Now, to verify there is no other files here. Only recycled bin, the Google Chrome web browser, and the Putty application. Now I’m going to download it here. I’ll just drag and drop it, and it is successful. There you go. Here’s our file. So we were not able to connect to our FTP application using pool members. Pool, FTP pool. And under FTP pool, we associate a hotel monitor done from our previous lab demonstrations. We also created a virtual server where we associated the pool on the FTP profile. Now we just successfully log into the FTP servers, seeing the two files. Also download one file test text.

22. Configuring Profiles Part 2

Now let’s create our Https configuration objects and enable SSL profiles. I’m here in our virtual server list and I’m going to click Create. I’m going to name our virtual server Https underscore Vs with an IP address of I’m going to use is the same IP address of our but different port. I’m going to use port 443 and I will scroll down. And if we verify our pools, there is no Https pool. So I’m going to hit this plus sign and this will redirect us to the new pool creation page. So we’re creating the pool on the fly. While we’re creating the virtual server, I’m going to add Https underscore pool as the name. I’m not going to associate any help monitors. That is fine. But I am going to add three pool members. 170, 216, 21 I will change the last octave 22 and 23. I’m going to click finish. This creates our pool and will automatically associate under the default pool configuration for this Vs. Before we hit finish, let’s verify everything. First. The name is https underscore Vs.

The destination address is 1010 10. This is correct. The server port is four, four, three and we’ll leave everything by default. Let’s hit Finish. There you go. Now, before we test our Https, let’s test first our Http Vs. I’m going to type in 1010 100. And look, we have our Http application and it’s doing load balancing server one. If I hit again, server three, then server two. Everything was working correctly. Now, if I type Https, then I type in the IP address of our Https. It’s successful as you can see. If I hit refresh, it’s also load balancing it’s now server three. But if I hit refresh, it’s now server two and now server one. If you compare our Http and Https application almost the same, the difference is the color Https. You see that there is a red image here and this signifies that our pool members is responding with Https open application.

So this is the port that they’re listening and for the Http, they’re listening to port 80, which is Http. This is just to signify for us to know which server is responding. Now, as we mentioned in our whiteboard, if we’re using Https and if our server is responding also Https, let me say it again. If our request is Https and our server our pool members responding Https, our traffic still end to end encrypted traffic. We’re still doing the secured communication from client to the pool members. Now, what we want is to terminate the Https session to the big IP. So big IP can perform many different features such as idle compression, cookie persistence, security inspection, the list goes on. Now, to do this, we need to edit our virtual server which is Https virtual server.

Now, the goal here is after the VIP terminates the SSL session it will forward the traffic to Https or Http pool numbers. You are correct Http pool numbers. So this is what we’re going to do. First we go down here and as you can see, we have SSL profile client. It’s still empty. If I associate client SSL to the selected space here, this enables client SSL profile. I’m going to hit Update to save our configuration and let’s test it right. So here am I. I am already pointing my URL to Https ten, not 100. All I need to do is hit Refresh button. Okay, still waiting, still waiting. Oh, what’s this? We are getting a bad request, an error. And the reason is we are speaking plain Http to an SSL enabled server port. Okay, so here is what we’re talking about. SSL termination or SSL client profile terminates SSL session onto the big IP.

As the big IP terminates it, it enables many different features and forward the connection to Http pool members only. So we still need to do something in our virtual server, not just adding client SSL profiles on the resources. We need to change the default pool to Http pool. I’m going to click update. Now we are using Http pool and if I go back to my Windows client and hit refresh there you go. We have now a successful application. But let’s compare. This is our Http vs. You see color blue. Now this is our Https virtual server. Why are we seeing color blue on the web page? Well, the reason because is the server that is responding is listening to port 80.

But if you check the URL, we are using Https. So from the client side it is Https, but from the server side it is Http only. Now, we’ve already talked about how to enable the encryption from VGIP down to the servers. And this is very simple. If you go back to the virtual server properties page, there is an SSL profile server and for testing you can just enable this. Just move that server SSL client profile, click Update. This will terminate SSL from the client side and reengaged recreate SSL down to the pool members.

Now, in this case, we will also need to change our default pool to Https pool because when the big IP encrypts the traffic, it is expecting to forward or create connection to Https enabled servers. Now let’s go back to our Windows client. If I hit refresh, this should be successful. The difference is the web page will have a red color. I hit refresh and as you can see, the web server now has red color. Now for this blue, this is just cash. Don’t worry about it. But yes, we are using slide profile as well as SSL server profile.

23. Persistence Part 1

Persistence is a type of profile that maintains session from one or group of clients to a selected pool member. So in this case, the client one sends traffic to our virtual server with an IP address of 1010 1100 listening to port 80. The big IP will do load balancing and select a pool member at the same time it kicks persistence. Now, in this case, the big IP selects the first pool member. As the client continues sending traffic. The big IP will also continue forwarding traffic to the same pool member, in this case pool member one. Now, if we have a different client, different IP address, sends traffic to the same virtual server, the big IP will select a pool number through its low balancing method. Again, the persistence will kick in. Since it’s using source address persistence, it will be based on the source IP address and if the client continues forwarding the traffic, the big IP will maintain the connection in this case to the third pool member. Now, we have many types of persistence. We have source address affinity which is based on source IP address. This is the persistence that we use as an example on our previous slide.

We also have cookie persistence. This is based on the content of web browser cookies and this is exclusively for web based applications. We also have destination address affinity which is based on destination IP address SSL persistence based on SSL ID sessions. And we also have universal persistence. This is customizable and an eye rule is required because we want to create our personalized custom mobile persistence criteria. We also have hash persistence rate persistence hash based on an existing I roll like universal persistence.

Here’s an example of source address persistent persistence in more detail. The client sends to the Vs. The Vigip do its load balancing by selecting a poll member. At the same time persistence kicks in. Now, the client sends traffic continuously so the Vigip will maintain the connection to the first poll member. Second client also sends traffic to the Vs. The big IP forwards the traffic to the selected pool member. This time it’s pool member three. As the client continues sending the traffic, the big IP forwards the connection to pool member three. Now, why are we doing this? Because it seems to me that we are skipping load balancing. Yes, we are. Using persistence will only do load balancing on the first connection. The succeeding connection will bypass load balancing and maintain the connection to that selected pool member.

Well, because some of the applications require this kind of connection where they want to maintain the connection from a particular source or group of clients. Now, to verify the persistence information we have our persistence records. Since in our example we have two source IP addresses 1010 130 and 1010 140, they have a dedicated record. Both are using source address persistence, both are using virtual servers and both are using pool Http pool but look at the pool members they’re different. It can also be the same. Okay, also take note the default timeout or age expiration of a source address persistence is 180 seconds. Again, this is the default where we persist per unique source IP address.

Now in this example we’re going to use the same setup to client a big IP and three full members. The client sends traffic again to the Vs the big IP do the load balancing forwards the traffic to the first full member. As the client continues sending traffic it maintains to the first pool member. Second client sends traffic to the same BS. The big IP now forwards the traffic to the same pool member of the first client it’s pool member one. How does this happen? And if both client continues forwarding traffic the IP still maintains the connection to the first pool member.

If we look at our persistence records, what do we see? Look at the persistence value we have here 1010 10 non specific source IP address but we are choosing the same pool member. If the source starts with 1010 one this is what we call the prefixed length option and we’re using 24 and this is the reason why if the source has the same 1st, second and third octet value they will all maintain the traffic connection to the same pool member. This is also equivalent if the first 24 bits coming from the left they will will be using the same persistence record. In this case, big IP will forward traffic to pull number one.

24. Persistence Part 2

Cookie persistence. How it works is when client access the virtual server or the application and special cookie is inserted as the big IP sends reply back to the client. This special cookie contains selected pool member and Http profile is required. Default cookie name is is big IP server plus the pool name. I also want to add that there is no persistence record if you use cookie persistence.

Why? Because the cookie information is already stored in your client web browser. And you can also set the expiration or the timeout when you create a cookie persistence profile. Now, there are three types of cookie persistence. We have the Http cookie insert. This is when big IP alone manage persistence cookie. We also have Http cookie rewrite. This is when big IP rewrites the cookie because the application sends it back to the big IP as a blank cookie. Lastly, we have the Http cookie passive. This is when the big IP doesn’t do anything and application alone manages the persistence cookie. Let’s talk about Http cookie insert. Let’s say the client sends traffic to the virtual server the first time. It will do the usual process the TCP three way handshake.

As this completes, it will create a session and it will start sending data. As the big IP received the data, it will then proceed with the load balancing selection. Now, let’s say it has selected server number one or pool number one. It will now forward the connection do the TCP three way handshake. Again, when the response of the server received by the big IP, this is when the cookie insert is being processed. Now, this cookie or special cookie, we add the information persistence or the persistence information. This includes the pull member information. In this case it’s 170 216 21. The big IP will respond back to the client with that special cookie added.

Now, the cookie will be installed on the client web browser and the next time the client sends traffic again to the virtual server, the big IP will receive it. It will say hey, I know this cookie, I can read it. And the information we see is a persistence information. Now, I’m going to bypass the load balancing and we’ll forward you to that full member. In this case it’s 170 216 21. Now, the second question is when the server responds back to the big IP, what will happen to the cookie? Will it get updated or the big IP will do nothing? Well, the answer to that question is based on the always send cookie configuration. By default this is disabled, meaning the big IP will not do anything and it will just forward the response back to the client. The question is when the client sends another traffic or another connection to the virtual server, will it persist? Again, the answer to that question is yes, because the cookie is still stored on that client web browser.

Now, what happens is when we enabled always send cookie when we enable this option. Every time the server sends back to the big IP, the cookie will always be updated by the big IP sends traffic or sends a reply back to the client with a cookie or with the updated cookie with a new timeout value for the Http cookie rewrite is almost the same. When client sends traffic to the virtual server, it will do again a TCP three-way handshake. And once the TCP three way handshake is completed, it will start sending data and the big IP will then select the pool member from the load balancing method. This is the server selection and let’s say we selected pool member one. Pool member one is selected, it will again do the TCP three way hanging over the data and the server will respond back to the big IP. Okay, the big IP will now add a cookie and then respond back to the client with that cook information. That cook information will be stored on the client’s web browser.

So he already knows that he has a cookie and the next time it sends traffic back to the virtual server, the VGIP will say hey, I know this cookie, your value has a persistence and I should bypass the load balancing and forward your connection to pool member one. Okay, so it’s almost the same what we discussed in the Http insert cookie. The only difference is when the server respond back to the big IP, the cookie will be empty and the big IP will force to rewrite the cookie and sends it back to the client. Lastly, Http cookie passive the first time the client access the virtual server it will do TCP three way handshake. TCP three way handshake and it will start sending data. Once the big IP receive, it will then proceed with the low balancing selection. Let’s say the big IP selected the first full member so it starts sending the traffic and the connection. Now if the big IP receive the response from the server or the application, it has already a cookie.

So in this case it’s not the big IP who’s adding updating or inserting a cookie, but the actual application slash the server. Then the big IP will just forward it back to the client as it replies. Now when the client sends again traffic to the virtual server, the big IP would know what is the selected pool member and it will just simply forward it to that pool member and bypass load balancing. Now, as the server received data and it will responds back to the VGIP, the big IP will not do anything, it will just forward the data, responds and the cookie back to the client. And of course the cookie is stored on the client web browser. In this case, big IP is just acting as a cookie passthrough and it doesn’t do anything. Any management about the cookie.