Forum Discussion
Simple HTTP session termination then back end session to web server
Hello Gurus! I'm VERY new to LTM but I suspect this one will be simple.
I've got an internal web app that simply uses http on port 80 from a company we acquired, which is currently on their local AD domain. We'll call it http://currenturl.olddomain.local/webapp.
In order to get our users that come in over our global WAN into a higher queue in QOS I need them to make connections on a custom port (8052), but we don't want to change the web server. So, I want provide the users across the pond a totally different URL that terminates at the F5 on http port 8052 (http://newurl.ourdomain.com:8052/) and then have the F5 proxy the session to the web server by opening a new connection on the back end to the web server on the actual URL (http://currenturl.olddomain.local/webapp).
Any help or article references would be much appreciated!
- Kevin_StewartEmployee
The port translation is done automatically in a standard virtual server configuration (with port translation enabled), so the destination port will change to port defined in the server pool. As for the the host and URL, something like this perhaps:
when HTTP_REQUEST { if { [TCP::local_port] equals "8052" } { HTTP::header replace Host "currenturl.olddomain.local" HTTP::uri "/webapp" } }
This will change the incoming Host header and send all requests to the "/webapp" URI path. This VERY simplistic example assumes that:
-
The "/webapp" URI is the only path (ie. there's nothing after this URI like "/webapp/foo"). A fairly simple fix.
-
The web server isn't responding to client requests with object references that point to the internal URL structure (ex. "http://currenturl.olddomain.local/webapp/image.jpg"). This is somewhat rare, but good to look out for.
-
- Mark_VogelAltostratus
Thanks Kevin. Will this make the F5 actually proxy the connection to the web server or will this tell the client to connect to currenturl.olddomain.local/webapp? I'm a little bit fuzzy on what makes the proxy happen (or not). Pretty sure this happens by creating a Profile?
- Kevin_StewartEmployee
An HTTP redirect causes the client to go directly to the defined host. Anything short of that, that is anything that allows the traffic to pass through the F5, is being proxied.
- Mark_VogelAltostratus
In response to the potential URI concerns, the plot may have thickened. I just found that there are multiple URLs:
http://currenturl.olddomain.local/webapp http://currenturl.olddomain.local/abc http://currenturl.olddomain.local/scan http://currenturl.olddomain.local/scan/something.htm
Not sure how this changes things in the iRule...
- Kevin_StewartEmployee
It certainly depends on what you need to do. Is there any pattern to what the client requests and what you translate that to on the server side? Is there a default path if the client doesn't specify a URI?
- Mark_VogelAltostratus
So I wrote the iRule exactly as shown above and when I browse to http://newurl.ourdomain.com:8052/ I see a hit (and no failure) on the iRule but no web page. IE "cannot display the web page" and firefox says the connection was reset.
If I browse directly to the actual URL http://currenturl.olddomain.local/webapp, it does end up with http://currenturl.olddomain.local/webapp/account/LogOn?ReturnUrl=%2fwebapp. Not sure if this matters.
On that note, does it matter what what the "Redirect Rewrite" setting is on the http Profile I'm specifying in the VS?
I'm not sure how to debug this on the LTM unfortunately.
Also, at this point I'm thinking since /xxxx is already needed to get to different parts of the web app, that we should keep them around. So instead of just having the users enter http://newurl.ourdomain.com:8052, I should have them enter http://newurl.ourdomain.com:8052/webapp, and http://newurl.ourdomain.com:8052/abc, etc.
- Kevin_StewartEmployee
Unless you just absolutely need to get rid of the "/webapp" portion of the URI, it would be much simpler to keep it. Here's a slight modification to the first iRule:
when HTTP_REQUEST { if { [TCP::local_port] equals "8052" } { if { [HTTP::uri] equals "/" } { HTTP::redirect "http://[HTTP::host]/webapp" } else { HTTP::header replace Host "currenturl.olddomain.local" } } }
This simply changes the Host header and redirects to /webapp if the request URI is blank.
- Kevin_StewartEmployee
Okay, so allow me to clarify. You have an SSL VPN tunnel in place. You have users on one side of the tunnel (assuming they have IP addresses from a lease pool you created). You have a VIP on the F5 that should be accessible through the tunnel. To start, can a client ping a VIP address through the tunnel? If so, then if the client opens a browser and types the IP address of the VIP (ie. http://10.10.10.100), do you see the traffic hit the front of the F5? If so, then if the client uses the name of the host (ie. http://currenturl.olddomain.local), do you see the traffic hit the front of the F5? If so, then do you see the traffic leave the back side of the F5 and go to the web server?
- Mark_VogelAltostratus
Hi Kevin. I was probably writing my last message at the same time you were writing yours. There were NO routes in the LTM. Side effect of me acquiring others' setup. So far most URIs are populating great just using the rule below:
when HTTP_REQUEST { if { [TCP::local_port] equals "8052" } { HTTP::header replace Host "currenturl.olddomain.local" } }
I'm just specifying the URI using the new URL so it goes to the correct place in the app (http://newurl.ourdomain.com:8052/webapp). I'll post back shortly on progress. There is one more piece of trickery I'm going to have to do but I think you may have already tipped me off on how to accomplish it.
To clarify locations:
In my physical location I'm on an end user subnet testing. F5 LTM is also here and VIP is on a server vlan that's trunked to the F5.
Remote location is where the server is, which is across a VPN tunnel from my location.
- Mark_VogelAltostratus
OK, so far so good except for just one of the URIs: the /scan. I'm running ieHTTPHeaders to watch the header traffic in IE (shown below).
When I enter http://newurl.ourdomain.com:8052/webapp, everything looks fine and ieHTTPHeaders shows this:
GET /webapp HTTP/1.1 Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, / Accept-Language: en-US User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; chromeframe/30.0.1599.101; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3) Accept-Encoding: gzip, deflate Host: iww.lims-minerals.bureauveritas.com:8052 Connection: Keep-Alive Cookie: s_vi=[CS]v1|292E1112051D385A-40000103A000D0CD[CE]
HTTP/1.1 302 Found Cache-Control: private Content-Type: text/html; charset=utf-8 Location: /webapp/Account/LogOn?ReturnUrl=%2fwebapp Server: Microsoft-IIS/7.5 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 17 Oct 2013 15:58:14 GMT Content-Length: 162
However, when I try the /scan URI, it looks like I'm getting redirected (by the server I guess?) to the old URL somehow and then IE ends up going straight to the web server using the old URL. ieHTTPHeader info when hitting that link:
GET /scan HTTP/1.1 Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, / Accept-Language: en-US User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; chromeframe/30.0.1599.101; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3) Accept-Encoding: gzip, deflate Host: http://newurl.ourdomain.com:8052 Connection: Keep-Alive Cookie: s_vi=[CS]v1|292E1112051D385A-40000103A000D0CD[CE]
HTTP/1.1 301 Moved Permanently Content-Type: text/html; charset=UTF-8 Location: http://currenturl.olddomain.local/scan/ Server: Microsoft-IIS/7.5 X-Powered-By: ASP.NET Date: Thu, 17 Oct 2013 15:57:09 GMT Content-Length: 150
Anything I can write into the iRule to keep that redirect from coming all the way back to my client browser and make the F5 receive that and handle it itself so the client browser just maintains its http session to the new hostname on port 8052 with /scan?
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com