IP to FQDN

Do you want to check the Host header on all requests through the VIP and if it's one particular IP address, replace the value with a hardcoded value? If so, you can add an HTTP profile to the VIP and use a rule like this:

 
 when HTTP_REQUEST { 
  
     Check if Host header matches 1.1.1.1. 
     Use catch to handle non-IP Host values. 
     If IP::addr matches 1.1.1.1, $result will be 1 
    if {not ([catch {IP::addr [HTTP::host] equals 1.1.1.1} result]) && $result==1}{ 
       HTTP::header replace Host "www.example.com" 
    } 
 } 
 

If that's not an accurate assumption of your scenario, can you clarify what you're trying to do?

Aaron

If by "outgoing: you mean response traffic then you would need to use HTTP::header replace Location "www.example.com" is hoolio's example as responses do not have a Host header. Also, if the IP address is embedded in the page you would need to use a stream profile to rewrite it. Since there seems to be only one host in question here a simple stream profile with the IP address in the Source field and the FQDN in the Target field should get it done. If there are multiple hosts in questions then you could do this with am irule:

 

 

when HTTP_RESPONSE {

 

Replace IP Addresses from HTTP responses

 

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

 

STREAM::expression "@[email protected]@ @[email protected]@ @[email protected]@"

 

STREAM::enable

 

} else {

 

STREAM::disable

 

}

 

}

 

 

 

HTH,

 

 

Joe

Hi Joe,

 

 

Nice one. I wasn't sure if the original poster was trying to rewriite an outbound request or response.

 

 

One note on the stream profile: it's applied to request and response payloads of both text and binary content types. So it's always a good idea to use an iRule to enable the stream filter only on the specific responses you want it for. Also, as there isn't a way to update the content-length header in requests using a stream profile and iRule, a stream profile isn't a valid option for rewriting request payloads when the find/replace strings are a different length.

 

 

Aaron

Sorry for any confusion in my explanation, I will try again.

 

We have a Apache web server that needs to send information to an external server. From what I am being told the encryption feature of this server is a resource hog so the F5 is needed for that task. The Apache server sends the information to the vip on the F5, the F5 encrypts the traffic and sends it to the pool member which is an external server. The issue I have is the node is defined by ip address 1.1.1.1 the external web server does not have a ptr record so reverse lookup will not work and connection fails. We are sending information to the external server there is no request nor is it a response. All traffic on this VIP will need to have the ip address changed to FQDN both values will stay the same.

 

Does this make sense?

 

So the client is a server in your network. That Apache "client" opens a connection to the VIP and is load balanced to an external host. Does that sound about right?

 

 

Who is doing a reverse lookup of the IP address to try to resolve it to a hostname? LTM doesn't need to a FQDN in the HTTP host header for load balancing. By default LTM would just translate the destination address on the TCP packets to the selected pool member and send the HTTP headers on unmodified.

 

 

Is the device that needs to resolve an IP address inspecting the source or destination IP address on the packets or the HTTP host header value? Can you clarify what you've configured so far and what isn't working?

 

 

Thanks,

 

Aaron

Yes that is correct other than there is only one external host. I guess no one is doing a reverse lookup/ the LTM tries to connect to 1.1.1.1 and connection fails. If I go to 1.1.1.1 from a web browser connection fails but if I go to site.com connection works! I have nothing more than a VIP and Pool configured right now.

Okay, so it sounds like the destination host might be filtering on the host header value in requests. You could try testing this from the LTM command line using curl to insert a host header:

 

 

curl -kv https://1.1.1.1/index.html -H "Host: www.example.com"

 

 

If that works, you should be able to use the iRule in my original reply to rewrite the host header to a static string. You'll need to include a server SSL profile on the VIP to have LTM accept clear text HTTP from the client and establish an SSL handshake on the server side.

 

 

Aaron

Here is what I received

 

 

[root@:Active] config curl -kv https://1.1.1.1/index.html -H "Host: www.example.com"

 

* About to connect() to 1.1.1.1 port 443

 

* Trying 1.1.1.1... connected

 

* Connected to 1.1.1.1 (1.1.1.1) port 443

 

* error setting certificate verify locations, continuing anyway:

 

* CAfile: /usr/share/ssl/certs/ca-bundle.crt

 

CApath: none

 

* SSLv2, Client hello (1):

 

Unknown SSL protocol error in connection to 1.1.1.1:443

 

* Closing connection 0

 

curl: (35) Unknown SSL protocol error in connection to 1.1.1.1:443

 

[root@:Active] config

 

 

Aaron,

 

Yes I am replacing ip and FQDN since this is on a public forum

 

Ran the following

 

[root@:Active] config curl -kv https://1.1.1.1:1234/service.svc?xxxx -H "Host: test.example.com"

 

* About to connect() to 1.1.1.1 port 1234

 

* Trying 1.1.1.1... connected

 

* Connected to 1.1.1.1 (1.1.1.1) port 1234

 

* error setting certificate verify locations, continuing anyway:

 

* CAfile: /usr/share/ssl/certs/ca-bundle.crt

 

CApath: none

 

* SSLv2, Client hello (1):

 

SSLv3, TLS handshake, Server hello (2):

 

SSLv3, TLS handshake, CERT (11):

 

SSLv3, TLS handshake, Server finished (14):

 

SSLv3, TLS handshake, Client key exchange (16):

 

SSLv3, TLS change cipher, Client hello (1):

 

SSLv3, TLS handshake, Finished (20):

 

SSLv3, TLS change cipher, Client hello (1):

 

SSLv3, TLS handshake, Finished (20):

 

SSL connection using RC4-SHA

 

Mike

 

Was the request successful? Was there anything in the curl output after the SSL handshake completed? For reference, below is a complete request to https://mail.google.com.

 

 

I notice you're making the request to a non-standard port (1234). Do you have the same port configured for the LTM pool member(s)? Is the pool member marked up by an HTTPS monitor?

 

 

If so, what happens when a client makes an HTTP request to the VIP? Do you see a request to the pool member go out? You can use tcpdump to check this (tcpdump -ni 0.0 host 1.1.1.1 and port 1234).

 

 

Aaron

 

 

$ curl -vk https://mail.google.com

 

* About to connect() to mail.google.com port 443 (0)

 

* Trying 209.85.229.83... connected

 

* Connected to mail.google.com (209.85.229.83) port 443 (0)

 

* successfully set certificate verify locations:

 

* CAfile: none

 

CApath: /usr/ssl/certs

 

* SSLv3, TLS handshake, Client hello (1):

 

* SSLv3, TLS handshake, Server hello (2):

 

* SSLv3, TLS handshake, CERT (11):

 

* SSLv3, TLS handshake, Server finished (14):

 

* SSLv3, TLS handshake, Client key exchange (16):

 

* SSLv3, TLS change cipher, Client hello (1):

 

* SSLv3, TLS handshake, Finished (20):

 

* SSLv3, TLS change cipher, Client hello (1):

 

* SSLv3, TLS handshake, Finished (20):

 

* SSL connection using AES256-SHA

 

* Server certificate:

 

* subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=mail.google.com

 

* start date: 2009-12-18 00:00:00 GMT

 

* expire date: 2011-12-18 23:59:59 GMT

 

* common name: mail.google.com (matched)

 

* issuer: C=ZA; O=Thawte Consulting (Pty) Ltd.; CN=Thawte SGC CA

 

* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.

 

> GET / HTTP/1.1

 

> User-Agent: curl/7.19.6 (i686-pc-cygwin) libcurl/7.19.6 OpenSSL/0.9.8l zlib/1.2.3 libidn/1.15 libssh2/1.2

 

> Host: mail.google.com

 

> Accept: */*

 

>

 

< HTTP/1.1 200 OK

 

< Cache-Control: public, max-age=604800

 

< Expires: Tue, 02 Feb 2010 17:45:59 GMT

 

< Date: Tue, 26 Jan 2010 17:45:59 GMT

 

< Refresh: 0;URL=https://mail.google.com/mail/

 

< Content-Type: text/html; charset=ISO-8859-1

 

< X-Content-Type-Options: nosniff

 

< X-XSS-Protection: 0

 

< X-Frame-Options: SAMEORIGIN

 

< Content-Length: 234

 

< Server: GFE/2.0

 

<