Forum Discussion
NimbostratusCannot 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 ?
25 Replies
- 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.
Mitra - Stucky,
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.
-Fred
A__Gotink_33511You 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 https://clouddocs.f5.com/api/iapps/CodeShare.html. It has many more capabilities than the 2 citrix templates that ship on-box.
stucky101_88485Thanks. 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 ?
thx- The current GA release is 11.2.0. You may wish to review the release notes (http://support.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-ltm-11-2-0.html) 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 (https://devcentral.f5.com/wiki/iApp.New-HTTP-alpha.ashx). This template will give you the ability to control IP redirect as well as disable caching, which was your request from another thread
Cheers,
Fred - stucky101_88485Fred
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.
Alex - Alex-
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.
Regards,
-Fred - stucky101_88485Fred
Thank you ! As soon as you have something usable I'm happy to try it. - stucky101_88485
Fred
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 "https://mycoolapp.domain.com" 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...
stucky
Stucky-
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 your_app_name.app/your_app_name description "your text here"
To change the vip description: modify ltm virtual your_app_name.app/your_app_name_vs 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.
-Fred
- stucky101_88485
Fred
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
