Cannot create iApps that run over http and https on same VIP


I have an app that runs over http and partly over https. Up until now I would create 2 VS on the same IP.
One for http on 80 and one for https on 443 which works cause the port is different.

It's unclear to me how this translates into the iApp concept. Logically there is only one app spread over 2 VS. The first problem is naming :

* I can only create one iApp over either http or https, after that I have to pick another iApp name or else it complains that objects with this prefix already exists.

*When I pick a different name, however, it still complains that :

"01070333:3: Virtual Server /Common/vs1 illegally shares both address and vlan with Virtual Server /Common/vs2"

This means I cannot use the iApp template at all. Both http and https have to listen on the same IP and allow the same VLAN. This works when you do it manually.

This opens up an interesting question. What exactly distinguishes an "iApp" ?  Is it per IP or per virtual server ?
It looks like there is no concept of having the same app use 2 different VS. How can I tell the f5 how to distinguish my apps ?
F.e. I have one setup where there is only one single VIP and all apps are separated only by URI. I have iRules that take care of that like :

if { [HTTP::host] equals "/app1" } {
  pool app1
elseif { [HTTP::host] equals "/app2" } {
  pool app2

and so forth.

I assume there is no way to tell the LTM to make these into separate iApps right ?
I was ok with switching back to having dedicated IPs per app but now I cannot even seem to do that.

Am I out of luck ?

22 Answer(s):

Depending on what version of BIG-IP you are running, I might have a solution for you.

First the explanation:
The reason why you are running into trouble is that when you deploy a service with the HTTP template and choose to make it secure on port 443, the template actually creates two virtual servers, one on port 443 and one on port 80. The one on port 80 just redirects traffic to port 443. This is done as a service to users who often forget the s on https, and this gets them where they wanted to go anyway. However, in situations like yours where you need a separate virtual server on the same IP address and on port 80, it causes a conflict.This is what you are running into.

The solution:
If you are running BIG-IP version 11.2, then I can very easily solve this problem for you. We added an option in version 11.2 to solve this very problem. When you deploy the secure port 443 template, there will be a question right under the port number in the Virtual Server Questions section that asks, "Do you want to redirect traffic that comes in as HTTP to HTTPS? ". Change this answer from Yes to No and this will cause the template to not create the redirect virtual and this will solve your conflict.

Unfortunately, this feature did not exist on earlier version. If you need this to work on an earlier version, then the template back-end code needs to be altered to not create that redirect virtual.


When working with common IP addresses, it is sometimes necessary to delete and rebuild the second iApp rather than just changing parameters. You may have run into this problem even though you entered the correct parameters.

Also, it was not entirely clear from the original post whether you want the BIG-IP to process SSL for you, or let SSL flow through to the servers, but there are several iApp-supported scenarios:

(1) 2 iApps, both with SSL processing turned off. On one, set both virtual server and server pool members to port 80. On the other set both virtual server and pool members to port 443.

(2) 2 iApps, one on port 80 as above, the other with SSL processing turned on. On the second, the virtual server is set to port 443, but the pool members are on port 80. Make sure redirect is off.

(3) 1 iApp, with SSL processing and redirect turned on. BIG-IP responds to both ports 80 and 443. The pool members are on port 80.

I hope this makes things clear.

You cannot create option (2) with the iApps templates because both create a virtual server (..._xmlb_server_enum) on port 137, so the second create failes with error 01070333:3 Our workaround was to set a fake virtual ipadres for xml broker when creating the second application service. This virtual server and its pool will not be used because the first application service already offers this service.

This post described http iApp scenarios. Your reference to xml brokers suggests that you have a Citrix application. If so, start a new post and describe your application and what you are trying to do with it. Also, you might download the current citrix_vdi template from It has many more capabilities than the 2 citrix templates that ship on-box.

Thanks. First off I'm still running BIG-IP 11.1.0 Build 2185.0 Hotfix HF4 because I was told a while back that was the most stable version.
Is it safe to upgrade to 11.2 ? If so I'd definitely do that and look at the new fix that Mitra mentioned.
Can you please confirm the latest stable release ?

The current GA release is 11.2.0. You may wish to review the release notes ( for any potential problems you may encounter due to your particular configuration.

Alternatively, you may download the early-release HTTP template that I posted on Dev Central yesterday ( This template will give you the ability to control IP redirect as well as disable caching, which was your request from another thread

Wow - what a giant leap !!

Thank you for this great new template ! We're getting closer to something usable now. I tried it and it works pretty well so far.
I like the other additions you made like X-Forwarded-For. Very useful for me and I didn't even think to mention that.

Here some more additions that I think would be easy for you to create:

* Choice of VLAN rather than "All VLANs and Tunnels"
* Option to explicitly name the persistence cookie that gets inserted like : {iApp_name}_persistence_cookie
* Option to encrypt that same cookie (random passphrase I assume would be fine) in the http profile.

At this point using an iApp is back on the table and I am close to being able to provide a new iApp WITHOUT having to uncheck strict updates and make changes afterwards - that is the goal here. I'd like to only use the "reconfigure" option in the future.
I do need the stuff added that I mentioned though.
I'd also like some default iRules but that I can do myself since those rules are specific to my setup.

Great work - looking forward to the next version.


I am glad to hear that the new template is helpful. Your constructive feedback has been very much appreciated, and we will seriously consider your 3 remaining suggestions.


Thank you ! As soon as you have something usable I'm happy to try it.


It's been a while and I am now evaluating 11.4. I noticed the iapp templates have improved quite a bit once again - thank you ! (Eventhough my cookie suggestions didn't make it in there - that's ok :))

At this point I have written a python script to create a standard http/https VIP via icontrol. What a giant leap. It takes 2 seconds to spin up a an entire vip now.

However, what I'm still totally missing is the ability to set the description for both the http and the https vip that are created. There is nothing in the gui (not even the ability to set the description for the iapp itself). I want to set those along with the vips since I use the descriptions to refer to the vips later. F.e. I have another script that enables a maint page based on description of the https vip so people who have no clue about the internal naming scheme of vs can enable such a page. I set the description after the fqdn of the VIP so all someone would have to know is that they want to enable maintenance on site "" and the script would find the vip by that description.

I can easily set the descriptions afterwards BUT now I have to uncheck "strict updates" and if I was to "reconfigure" later my descriptions would be lost again. One day I'd really love to have an iapp templ that contains all the info I need therein without having to modify it one bit after. I poked through the template but am a bit scared to muck around trying to add description fields. I don't even see the http redirect vip being described much there.

Is there a way you could get me one of those beta http templates again based on the latest 11.4 with this added ? Again I'd like the ability to add both the http and the https vip's descriptions into the iapp templ wizard.

So close...



You can change descriptions with tmsh, and if the tmsh statements are inside the iapp, then strictness will not be violated.

To change the iapp description: modify sys app ser description "your text here"

To change the vip description: modify ltm virtual description "your text here"

Of course, you would substitute "your text here" with the variable name that you added for the user to enter their description. To avoid getting into the template logic, simply place the tmsh statements at the end of the app's implementation section.



I see what you're saying and that didn't even occur to me but is that not a bit of a hack ? Either way it's something to think about for next gen templates but it should fix my problem for the time being.

Thanks very much for your reply

Well, I prefer to think of it as a "customization" rather than a "hack," but that is a matter for debate, I suppose. In any event, very few customers pay attention to the "Description" fields, so I doubt we will include a field to manipulate them in an official iApp release. Your python scripts sound very clever. Let me know how things go.

cheers, Fred

Got it. Not sure if they are clever but I KNOW I cannot expect anyone to remember that "" translates to "/{partition_name}/" so I figured why not utilize the description for a mapping of the 2 ? You are right otherwise - I had never used it before either. Will try this out when I have a minute.

Thanks again - DC rulez !!

Wait ! I just realized I cannot hard-code the description into the template. I need to pass it to the script. Let me clarify. I can easily change the description after the iapp has been created. In fact I have a script for that too :) The issue is just that now this description is not part of the iapp so if I ever "reconfigure" it the description disappears again. Are you saying there is a way to add a description into a template afterwards and still make it part of the template ? What exactly do you mean by "and if the tmsh statements are inside the iapp" ?

I'm afraid you mean placing tmsh commands into the template but like I said I have to catch arguments from the outside and that means adding something to the presentation layer right ? This may not be as simple after all.

Fred One more thought. I assume the description would be part of "scalar_vars", "list_vars" or "table_vars". I have these defined in the script so if I knew the exact name of the description I might be able to add it from the script ? By name I mean those arbitrary fields with the double underscores in them like:

{'name': 'pool__addr', 'value': ipaddr}, {'name': 'pool__http', 'value': '/#create_new#'}, {'name': 'pool__lb_method', 'value': 'least-connections-member'}

See f.e. how I pass the ip address as a var here. I would imagine something like :

{'name': 'vs_redirect__description', 'value': ''}

{'name': 'vs__description', 'value': ''}

but I think that requires mod'ing the template right ?

Unfortunately, the description is not one of the variable or table values within the iapp, or more properly, the "application service object." The description is a direct property of the ASO. However, there is nothing to prevent you from creating a new variable in the ASO, and using it however you please, e.g. {'name':'stuckys_descrip','value':''}.

Fred Just to make sure we're on the same page. I use iControl to stand up the appservice so the only way to tell the api what I want is via the 3 var types mentioned. I don't have a way to modify the template itself on the fly each time I run the script so I'm not sure how you you think this can be done. And as far as your example goes {'name':'stuckys_descrip','value':''}.

If I add that to the template that still leaves me with 2 problems

  1. How would I feed the description to the template via the api since you mentioned there is no such object.method call available.
  2. Your example doesn't specify which virtual server the description would be for. Remember the standard http template creates 2 vs. (http_redir and https).

I think I'm missing something here. Can you clarify please ?


OK, let's back up. You want to set the value of the "description" property of a virtual server associated with an iapp. You can do this with iControl (LocalLB.VirtualServer.set_description) or with TMSH (modify ltm virtual descripton). The problem is that the iapp "owns" these objects, and will not allow a cli script to modify them. The solution is to put the script code inside the iapp implementation, so it runs whenever the iapp runs. Then the iapp controls the objects it is responsible for, and everyone is happy. If you wish to insert a value into the description that the iapp does not have access to, then you will need to set up some method of passing that information in, e.g. have the iapp read the value from a file on disk.


Just to clarify. The problem is not modifying the iapp after creation. My script unchecks the "strict updates" button, then sets the description, then re-checks it. I even trap ctrl-c to make sure it gets checked again. The problem is that now the description is not owned by the iapp and would be owerwritten again if I ran a reconfigure. Your fs idea might work. The ipp creation script could dump the files in a location known to the template and then the creation method would be able to read it out. I still think any setting in a given object should be configurable via the API but I'll try the fs idea.


Stucky- I wonder why the description is being overwritten. I tried the following:

(1) run the http iapp, named "h1". This creates "h1_vs". (2) disable strictness (3) add a description (tmos)# modify ltm virtual description "My description text" (4) enable strictness (5) re-run the iapp (6) check the description. (tmos)# list ltm virtual description ltm virtual { description "My description text" }

In my example, the iapp does not overwrite the description.
How does your script differ? Fred

Well that is interesting. I never actually tried it. I simply assumed that everything that was not initially defined in the template will get overwritten as that is the normal behaviour. I just tested it myself and you are right - it doesn't touch the description even after a reconfigure. So I guess the description is not really considered part of the template to begin with ? Seems a bit inconsistent though, doesn't it ? Well that solves the issue albeit in an unexpected way.



iApp strictness of ownership is not so granular as to track an object property like the description field. The entire object, a virtual server in this case, is owned by the iApp. That is why you must disable strictness in order to modify its properties. Since strictness is generally enforced, the iApp framework does not need to re-create the objects when you reconfigure the template. It only modifies those properties that you have changed. In this case, there are no commands in the template that specify a change to the description property, so it is left alone. It may help you to know that iApps do not keep a separate copy of any object information. Instead, objects that the iApp creates are marked with an "app-service" tag. You can view this tag from tmsh. Objects that are created through tmsh or tmui without using an iApp are marked "app-service none".


Got it. Thank you very much for your time and effort !

Glad to be of assitance!

Your answer: