Forum Discussion

Ricky_S_79564's avatar
Ricky_S_79564
Icon for Nimbostratus rankNimbostratus
Oct 12, 2012

Java JNLP Launcher.jar not being redirected to port 443

Hi Everyone,

 

I am fairly new on this forum so please bear with me. I have a problem with opening JNLP files whilst i have an iRule on my virtual server that redirects everything to port 443. Let me give you a background of the architevture and hopefully someone can help.

 

We have a Virtual server setup the load balances clients to two backend JBOSS/Tom Cat servers. Both the two backend servers only talk and respond in 8080. The communication between client and F5 and back to Client needed to ahve full SSL encryption, so in order for this to happen I needed to have 2 Virtual servers created working off the same single IP. One virtual server is listening on porit 443 and then one is listening on port 80. This ensures when traffic is sent back from the physcial servers (as they only talk in http) http traffic is redirected to https. For this to happen i have an iRule setup on my virtual server listening on port 443.

 

The iRule is as follows:

 

 

when HTTP_REQUEST {

 

HTTP::redirect https://[HTTP::host][HTTP::uri]

 

}

 

 

The Virtual servers have a default http profile and they use a customised Cookie persistence profile. Now everything seemed to be working fine, but I have noticed that there are issues launching JNLP files via a JNLP launcher. File are not opening and I keep getting an error message saying unable to launch application. Looking at the URL it shows that it is trying to talk over port 80, but because we have a redirect it seems the Java application does not like the re-direct and keeps trying to push the client over port 80. After troubleshooting with packet tracers and qkviews here is what I believe is happening:

 

 

The client is hitting the virtual server over port 80 and it is being redirected fine to port 443. The F5 is sending 302 showing the redirects. However when attempting to open launcher.jar the client does not come back to the F5 on 443. The client comes back to the F5 on 80 which in turn another 302 is being responded failing the launcher.jar to be opened. It appears the application ensures the client connects to port 80 overriding the headers 302 redirect.

 

 

I am looking to see if there are any other iRules i can create or edit the one above which will explicitally redirect launcher.jar to communicate over 443? We have a third party who manage the JBOSS servers and the java app, so is it something where they need to change the connector type from their end to talk in 443?

 

 

Any help would be much appreciated

 

 

Thanks

 

Ricky

 

application delivery
dev
devops
iRules

9 Replies

Sort By
  • nitass's avatar
    nitass
    Icon for Employee rankEmployee
    Oct 12, 2012
    have you tried to rewrite http to https using stream profile?

     

     

    sol8115: Overview of the Stream profile

     

    http://support.f5.com/kb/en-us/solutions/public/8000/100/sol8115.html
  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Oct 12, 2012
    If you'd like to avoid rewriting responses, perhaps one of these will help?

     

     

    http://jbossadmin.wordpress.com/2010/03/18/f5-bigip-ltm-irules/

     

    https://community.jboss.org/thread/164522
  • Ricky_S_79564's avatar
    Ricky_S_79564
    Icon for Nimbostratus rankNimbostratus
    Nov 20, 2012
    Hi guys,

     

     

    Just a quick update. I got the specific problem above to work by writing a stream expression within an iRule. The iRule is as follows:

     

     

    when HTTP_REQUEST {

     

    Disable the stream filter for all requests

     

    STREAM::disable

     

    }

     

    when HTTP_RESPONSE {

     

    Check if response type is text

     

    if {[HTTP::header value Content-Type] contains "text"}{

     

    Replace any http:// instance with http://, unless the original string is http://www.no-change.com

     

    STREAM::expression {@http://aislive.invicta.cantium.net:80@https://aislive.invicta.cantium.net:443@}

     

    Enable the stream filter for this response only

     

    STREAM::enable

     

    }

     

    }

     

     

    aislive.invicta.cantium.net is the FQDN. However what i have found now is other options within the application also do not seem to work. i.e. there are options within the application to view PDF outputs of a particular persons case history, I can produce the PDF output fine in one section of the app but cannot produce it in another option of the application.

     

     

    I ran packet captures for the PDF output that works and packet captures for the PDF output that does not work but am having trouble viewing the GET commands within these packet captures so am unable to see which tcp ports it is trying to talk in. I have also before amended the irule above to add in stream expressions for converting port 8080 into 443 but this has not done anything.

     

     

    Any help would be appreciated. If you want to see packet captures please drop me your email address and i can forward on. many thanks.
  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Nov 20, 2012
    Is there a reason you are specifying the :80 and :443. Normally, you would just change http:// to https:// as the default ports used by browsers are the ones you are using. Can you try this: {@http://@https://@}
  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Nov 20, 2012
    Also, you may not be able to see the GET requests (as they are encrypted) but the requested port will still be shown in the packet capture as it'll be the destination port of the packet.
  • Ricky_S_79564's avatar
    Ricky_S_79564
    Icon for Nimbostratus rankNimbostratus
    Nov 20, 2012
    The reason for :80 on the end is if i do not explicitally put that in and just leave it as {@http://@https://@} i get an error saying unable to launch application and below it says from http://aislive.invicta.cantium.net/ufs:80. So it looks like its looking for that port 80 on the end explicitally.

     

     

    When i do specify the :80 and then the :443 it works fine. I currently have 3 stream expressions now within this irule and they are:{@http://mydomain/ufs:80@https://mydomain/ufs:443@}

     

    {@http://mydomain/ufs:8080@https://mydomain/ufs:443@}

     

    {@http://mydomain/ufs@https://mydomain/ufs@}

     

     

    But i still get no joy
  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Nov 20, 2012

    I'm not sure you can use three expressions separately as you appear to be doing, I'd try this instead;

     {@http://mydomain/ufs:80@https://mydomain/ufs:443@ @http://mydomain/ufs:8080@https://mydomain/ufs:443@ @http://mydomain/ufs@https://mydomain/ufs@}

    If you still get no luck I would suggest you do a tcpdump on the F5 and capture the server responses on the 'internal' VLAN, which should be unencrypted and will hopefully give you a better idea of what the server is sending back.

  • Ricky_S_79564's avatar
    Ricky_S_79564
    Icon for Nimbostratus rankNimbostratus
    Nov 20, 2012
    sorry i wrote that out as quick form. i do infact have it setup like this:

     

     

    {@http://aislive.invicta.cantium.net:80@https://aislive.invicta.cantium.net:443@ @http://aislive.invicta.cantium.net:8080@https://aislive.invicta.cantium.net:443@ @http://aislive.invicta.cantium.net/ufs/@https://aislive.invicta.cantium.net/ufs/@}

     

     

    Thanks for the input, i will try it via a tcpdump

     

     

    Ricky
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Nov 20, 2012
    I don't think it will fix the issue, but you could combine the regexes into one. Also, you could be more specific and escape the periods in the "find" portion of the stream expression to match a period instead of any single character.

    {@http://aislive\.invicta\.cantium\.net(:8080|:80)?@https://aislive.invicta.cantium.net@}

    Like Steve suggested, I think a tcpdump of the issue would help isolate the issue. You could also add debug logging to STREAM_MATCHED to when the stream filter is matching: 

    
when HTTP_REQUEST {
 Disable the stream filter for all requests
STREAM::disable

set debug 1

if {$debug}{
set uri "[HTTP::host][HTTP::uri]"
}
}
when HTTP_RESPONSE {
 Check if response type is text
if {[HTTP::header value Content-Type] contains "text"}{

 Replace any http:// instance with http://
STREAM::expression {@http://aislive\.invicta\.cantium\.net(:8080|:80)?@https://aislive.invicta.cantium.net@}

 Enable the stream filter for this response only
STREAM::enable

if {$debug}{log local0. "[IP::client_addr]:[TCP::client_port]: Enabling stream filter for response to $uri - [HTTP::header Content-Type]"}

} else {
 Debug only. You can remove when testing is complete
if {$debug}{log local0. "[IP::client_addr]:[TCP::client_port]: Not enabling match for response to $uri - [HTTP::header Content-Type]"}
}
}
when STREAM_MATCHED {
if {$debug}{log local0. "[IP::client_addr]:[TCP::client_port]: Rewriting [STREAM::match] for $uri"}
}

    Aaron