The remote server's SSL certificate has already expired - Plugin ID 15901
Hi Experts We are running Nessus Scan against our F5 BIG-IP LTM devices and getting following alert:- The remote server's SSL certificate has already expired - Plugin ID 15901 Now problem is that we are using IP address to logon to these devices instead of a common name (CN) which is used by SSL certs. We can`t remove it for sure. Now how to regenerate it without a common name (CN) is a concern for us ? Some of the information from F5:- http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos_management_guide_10_1/tmos_device_certif_config.html1019303 Here is our cert information:- General Properties Name server Certificate Subject(s) My Company Ltd Certificate Properties Expires Jan 16, 2013 Version 3 Serial Number XXXX Subject Common Name: Organization: My Company Ltd Division: Locality: Yes State Or Province: No Country: YO Issuer Self Any advice will be highly appreciated. Thanks
Block HTTP access from specific user agent(2)
Dear community, I want to arrange iRule which I learned in following URL. https://devcentral.f5.com/questions/block-https-access-from-specific-user-agentanswer118447 Can I use iRule like this? My client doesn't want to show even 404. when HTTP_REQUEST { log local0. "User-Agent:[HTTP::header "User-Agent"]" if { ([regexp sqlmap|havij|nmap|nessus|absinthe|nikto|w3af|pangolin|bsqlbf|prog.customcrawler|sql\ power\ injector|mysqloit|netsparker [string tolower [HTTP::header "User-Agent"]]]) && !([IP::addr [IP::client_addr] equals 192.168.115.100]) } { discard log local0. "[HTTP::header "User-Agent"] discarding." } }The remote service supports the use of week/medium strength SSL ciphers - Plugin ID (26928/42873)
Hi There We are running Nessus Scan for BIG-IP LTM devices and getting following Alerts :- The remote service supports the use of medium strength SSL ciphers - Plugin ID (26928) The remote service supports the use of weak SSL ciphers. - Plugin ID (42873) Description: The remote host supports the use of SSL ciphers that offer medium strength encryption, which we currently regard as those with key lengths at least 56 bits and less than 112 bits. Note: This is considerably easier to exploit if the attacker is on the same physical network. Solution: Reconfigure the affected application if possible to avoid use of medium strength ciphers. Basically these alerts only indicating Admin IP and the alert so we assume these alerts are related with the admin interface where low/medium end ciphers needs to be disabled. This was our initial cipher strength HTTPD - SSLCipherSuite: ALL:!ADH:!EXPORT56:!eNULL:!MD5:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP In the configuration, We have disabled low cypher i.e HTTPD -SSLCipherSuite ALL:!ADH:!SSLv2:!EXPORT40:!EXP:!LOW This disabling all the cipher length less than 128 bits length. http://support.f5.com/kb/en-us/solutions/public/7000/800/sol7815.html Even after aplying the fix, we are getting these alerts. Can anyone advice what is the possible solution/fix here ? Can we take them as false positive and close the alerts ? Thanks in advance !!
Configure X-forwarded-for on WebSphere App server
Hi, I need to use X-forwarded-for to print data from the client that hit the load balance in WebSphere app server. My architecture as follows: 5 app server connect to --- F5 ---- directed request to 2 app server Can I use X-forwarded-for to print these data directly from F5 to the app servers SystemOut since I do not use HTTP servers? Regards,
Can't open java applet component when connecting to the application through Load balancer F5
Hi We have one new building and the workstations are connected to our network. There is two systems that has java applet components that when clicked, it does not load the java applet. But when connecting to the application server node directly, these java applet components are opened. Al other buildings in other locations are working fine even through the current F5. Only this site has the issue !!! Our collegues checked for the workstation configurations and also bring one workstation to our IT department building and connected to same applications through the same F5, it Worked without any issues. I have one system for Oracle applications 12.1 that I enabled the java debugging console. The output showed exception network: Connecting http://hrms.domain.org:8080/ with proxy=DIRECT java.lang.InterruptedException at java.lang.Object.wait(Native Method) at sun.plugin2.message.Queue.waitForMessage(Unknown Source) at sun.plugin2.message.Pipe.receive(Unknown Source) at sun.plugin2.main.client.MessagePassingExecutionContext.doCookieOp(Unknown Source) at sun.plugin2.main.client.MessagePassingExecutionContext.getCookie(Unknown Source) at sun.plugin2.main.client.PluginCookieSelector.getCookieFromBrowser(Unknown Source) at com.sun.deploy.net.cookie.DeployCookieSelector.getCookieInfo(Unknown Source) at com.sun.deploy.net.cookie.DeployCookieSelector.get(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.setCookieHeader(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.writeRequests(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at com.sun.deploy.net.DownloadEngine.getJarFileWithoutCache(Unknown Source) at com.sun.deploy.net.DownloadEngine.downloadJarWithoutCache(Unknown Source) at sun.plugin.PluginURLJarFileCallBack$2.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source) at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source) at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source) at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source) at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source) at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source) at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source) at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$1000(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$JarLoader.(Unknown Source) at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source) at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source) at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source) at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source) at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source) at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source) at java.lang.Thread.run(Unknown Source) network: Cookie service is not available - use cache to determine "Cookie" network: Connecting http://hrms.domain.org:8080/OA_JAVA/oracle/apps/fnd/jar/fndewt.jar with cookie "HRPROD=rClRylxIBeH_r2yj3qbDh_n8:S; BIGipServerPool-NDC-HRMS-8080=269161644.16415.0000; oracle.uix=0^^GMT+3:00^p" network: Downloading resource: http://hrms.domain.org:8080/OA_JAVA/oracle/apps/fnd/jar/fndewt.jar Content-Length: 2,241,848 Content-Encoding: null We are using BIG-IP 11.0.0 Build 8037.0 Final The issue only happen for that building, all other buildings connecting the same F5 are working fine without any issues. When opening the page directly from the application server, like http://node1.domain.org:8080 , the java applet is downloadable and can be displayed. Kindly advice Thank you C.
Combine Client accepted and http_request.
I have an requirement to forward a source IP to particular pool member. Since I already have http_request configured is it a good idea to add client_accepted into the same irule ? when HTTP_REQUEST { if { [HTTP::host] == "my fqdn" } { HTTP::redirect "https://myfqdn/irj/portal/" pool pool_t_portal } if { [HTTP::uri] equals "/" or [HTTP::uri] equals "/index.html" or [HTTP::uri] equals "/webdynpro/welcome/Welcome.jsp" } { HTTP::redirect "https://[HTTP::host]/irj/portal/" } if { [HTTP::uri] starts_with "/~" and [HTTP::uri] ends_with "index.html"} { HTTP::redirect "https://[HTTP::host]/irj/portal/" } if { [HTTP::uri] starts_with "/uddiclient" or [HTTP::uri] equals "/uddiclient/process"} { HTTP::redirect "https://[HTTP::host]/irj/portal/" } if { [HTTP::uri] equals "/nwa" } { HTTP::redirect "https://[HTTP::host]/irj/portal/" } } when CLIENT_ACCEPTED { if {[IP::addr [IP::client_addr] equals "src.src.src.src"]}{ pool "pool_q_portal" member dst.dst.dst.dst} }
Websphere Portal and webmaster access error
Dear all I had Virtual Server 172.16.80.72 with pool 3 APP Webshpere 172.16.85.71:10039,172.16.85.72:10050, 172.16.85.73:10050. VS's irule redirect from http://172.16.80.72 to http://172.16.80.72/wcs/portal. After configuration, client access it well but webmaster has few complaints. After login to admin website, admin interface broken icons. When click the tab for system administrator, error message display "Google chrome could not connect http://172.16.80.72:10050/wcs/myportal". I want to use VS replace the edge server 172.16.80.32. If click the tab for system administrator on 172.16.80.32, access link is http://172.16.80.32/wcs/myportal. How to resolve problem ? I need config on F5 or request webmaster config for http response from server app to F5 auto change the service port from 10050 to 80. Best Regard
Quick! The Data Center Just Burned Down, What Do You Do?
You get the call at 2am. The data center is on fire, and while the server room itself was protected with your high-tech fire-fighting gear, the rest of the building billowed out smoke and noxious gasses that have contaminated your servers. Unless you have a sealed server room, this is a very real possibility. Another possibility is that the fire department had to spew a ton of liquid on your building to keep the fire from spreading. No sealed room means your servers might have taken a bath. And sealed rooms are a real rarity in datacenter design for a whole host of reasons starting with cost. So you turn to your DR plan, and step one is to make certain the load was shifted to an alternate location. That will buy you time to assess the damage. Little do you know that while a good start, that’s probably not enough of a plan to get you back to normal quickly. It still makes me wonder when you talk to people about disaster recovery how different IT shops have different views of what’s necessary to recover from a disaster. The reason it makes me wonder is because few of them actually have a Disaster Recovery Plan. They have a “Pain Alleviation Plan”. This may be sufficient, depending upon the nature of your organization, but it may not be. You are going to need buildings, servers, infrastructure, and the knowledge to put everything back together – even that system that ran for ten years after the team that implemented it moved on to a new job. Because it wouldn’t still be running on Netware/Windows NT/OS2 if it wasn’t critical and expensive to replace. If you’re like most of us, you moved that system to a VM if at all possible years ago, but you’ll still have to get it plugged into a network it can work on, and your wires? They’re all suspect. The plan to restore your ADS can be painful in-and-of itself, let alone applying the different security settings to things like NAS and SAN devices, since they have different settings for different LUNS or even folders and files. The massive amount of planning required to truly restore normal function of your systems is daunting to most organizations, and there are some question marks that just can’t be answered today for a disaster that might happen in a year or even ten – hopefully never, but we do disaster planning so that we’re prepared if it does, so never isn’t a good outlook while planning for the worst. While still at Network Computing, I looked at some great DR plans ranging from “send us VMs and we’ll ship you servers ready to rock the same day your disaster happens” to “We’ll drive a truck full of servers to your location and you can load them up with whatever you need and use our satellite connection to connect to the world”. Problem is that both of these require money from you every month while providing benefit only if you actually have a disaster. Insurance is a good thing, but increasing IT overhead is risky business. When budget time comes, the temptation to stop paying each month for something not immediately forwarding business needs is palpable. And both of those solutions miss the ever-growing infrastructure part. Could you replace your BIG-IPs (or other ADC gear) tomorrow? You could get new ones from F5 pretty quickly, but do you have their configurations backed up so you can restore? How about the dozens of other network devices, NAS and SAN boxes, network architecture? Yeah, it’s going to be a lot of work. But it is manageable. There is going to be a huge time investment, but it’s disaster recovery, the time investment is in response to an emergency. Even so, adequate planning can cut down the time you have to invest to return to business-as-usual. Sometimes by huge amounts. Not having a plan is akin to setting the price for a product before you know what it costs to produce – you’ll regret it. What do you need? Well if you’re lucky, you have more than one datacenter, and all you need to do is slightly oversize them to make sure you can pick up the slack if one goes down. If you’re not one of the lucky organizations, you’ll need a plan for getting a building with sufficient power, internet capability, and space, replace everything from power connections to racks to SAN and NAS boxes, restorable backups (seriously, test your backups or replication targets. There are horror stories…), and time for your staff to turn all of these raw elements into a functional datacenter. It’s a tall order, you need backups of the configs of all appliances and information from all of your vendors about replacement timelines. But should you ever need this plan, it is far better to have done some research than to wake up in the middle of the night and then, while you are down, spend time figuring it all out. The toughest bit is keeping it up to date, because a project to implement a DR plan is a discrete project, but updating costs for space and lists of vendors and gear on a regular basis is more drudgery and outside of project timelines. But it’s worth the effort as insurance. And if your timeline is critical, look into one of those semi trailers – or the new thing (since 2005 or 2007 at least), containerized data centers - because when you need them, you need them. If you can’t afford to be down for more than a day or two, they’re a good stopgap while you rebuild. SecurityProcedure.com has an aggregated list of free DR plans online. I’ve looked at a couple of the plans they list, they’re not horrible, but make certain you customize them to your organization’s needs. No generic plan is complete for your needs, so make certain you cover all of your bases if you use one of these. The key is to have a plan that dissects all the needs post-disaster. I’ve been through a disaster (The Great NWC Lab Flood), and there are always surprises, but having a plan to minimize them is a first step to maintaining your sanity and restoring your datacenter to full function. In the future – the not-too-distant future – you will likely have the cloud as a backup, assuming that you have a product like our GTM to enable cloud-bursting, and that Global Load Balancer isn’t taken out by the fire. But even if it is, replacing one device to get your entire datacenter emulated in the cloud would not be anywhere near as painful as the rush to reassemble physical equipment. Marketing Image of an IBM/APC Container Lori and I? No, we have backups and insurance and that’s about it. But though our network is complex, we don’t have any businesses hosted on it, so this is perfectly acceptable for our needs. No containerized data centers for us. Let’s hope we, and you, never need any of this.Replacing the WebSphere Apache Plugin with iRules
Problem Definition "We’re having a bit of difficulty configuring the LTM to handle all the redirects that this WebSphere application does. We’ve tried streaming profiles and iRules, but every method seems to break one component while fixing another. The main trick seems to be trying to deal with the default WebSphere ports of 9081 and 9444 for HTTP and HTTPS, respectively. We ideally want to hide these odd-number ports from the end-user. Normally this is a fairly simple procedure, but it’s proved pretty challenging. The issue may lie on the server and/or in the application code, but we’d like to be able to flex the muscle of the F5, if we could, and solve the problem there. One of the main stumbling blocks seems to be pop-up windows for viewing documents (PDF and Word). Word docs instantiate a Java applet, and we’ve had some success rewriting the requests there, but it’s the Adobe file transfer / view that has been the most confounding. The real puzzler is that IBM provides an Apache-based load-balancer with a WebSphere plugin that works really well in hiding the odd port numbers behind standard 80/443. Unfortunately, it’s poorly documented (if at all), so I’m not sure there will be any opportunity to reverse-engineer it and map it to LTM. So, if anyone has any direct experience with WebSphere, or more specifically the IBM SCORE application and can pass on any insights, it would be appreciated." hmmmm, I think we might be able to do something here... The Apache Plugin The "Apache webserver plugin" used by WebSphere is an XML file that defines the server clusters, the services they provide, and the URI's which should be forwarded to each cluster. The items in the plugin file that interest us are the UriGroup, ServerCluster and Route definitions. UriGroup statements group selected URIs together so that Route statements may be used to direct requests to a specific ServerCluster based on the URIs requested. URI Groups Since the functionality we wish to replace is the determination of which service will receive requests for specific URI's, we will start with the definition of the groups of URI's -- the "UriGroup" definitions in the XML file: <UriGroup Name="default_host_WebSphere_Portal_URIs"> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/wps/PA_1_0_6D/*"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/wps/PA_1_0_6E/*"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/wps/PA_1_0_6C/*"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/wps/*"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/wsrp/*"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/wps/content/*"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/wps/pdm/*"/> ... </UriGroup> ... <UriGroup Name="default_host_Server_Cluster_URIs"> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/snoop/*"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hello"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hitcount"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsp"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsv"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsw"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/j_security_check"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/ibm_security_logout"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/servlet/*"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/ivt/*"/> ... </UriGroup> The UriGroup definition contains URI strings with glob-style pattern matching (which will come in handy later). All URIs within each group are intended to use the same ServerCluster. Server Clusters Four application services are defined by the named ServerCluster definitions. Each physical node has two different services, and each service has two ports (one for http and one for https). Looking at the bolded items in the XML file snip below, you can see the service WebSphere_Portal is defined to run on ports 9081 (http) and 9444 (https) on server1.domain.com and server2.domain.com, and the service Server_Cluster is defined on ports 9080 (http) and 9443 (https) on both nodes: <ServerCluster CloneSeparatorChange="false" LoadBalance="Round Robin" Name="WebSphere_Portal"... <Server CloneID="12xx2868r" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="2" ... <Transport Hostname="server1.domain.com" Port="9081" Protocol="http"/> <Transport Hostname="server1.domain.com" Port="9444" Protocol="https"> <Property Name="keyring" Value="D:\IBM\WebSphere\AppServer\etc\plugin-key.kdb"/> <Property Name="stashfile" Value="D:\IBM\WebSphere\AppServer\etc\plugin-key.sth"/> </Transport> </Server> <Server CloneID="12vxx4xx3" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="2" ... <Transport Hostname="server2.domain.com" Port="9081" Protocol="http"/> <Transport Hostname="server2.domain.com" Port="9444" Protocol="https"> <Property Name="keyring" Value="D:\IBM\WebSphere\DM\etc\plugin-key.kdb"/> <Property Name="stashfile" Value="D:\IBM\WebSphere\DM\etc\plugin-key.sth"/> </Transport> </Server> <PrimaryServers> <Server Name="WebSphere_Portal_1"/> <Server Name="WebSphere_Portal_2"/> </PrimaryServers> </ServerCluster> <ServerCluster CloneSeparatorChange="false" LoadBalance="Round Robin" Name="Server_Cluster" ... <Server ConnectTimeout="0" ExtendedHandshake="false" MaxConnections="-1" Name="server01" ... <Transport Hostname="server1.domain.com" Port="9080" Protocol="http"/> <Transport Hostname="server1.domain.com" Port="9443" Protocol="https"> <Property Name="keyring" Value="D:\IBM\WebSphere\DM\etc\plugin-key.kdb"/> <Property Name="stashfile" Value="D:\IBM\WebSphere\DM\etc\plugin-key.sth"/> </Transport> </Server> <Server ConnectTimeout="0" ExtendedHandshake="false" MaxConnections="-1" Name="server2" ... <Transport Hostname="server2.domain.com" Port="9080" Protocol="http"/> <Transport Hostname="server2.domain.com" Port="9443" Protocol="https"> <Property Name="keyring" Value="D:\IBM\WebSphere\DM\etc\plugin-key.kdb"/> <Property Name="stashfile" Value="D:\IBM\WebSphere\DM\etc\plugin-key.sth"/> </Transport> </Server> <PrimaryServers> <Server Name="Server_Cluster_1"/> <Server Name="Server_Cluster_2"/> </PrimaryServers> </ServerCluster> The physical nodes (Transport definitions) are added as FQDNs (server1.domain.com and server2.domain.com), so you will need to resolve names to the actual IP addresses to create your server pools. Route Statements Route statements correlate a UriGroup with the corresponding ServerCluster: <Route ServerCluster="Server_Cluster" UriGroup="default_host_Server_Cluster_URIs" VirtualHostGroup="default_host"/> ... <Route ServerCluster="WebSphere_Portal" UriGroup="default_host_WebSphere_Portal_URIs" VirtualHostGroup="default_host"/> In this case, any request for a URI in the group default_host_Server_Cluster_URIs will be routed to the Server_Cluster pool, and requests for those URI's in the group default_host_WebSphere_Portal_URIs will be routed to the WebSphere_Portal pool. The LTM Configuration Now that we have a better understanding of what the plugin XML file defines, we can build the corresponding LTM configuration: server pools the iRule that selects them persistence, ssl and http profiles and the virtual servers that tie them all together to accept HTTP and HTTPS requests Pools Look up the FQDNs provided in the XML file to create the required server pools with pool members on the indicated IP addresses and ports. In most cases, HTTPS traffic will be decrypted at LTM and forwarded to the servers over HTTP, so only the 2 HTTP pools will be required. Assuming the hostnames server1.domain.com and server2.domain.com resolve to 192.168.100.1 and 192.168.100.2, we would create the following pools: pool Server_Cluster_http { member 192.168.100.1:9080 member 192.168.100.2:9080 } pool WebSphere_Portal_http { member 192.168.100.1:9081 member 192.168.100.2:9081 } If traffic will be re-encrypted, create the HTTPS pools as well: pool Server_Cluster_https { member 192.168.100.1:9443 member 192.168.100.2:9443 } pool WebSphere_Portal_https { member 192.168.100.1:9444 member 192.168.100.2:9444 } Examine the Server definitions in the XML file for other pool member settings that might be relevant, such as ratio (LoadBalanceWeight in the XML file) and connection limits. SSL Profile LTM must decrypt HTTP requests to manage them under this configuration. You can either offload SSL to LTM completely, or decrypt and re-encrypt HTTPS requests. In either case, create a clientssl profile containing a certificate & key pair for the virtual server hostname. If you are offloading SSL (HTTPS traffic will be decrypted at LTM and forwarded to the servers over HTTP), that's all you need for SSL. If instead you will be re-encrypting, create a serverssl profile to handle the re-encryption task. HTTP Profile If you are offloading SSL, create a custom HTTP profile with the "Rewrite Redirects" option set to "All", allowing the system to rewrite any self-referencing server-set redirects to the proper protocol scheme. Persistence Default cookie persistence is the simplest option you can choose here. Noting the references in the XML file to the AffinityCookie named JSESSIONID, you can alternatively enable JSESSIONID persistence with another simple iRule found in the DevCentral codeshare: JSESSIONID Persistence iRule We will use a switch statement in an iRule to replicate the actions that the Route statements define to the Apache webserver. The switch statement will contain the mappings of the UriGroup definitions to the pools defined in the corresponding Route statements. Using a switch statement in favor of a Data Group List provides the same capabilty for partial glob-style URI matching as that used in the UriGroup definitions. So consider the following UriGroup and Route definitions: <UriGroup Name="default_host_WebSphere_Portal_URIs"> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/wps/*"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/wsrp/*"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/wps/content/*"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/wps/pdm/*"/>... <Route ServerCluster="WebSphere_Portal" UriGroup="default_host_WebSphere_Portal_URIs" VirtualHostGroup="default_host"/> ... <UriGroup Name="default_host_Server_Cluster_URIs"> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/snoop/*"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hello"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hitcount"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsp"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsv"/> <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsw"/> ... <Route ServerCluster="Server_Cluster" UriGroup="default_host_Server_Cluster_URIs" VirtualHostGroup="default_host"/> Here is an iRule that replicates this definition to handle HTTP requests, mapping all of the URI strings for HTTP requests, including the embedded wildcards, to the corresponding HTTP pool: when HTTP_REQUEST { switch -glob [string tolower [HTTP::uri]] { "/wsrp/*" - "/wps/content/*" - "/wps/pdm/*" - "/wps/*" { pool WebSphere_Portal_http } "/snoop/*" - "/hello" - "/hitcount" - "*.jsp" - "*.jsv" - "*.jsw" { pool Server_Cluster_http } } } The "-" after a URI means to execute the next defined script body. The blank lines between groups are added for readability, and are not required. Adding a new URI is as simple as duplicating a line in the appropriate group and changing the URI string. Since the switch command will fall out on the first match, more specific matches must be listed before more general ones matching the same patterns with different script bodies, so thorough testing and some experimentation may be required if you have different patterns that match in both groups. (For instance if you had the URI /wps/randompath/myscript.jsp, it would match both /wps/* and *.jsp, but would be sent to WebSphere_Portal_http since it matched first.) If LTM is offloading encryption, the iRule above would work for both HTTP and HTTPS requests, since the decision is based only on the URI. If LTM is re-encrypting HTTPS requests to the backend servers, we will need a way to send HTTP requests to the HTTP pools, and HTTPS requests to the corresponding HTTPS pools after re-encrypting. The iRule above can be enhanced to check the destination port of the request to see if it was HTTP or HTTPS, then select the appropriate pool based on URI and protocol scheme: when HTTP_REQUEST { switch -glob [string tolower [HTTP::uri]] { "/wsrp/*" - "/wps/content/*" - "/wps/pdm/*" "/wps/*" { if [TCP::local_port == 80] }{ pool WebSphere_Portal_http } else { pool WebSphere_Portal_https } "/snoop/*" - "/hello" - "/hitcount" - "*.jsp" - "*.jsv" - "*.jsw" { if [TCP::local_port == 80] }{ pool Server_Cluster_https } else { pool Server_Cluster_https } } } Alternatively, you could duplicate the HTTP iRule for the HTTPS virtual server and simply replace the pool selections with those appropriate for HTTPS. The resulting iRule is slightly more efficient, since the destination port test isnot required, but it does require maintaining 2 spearate versions of essentially the same iRule. Virtual Servers Finally, define a virtual server for HTTP on port 80 and another for HTTPS on port 443. To each, apply the persistence profile and the appropriate routing iRule. To the HTTPS virtual, apply also the clientssl profile and the custom http profile. (Do NOT apply either to the HTTP virtual server or traffic will not flow as expected.) In the ServerCluster definition, we see the load balancing method is RoundRobin, so we will choose that method here. Examine the ServerCluster definition for other virtual server settings that might be relevant. Once you have associated all the objects with the virtual server, you are ready to test the application without the Apache webserver plugin. Get the Flash Player to see this player. 20080729-ReplacingWebSphereApachePlugin.mp3
