hi all, so we have an application that requires connecting to a specific URL, but this application only supports "http". we happen to have an "https" URL that this application needs to connect to, so I though of creating a VIP that listens on port 80, and then plugged the URL as a pool member on port 443. this seems to get the initial connection to work, but then the URL sends a redirection to the client, and Yes it is "https" so when the client attempts to connect to the VIP on 443, of course it fails. so I was wondering if there's a way to resolve this problem using an iRule. anyone can help with this :) Thanks

For your 443 virtual server, you can apply a client SSL profile and terminate the SSL at the BIG-IP. Not applying a server SSL profile will allow the BIG-IP to talk native HTTP to the server, so this should satisfy your requirement if I understand it correctly. Use the same pool for both of your virtual servers (80 and 443). Though why would the server be sending a redirect to HTTPS if it doesn't support SSL enabled connections?

I figured a picture is worth $5 so here it is. so the failure happens when the client receives an https URL and then it attempts step 4 and then it dies right there.

Okay, so the web server needs to talk SSL. So you need this: Virtual server on port 80, apply the irule _sys_https_redirect (this is a stock iRule included in all recent LTM code versions). This will redirect all HTTP to HTTPS. Virtual server on port 443. Apply an appropriate client SSL profile to handle the client side SSL. Pool with the server as a 443 member. Apply this to your 443 virtual server. That should be all you need.

I think you already have this, but ensure you also have a server SSL profile applied to your 443 virtual server.

there's only one VIP, which is the one that listens on 80 . I guess the main problem here is that the redirect comes back from the web server as https, so we'll need to somehow change this URL to http before sending it to the client.

http to https VIP | DevCentral

44 Replies

mj_almassud_136
Nimbostratus
May 12, 2014
Cory,

Thanks for your help buddy.

I will test this later after business hours and report back.

MJ
- Cory_50405
  Noctilucent
  May 12, 2014
  Remember, you'll first have to apply an empty stream profile to your virtual server, and then apply the iRule.
mj_almassud_136
Nimbostratus
May 12, 2014
Cory,

I was able to test this and it's still not redirecting. I took a pcap and found something that seems interesting:

GET /Doc1/Login.aspx HTTP/1.1

Accept: image/jpeg, image/gif, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, /

Accept-Language: en-US

User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E)

Accept-Encoding: gzip, deflate

Host: HostName.DomainName.com

Connection: Keep-Alive

HTTP/1.1 200 OK

Server: Microsoft-IIS/7.5

X-Powered-By: ASP.NET

X-UA-Compatible: IE=9

Date: Fri, 09 May 2014 17:15:47 GMT

Content-Length: 263

the redirect seems to be part of the payload through a java script, so I think this is the reason the iRule didn't work with this VIP.
mj_almassud_136
Nimbostratus
May 13, 2014
Good morning Cory,

any more thoughts about a solution for this issue? I am kind of stock and not sure what else to do at this point.
Cory_50405
Noctilucent
May 13, 2014
Was the capture you took on the server side? How are you determining that the issue could be Javascript related?

What are you seeing on the client side?
mj_almassud_136
Nimbostratus
May 13, 2014
the capture was done on BigIP over ssh: tcpdump -ni 0.0:nnn -s0 host x.x.x.x -w /var/tmp/external.cap & tcpdump -ni 0.0:nnn -s0 '(host x.x.x.x)' -w /var/tmp/internal.cap &

I was testing the access from a windows server in the internal network.
Cory_50405
Noctilucent
May 13, 2014
Can you run a Wireshark capture from your Windows server and see what the client is receiving from the BIG-IP?
mj_almassud_136
Nimbostratus
May 13, 2014
yes sir will do and report back soon.
mj_almassud_136
Nimbostratus
May 13, 2014
so the packet capture on the server where the connection is being establish showed that the client is getting the response back directly from the web server rather than from the VIP, which would be a problem.
Cory_50405
Noctilucent
May 13, 2014
Aha. Enabling SNAT on your virtual server should resolve this issue. Try using SNAT auto map and see if it works.
mj_almassud_136
Nimbostratus
May 13, 2014
I checked that and it is enabled: