For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

robson_78577's avatar
robson_78577
Icon for Nimbostratus rankNimbostratus
May 23, 2013

HTTP to HTTPs on High Ports

Hi all,

 

I have a client environment who needs to connect with webservers, using HTTP. Hovewer, the servers only supports HTTPS.

 

So, I configured a Virtual Server to receive these requests, and send to Servers using this configuration:

 

 

VS Address: 10.10.10.10

 

Service Port: 80 (HTTP)

 

 

Type: Standard

 

Protocol Profile (Client and Server): profile_TCP

 

HTTP Profile: Profile_http

 

SSL Profile Client: None

 

SSL Server Profile: serverssl (default)

 

 

Members: 20.20.20.20:443

 

No Irules and Http Class Profiles

 

 

This VS works fine and well, when I made a test from Browser. (http:10.10.10.10/content/)

 

But my client environment is configured to use http requests on TCP port 4500. So I created a same VS like above, with the same configurations, and the same requests are not working, using http:10.10.10.10:4500/content/

 

Is there a problem to use a different TCP port (like TCP high Ports) instead TCP 80? I am sure about the both configurations and the only different thing is the TCP port.

 

any ideas?

 

 

basic
getting started
new to f5

5 Replies

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    May 23, 2013
    That should definitely work. Is there any chance that the server is choking on the host header?
  • robson_78577's avatar
    robson_78577
    Icon for Nimbostratus rankNimbostratus
    May 24, 2013

    Hi Kevin,

     

    I dont know. I am a new one on this kind of connections. The usual connections that I made on LTM is about HTTPS (443) to HTTP (any high port). Considering HTTPS connections to Server, I am unable to open the HTTP Header (with Wireshark i.e.) and see what I am sent to Server.

     

    Do you have any idea to see/open this header considering HTTPS?

     

    Do you know if in this case, the host header contains the port information? If its a problem, how do I to remove this info? What is the best way, Stream Profile or Irules?

     

    Tks

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    May 24, 2013
    An iRule-based stream profile will definitely get rid of the port, which would show up in the Host header. The first thing you have to find out though is WHY it's failing. Here are some thoughts and possible troubleshooting steps.

     

     

    1. It should already be set, but make sure port translation is enabled on the virtual server. From there run a TCPDUMP from the F5's command shell and watch traffic between the F5 and the server. You should see the 443 traffic, which I assume ends with a reset from the server AFTER the handshake.

     

     

    2. Observe the server logs for anything anomalous.

     

     

    3. Run an SSLDUMP between the F5 and the server. This will allow y
  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    May 24, 2013
    An iRule-based stream profile will definitely get rid of the port, which would show up in the Host header. The first thing you have to find out though is WHY it's failing. Here are some thoughts and possible troubleshooting steps.

    1. It should already be set, but make sure port translation is enabled on the virtual server. From there run a TCPDUMP from the F5's command shell and watch traffic between the F5 and the server. You should see the 443 traffic, which I assume ends with a reset from the server AFTER the handshake. If you know that traffic is making it to the server, and that they're at least negotiating the initial TCP handshake, that there must be something going on higher in the stack.

    2. Observe the server logs for anything anomalous.

    3. Run an SSLDUMP between the F5 and the server. This will allow you to see the payload.

    ssldump -k -i 0.0 -AdNn port 443

    where

    -k is the path to the private key that the server uses for SSL. You'll need to copy that to the F5.

    -i is the interface. We're saying any interface, though you can be more specific

    -AdNn is some switches to make the output easier to read

    "port 443" is the filter. Unlike TCPDUMP this command absolutely requires a filter. You can again be more specific if necessary.

    What we're looking for is something in the server payload that may indicate that it doesn't like the port in the Hosts header. Anything anomalous.

    4. Look at the client side to see if you're getting anything weird there. A redirect to a weird port or address, an odd message, anything. You may need to compare all of this data to a working connection that uses port 80 (without the port in the Hosts header).

    5. Finally, you can manually change the Hosts header in the Request payload by issuing the HTTP::header replace Host command. 

    
when HTTP_REQUEST {
    HTTP::header replace Host 
}

  • robson_78577's avatar
    robson_78577
    Icon for Nimbostratus rankNimbostratus
    May 25, 2013

    Hi Kevin,

     

    Thanks for the explanation. I will try to do these steps, and I return back on next monday with the results.

     

    Regards