Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Forward explicit SSL proxy server

Dear all,

Trying to figure out why HTTPS traffic is not passing the forward proxy. I followed the following article, configured the HTTP and SSL profiles and the two virtual servers accepting HTTP and HTTPS traffic. The only thing that we dont use is the APM part.

Result is that when using the explicit IP address configured in HTTP virtual server and the local browser client is that it works just fine when accessing HTTP websites. When I try to access a website with HTTPS using the explicit IP address configured in my browser I can see an HTTP CONNECT and the virtual server replies with service unavailable HTTP 503. This happens with all HTTPS sites. If I change the proxy setting in the browser the HTTPS (port 443) to request is simply being reset.

https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-secure-web-gateway-implementations-12-0-0/7.html

Does anyone has experience in deploying Big IP LTM as a explicit forward proxy using HTTP and clientSSL profiles only without the use of Irules?

0
Rate this Question
Comments on this Question
Comment made 09-May-2018 by Pedro Roure 211

Hi all,

I'm having exactly the same problem: HTTP works and HTTPS not work with an 503 Service Unavailable. The only difference is that i made the implementation through an SWG iApp. Any ideas ?

0
Comment made 09-May-2018 by Stanislas Piron 10481

You can find here working simple configuration of http proxy without swg (tested on version 13.1)

0

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Dear all use my config but only change the virtual server port from 443 to all and then it works fine, problem solved!

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Okay, so just a crazy set of questions here, but

  1. Do you have an HTTP profile applied to the TCP wildcard VIP? You shouldn't.

  2. Does the destination address include the mask (ex. 0.0.0.0/0), versus just 0.0.0.0? If not, it should.

1
Comments on this Answer
Comment made 14-Sep-2016 by Andrew 297

Bingo on No.2. Thanks a lot Kevin! Obviously my eye for detail failed me on this one. Looking at Marvin's screenshots, that's his problem also.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

There are at least three ways to get HTTP traffic to go through your inspection devices.

  1. Use the new SSL Intercept 1.5 iApp, which supports this use case and much more.

  2. If you're doing this across two boxes, set the internal box's default route to the internal self-IP of the second box. Or if on a single box, create a route domain that separates a "dmv internal" VLAN from a "dmv external" VLAN, and then make the box's default route the dmv external VLAN self-IP. So you'd have a client side VLAN, Internet side VLAN, and two internal VLANs through which your decrypted traffic would flow from ingress to egress.

  3. Use an iRule to force traffic through the inspection zone. In the iRule attached to the http-explicit VIP, the HTTP_REQUEST event will only fire for HTTP traffic. HTTPS traffic is sent directly to the wildcard TCP VIP. The only caveat to this is that by the time the HTTP_REQUEST event fires, the outgoing traffic hasn't been IP translated yet. In other words, the source address and port are still the http-explicit VIP's address and port. Here's what the iRule might look like:

    when RULE_INIT {
        ## User-Defined: optional internal DNS cache (in seconds)
        set static::DNSCACHE_TIME 20
    
        ## User-Defined: path for the decrypted traffic. This can be a wildcard VIP on the other side of a route domain and VLAN for inline layer 2 devices, or the inbound IP address of an inline layer 3 device. In any case it's defined as a pool so that you can effectively load balance across multiple security devices
        set static::L2_SERVICE_POOL "my_service_pool"
    }
    when CLIENT_ACCEPTED {
        ## Check for service availability. If services are down, bypass SSL inspection and just exit
        ## The default path for HTTP explicit traffic, via http-explicit, is the system default route. If the inline security devices are available, you're going to trigger commands in the HTTP_REQUEST event. Otherwise let the traffic follow its native path to the system default gateway
        if { [active_members $static::L2_SERVICE_POOL] > 0 } {
            ## At least one security service is available
            set PROXY_ON 1
        } else {
            ## No security services are available - exit via system default route without inspection
            set PROXY_ON 0
            ## Enable outbound SNAT from here (as required)
            snat automap
        }
    }
    when HTTP_REQUEST {
        ## This event is only triggered for HTTP requests
        ## HTTPS (CONNECT) requests are sent to the ingress TCP VIP by default
        if { $PROXY_ON } {
            ## Pick an active service pool member. We're routing here. Normally you'd just turn off address translation in the VIP, but since you actually need this enabled for HTTPS traffic, you're going to use a combination of 'node' and 'nexthop' to effectively creating a routed path. First pick an inline security service pool member.
            pool $static::L2_SERVICE_POOL
            set next_service [lindex [LB::select] 3]
    
            ## The incoming destination address is local, so resolve the host and re-inject the true 
            ## destination address via node command, and account for non-standard ports
            set proto 1
            catch {
                if { [HTTP::host] contains ":" } {
                    set host [lindex [split [HTTP::host] ":"] 0]
                    set port [lindex [split [HTTP::host] ":"] 1]
                } else {
                    set host [HTTP::host]
                    set port 80
                }
                set this_host [lindex [RESOLV::lookup -a ${host}] 0]
    
                ## Optionally create a local table to cache DNS responses so that you're not always doing two DNS queries per request
                #if { [table lookup -subtable DNSCACHE ${host}] ne "" } {
                #    set this_host [table lookup -subtable DNSCACHE ${host}]
                #} else {
                #    set this_host [lindex [RESOLV::lookup -a ${host}] 0]
                #    table set -subtable DNSCACHE ${host} ${this_host} $static::DNSCACHE_TIME
                #}                    
    
                ## Then set the traffic path in the direction of the resolved node
                node ${this_host} ${port}
            }
        }
    }
    when LB_SELECTED {
        ## Only do this for HTTP traffic. The true destination address was re-inserted via node 
        ## command above, so set the nexthop route to the target VLAN self-IP. So if this is HTTP traffic and the inline security services are available, you're going to instruct the outgoing traffic to go through the selected inline security service, thus forcing a routed path
        if { [info exists proto] } {
            LB::reselect nexthop ${next_service}
        }
    }
    
1
Comments on this Answer
Comment made 21-Sep-2016 by Andrew 297

Awesome, thanks Kevin. I was already looking at doing the route domain split and that's probably the way I'll go in my case, but good to have a working iRule example. The 1.5 iApp is not really ideal for what I need, as impressive as it is! :)

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

There are a few moving parts.

  1. Create the "tcp-forward" tunnel object
  2. Create the DNS resolver object
  3. Create the http-explicit profile that binds the tunnel and DNS resolver objects
  4. Make sure you have a default outbound route. It may be helpful to jump onto the command line and nslookup/dig some remote site to make sure it resolves, and then cURL to it to make sure the F5 can actually get there
  5. Create the proxy VIP - this is the IP::port that the client browser will be configured to talk to. A standard VIP, listening on specific internal IP and port (ex. 3128 or 8080), http-explicit profile, listening on client side VLAN, SNAT as required, address and port translation enabled
  6. Create the "tunnel" VIP - this is the VIP that will maintain the HTTP CONNECT tunnel for SSL traffic. A standard VIP listening on 0.0.0.0, port 443 (or port 0 if you want to be able to handle HTTPS on any port), listening on the tunnel object created earlier, SNAT as required, address and port translation disabled

So the way it works, an HTTP proxy request hits the proxy VIP, is locally resolved, and is routed out the default gateway. An HTTPS proxy CONNECT request hits the proxy VIP, is locally resolved, and the proxy VIP establishes a TCP tunnel between the client and the tunnel VIP, and then responds to the client with a "200 Connection Established". Upon receipt of this message the client initiates its SSL handshake outbound, through the TCP tunnel, out the default gateway to the remote server. You don't technically have to process SSL at the tunnel VIP. If you do, that's called "SSL Forward Proxy", and you need the SSL Forward Proxy license for that. This license allows the F5 to re-issue the server cert to the client from a locally-installed (preferably subordinate) certificate authority. In this case, you'd

  1. Install the CA certificate and private key
  2. Create a client SSL profile that enables the SSL Forward Proxy option, binds the CA cert and key, and whatever other options you want there
  3. Create a server SSL profile that enables the SSL Forward Proxy option, optionally enables the SSL Forward Proxy Bypass option, optionally sets the Server Authentication - Server Certificate option to require, and provides a certificate bundle for the Trusted Certificate Authorities option (if Server Certificate is set to require). The ca-bundle certificate bundle is comprised of the Mozilla CA trust stack and is updated often. You may optionally want to modify the Ciphers option to: "DEFAULT:ECDHE_ECDSA" if you're running at least 11.6HF5, and it would be wise to also set the Secure Renegotiation option to Request or Require as there are still many servers on the Internet that don't support RFC5746 Secure Renegotiation.
  4. Bind the client and server SSL profiles to the tunnel VIP
0
Comments on this Answer
Comment made 02-Sep-2016 by Kees van den Bos 771

Dear Kevin,

Is there a difference in licensing SSL Forward Proxy between a LAB VE and a BIG-IP LTM? (IS the SSL Forward Proxy license included in the LAB VE license?)

I was a bit surprised a license is needed for SSL Forward proxy, it would be nice if the implementation manual would be changed and a note would be added that this feature is separately licensed https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-implementations-11-3-0/14.html

Cheers,

Kees

0
Comment made 08-Sep-2016 by Marvin 412

Hi Kevin thanks for your answer, I was investigating the issue in the lab but I am still unable to get it to work. We are actually looking for the solution without the need for the extra SSL forward proxy license.

Here is the config I have so far.

Image Text

Image Text

HTTP explicit proxy refering to DNSresolver and tunnel profile

Image Text

Image Text

DNS resolving is working fine also able to access websites using F5 Big IP

Image Text

Image Text

First forward proxy virtual server created using destination and port NAT enabled, SNAT but is listening on all interfaces (I only have one vlan one-armed setup)

Image Text

Also configured the 443 virtual server listening on the tunnel. In this example there are client and server certificates created, but I also tried without using them with the same result, also removed the http profile and did not help either.

Image Text

Image Text

Image Text

The following error message appears in Wireshark while accessing a HTTPS website HTTP 503 Service Unavailable and there is no connection being setup from the F5 Big IP towards the external website, looks like F5 Big IP not accepting the request. In my lab however I do have SSL forward proxy license enabled (F5 strongbox) physical appliance.

Image Text

Maybe you have the solution on this issue or perhaps Kees?

0
Comment made 08-Sep-2016 by Kees van den Bos 771

Did you configure a forwarder on the DNSresolver?

0
Comment made 09-Sep-2016 by Marvin 412

No I did not configure a forwarder on the DNSresolver, I believe it is only needed if the local DNS server configured on the Big IP is not able to resolve certrain domains, in othet words conditional forwarding..

0
Comment made 15-Sep-2016 by Kees van den Bos 771

Hi Marvin,

See the solution in the post above, your wildcard vs should have 0.0.0.0/0 as destination.

0
Comment made 10-Oct-2016 by Marvin 412

After coming back from holidays continued with this issue and yes my whole configuration was correct but I needed to change the port 443 to * all, now it works perfect!

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

There's no difference in the license itself, but I do not believe the Lab VE comes with SSL Forward Proxy. You'll see it on the License page listed as SSL, Forward Proxy. I egree though that there are a few documents that don't mention the separate license.

0
Comments on this Answer
Comment made 02-Sep-2016 by Kees van den Bos 771

Dear Kevin,

I have been testing SSL Forward proxy on a LAB VE and it works like a charm. But I can't get it to work on a BIG-IP LTM/APM (because it is not licensed). So I think it is included in a LAB VE (I will check my license file tonight when I am back from work).

0
Comment made 08-Sep-2016 by Marvin 412

Hi Kees guess I can also talk Dutch :-), but think the rest will not understand what we are talking about, so anyway you´ve got it working in your lab I see. Did you implement it as a explicit proxy server?

0
Comment made 08-Sep-2016 by Kees van den Bos 771

Hi Marvin, I guess you could ;-). Yes we did implement it as a explicit proxy server. But this is done on a LAB VE Big-IP and it seems the SSL Proxy license is included.

This is the implementation guide https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ssl-administration-11-6-0/13.html

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I know that you can license it on the Lab VE, but I don't think the $98 Lab VE comes with by default.

0
Comments on this Answer
Comment made 02-Sep-2016 by Kevin Stewart

I misspoke. I believe that it does.

0
Comment made 02-Sep-2016 by Kees van den Bos 771

Thanx!!

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

If you attempt to use SSL Forward Proxy features without the license, it will surely fail.

At a minimum, if you remove the TCP ingress VIP and just leave the proxy VIP, you should be able to do outbound HTTP (HTTPS should fail with a 503). If that works, create the ingress TCP VIP with the following minimum properties (leave everything else at default):

  • Type: Standard
  • Destination Address/Mask: 0.0.0.0/0
  • Service Port: 443
  • VLAN and Tunnel Traffic: Enabled on the tunnel VLAN
  • Source Address Translation: SNAT if you need it for outbound traffic
  • Address and port translation: unchecked

In this case you're just creating a tunnel to allow HTTPS traffic to pass, without attempting to decrypt. Again, without the license it will definitely fail if you apply SSL profiles.

0
Comments on this Answer
Comment made 09-Sep-2016 by Marvin 412

Hi Kevin, I got your point, however I already tested it without the use of client and server SSL profiles, also without a HTTP profile attached to the VS listening on 0.0.0.0:443. If I look at the statistics on the virtual server I never see any match and no traffic at all. NAT translation is also disabled. Traffic does arrive at the VS on port 8080.

Ps: I also have SSL forward proxy license in my lab but our customer doesnt.

Any ideas?

Big IP version 12.1.1

0
Comment made 14-Sep-2016 by Andrew 297

Hi Marvin, Did you work this one out? Have followed the documentation and have the same result - no traffic hits the SSL-Forward-Proxy VIP.

0
Comment made 14-Sep-2016 by Marvin 412

Hi Andrew, no I didn´t, I followed all the instructions provided by Kevin and I have the same result as you. At least it seams like that. Traffic is not being hit at the SSL virtual server (no ssl profiles attached) and still is responding with HTTP error code service unavailable when trying the send HTTP connect via the proxy port 8080 using the explicit virtual server on the Big IP.

In my setup all HTTP traffic works seemless using the HTTP explicit proxy on the F5, only problem is the SSL traffic not passing through and not even reaching the HTTPS virtual server via the TCP tunnel where it is listening on.

Are you using the same version 12.1.1 as I do?

0
Comment made 14-Sep-2016 by Andrew 297

Yes, 12.1.1

0
Comment made 14-Sep-2016 by Hello world 162

Sorry for interrupting you. I also have same issue now. My SSL fowarding vip connecting explisit http vip via http-tunnel doesn't work well. My s/w version is ver.11.6.1 final.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Have followed the documentation and have the same result - no traffic hits the SSL-Forward-Proxy VIP.

Andrew, assuming you're also doing explicit proxy, you should have two ingress VIPs: the proxy vip listening on some IP and proxy port, and a wildcard TCP VIP listening on 0.0.0.0/0 and port 443 (or any port), that is bound to the proxy tunnel object that you created and also applied to the http-explicit proxy (which is applied to the proxy VIP).

Which VIP are you observing?

0
Comments on this Answer
Comment made 14-Sep-2016 by Andrew 297

Hi Kevin, So, as with the other guys in this thread, I do indeed have an explicit proxy VIP configured with the explicit proxy http profile. This arrangement works as a simple forward proxy. From there I have created the tcp-forward tunnel and have configured it on the same http profile. I also have the wildcard tcp vip listening on 0.0.0.0/0 and port 443 which is bound only to the tcp-forward tunnel configured in the http profile. As with the other guys, my HTTP traffic continues to be forwarded, however HTTPS requests fail and I don't see any statistics at all on the wildcard 443 VIP. I've tried with the SSL Forward Proxy profile's (client/server) as well as without. I'm going to look at doing some pcap's and turn on some additional debugging this morning.

0
Comment made 18-Oct-2016 by Marvin 412
0
Comment made 18-Oct-2016 by Marvin 412
when HTTP_REQUEST {
    HTTP::header replace Host "sslapp2.alpha.com"
}
when SERVERSSL_CLIENTHELLO_SEND {   
    set hostname "sslapp2.alpha.com"    
    set bin [binary format S1S1S1S1ca* 0 [expr [string length $hostname] + 5] [expr [string length $hostname] + 3] 0 [string length $hostname] $hostname]   
    SSL::extensions insert $bin 
}`text`
0
Comment made 18-Oct-2016 by Marvin 412

Could you explain if it is possible to use this irule without having the SSL forward proxy license? For sure we have to change the event when SERVERSSL_CLIENTHELLO_SEND to something else, because in my setup we are not decrypting the traffic. So is it possible to change it on the fly?

0
Comment made 18-Oct-2016 by Kevin Stewart

You don't SSL Forward Proxy to use this function.

0
Comment made 18-Oct-2016 by Marvin 412

Hi Kevin, thanks for your response, but how am I able to use this Irule withouth the use of an serverSSL profile because SERVERSSL_CLIENTHELLO_SEND requires one....

0
Comment made 18-Oct-2016 by Marvin 412

How to modify the Irule event to be able to get it to work without the SSL forward proxy license?

0
Comment made 18-Oct-2016 by Kevin Stewart

You're asking how to use the iRule event without SSL Forward Proxy and without a server SSL profile. Those are two different things. You don't need SSL Forward Proxy, but you do need a server SSL profile. In fact it doesn't make sense to attempt this command without server side SSL. The purpose is to inject an SNI (Server Name Indicator) field into the ClientHello message extensions, which is part of an SSL handshake.

May I ask what you're trying to do?

0
Comment made 18-Oct-2016 by Marvin 412

I understand it completely. Let me explain it in a little more detail. An internal server (client) uses the explicit proxy configured on the F5 without an SSL forward proxy license. The server connects using port 8080, sends the HTTP connect and afterwards sends the client Hello packet without the SNI extension information provided. In other wordt the internet client does not use SNI in the client Hello. The F5 forwards the Client SSL hello packet to the external webservice on the internet and it responds with an RST ACK, because it requires the use of SNI. So I am just wondering if it is possible to inject the SNI information without having an SSL profile configured, because if you have a close look at my forward proxy implementation, earlier mentioned, we dont use SSL profiles at all. Is it possible or should I use the forward SSL proxy license to be able to configure server SSL profiles and apply the Irule the inject the SNI? Hope it makes more sense now?

0
Comment made 19-Oct-2016 by Marvin 412

I think I need another way to detect the Client SSL handshake, because I dont use SSL profiles and the Client Hello is passing through transparently using the tunnel interface, something like the following Irule:

when CLIENT_DATA {

        if { ($detect_handshake) } {

                # If we're in a handshake detection, look for an SSL/TLS header.

                binary scan [TCP::payload] cSS tls_xacttype tls_version tls_recordlen

So if we are able to detect the Client SSL handshake looking into the TCP payload, we also are able to modify this packet on the fly while passing through the F5 explicit forward proxy, without renegotiating the SSL session, any ideas how to accomplish this?

https://devcentral.f5.com/codeshare?sid=717

0
Comment made 19-Oct-2016 by Kevin Stewart

So if I understand you correctly, this internal server (client) is actually NOT including an SNI in its outbound SSL handshake, but you need to insert one so that the remote host will accept the handshake. Correct?

The bigger issue here is that you cannot simply insert arbitrary data into an SSL handshake. The handshake is protected with a set of encrypted hashes (one from the client and one from the server) that is transmitted in the respective Finish messages. The hash is a recording of the messages that occurred in the handshake, so if you attempt to alter any of that, you'll break the integrity of the hash.

SERVERSSL_CLIENTHELLO_SEND works because it's part of the the server side SSL handshake and modifies the Finish hash appropriately.

So you're best bet here then would be to deploy SSL Forward Proxy so that you can explicitly insert the SNI as part of a server side SSL handshake.

0
Comment made 20-Oct-2016 by Marvin 412

Hi Kevin, exactly! Yes, I will try it in my lab; do you perhaps have some instructions to realize this? For your information, I opened a support case Service Request #C2256677 to investigate this issue and it would be nice to have some flexibility in the SSL forward proxy setup to insert SNI in the external Client Hello only, based on the external website URL destination or something like that.

Yes, I agree with you that without having a SSL forward proxy in theory it would not work because of the encrypted hashes as you mentioned and besides of that a very complex solution to solve this.

0
Comment made 20-Oct-2016 by Kevin Stewart

You simply need to license SSL Forward Proxy, import a subordinate CA certificate and private key, configure your client and server SSL profiles to enable SSL Forward Proxy and to use the CA cert/key, and then insert those SSL profiles into the TCP wildcard VIP behind your explicit proxy VIP.

Once you have that working, you can then use the SERVERSSL_CLIENTHELLO_SEND event to insert an SNI.

0
Comment made 20-Oct-2016 by Kevin Stewart

That's a great resource.

0
Comment made 20-Oct-2016 by Marvin 412

But what I need is a explicit SSL forward proxy

0
Comment made 20-Oct-2016 by Kevin Stewart

The SSL Forward Proxy piece doesn't change. In a transparent SSL forward proxy, you just have the one ingress TCP VIP. In an explicit SSL forward proxy, you have an explicit proxy VIP, and a separate TCP VIP that is bound to the http explicit tunnel. As a client issues a CONNECT to the explicit proxy VIP, a TCP tunnel is established between the client and the TCP VIP, and that TCP VIP can now decrypt and re-encrypt the traffic.

0
Comment made 20-Oct-2016 by Marvin 412

Got it, already configured in my lab environment, however the https virtual server is not being hit, but I am able to access all websites. Seems like traffic is passing through using only the forward virtual server (listening on a specific IP and port 8080).

The SSL virtual server is listening on the tunnel interface with destination 0.0.0.0/0 with port 443 and has client and server SSL profiles attached. This tunnel interface is configured in the http profile used in the previous mentioned virtual server. Also traffic is not being intercepted using the SSL profiles. Any idea why https traffic is not being hit by the SSL virtual server?

0
Comment made 20-Oct-2016 by Marvin 412

Forgot to configure the proxy settings to also pass https to the proxy IP, working on the irule right now.

0
Comment made 20-Oct-2016 by Kevin Stewart

Look at the Default Connection Handling setting in the http-explicit proxy. What do you have it set to? In order for SSL traffic to flow through the SSL VIP, this must be set to Deny.

0
Comment made 20-Oct-2016 by Marvin 412

Thanks got that one also figured out ;-), nice option though!!

0
Comment made 20-Oct-2016 by Marvin 412

Irule not working yet

when SERVERSSL_CLIENTHELLO_SEND {   
    set hostname "middleware-tst.mega-santamaria.com"   
    set bin [binary format S1S1S1S1ca* 0 [expr [string length $hostname] + 5] [expr [string length $hostname] + 3] 0 [string length $hostname] $hostname]   
    SSL::extensions insert $bin 
}
0
Comment made 20-Oct-2016 by Marvin 412

Nice one Kevin :-), Irule works but had to include the HTTP_REQUEST event. If there already exist SNI information in the client hello it will insert it twice, so would be nice to first detect if there is SNI information in the client Hello and then do nothing, else continue with the insertion of SNI information with this irule:

when HTTP_REQUEST {
    HTTP::header replace Host "middleware-tst.mega-santamaria.com"
}
when SERVERSSL_CLIENTHELLO_SEND {   
    set hostname "middleware-tst.mega-santamaria.com"   
    set bin [binary format S1S1S1S1ca* 0 [expr [string length $hostname] + 5] [expr [string length $hostname] + 3] 0 [string length $hostname] $hostname]   
    SSL::extensions insert $bin 
}
0
Comment made 20-Oct-2016 by Kevin Stewart

Try this:

when CLIENTSSL_CLIENTHELLO {
    set sni_exists [SSL::extensions exists -type 0]
    if { $sni_exists } {
    binary scan [SSL::extensions -type 0] @9a* tls_servername
    }
}

so then just check to see if tls_servername exists and/or is not empty.

0
Comment made 20-Oct-2016 by Marvin 412

Hi Ken,

I modified your Irule so it is only applied based on the destination IP addresses included in the datagroup. I verified the Client Hello packets and the SNI extension is only added when communicating towards the external IP addresses. Still would like buildin a check to see if there already exists SNI information and then skip the modification.

when HTTP_REQUEST {
# Modify SNI only if remote IP address matches
    if { [matchclass [IP::remote_addr] equals SantaMaria ]} {
        log local0. "[IP::remote_addr] changed SNI" 
        HTTP::header replace Host "middleware-tst.mega-santamaria.com"
    }
}

when SERVERSSL_CLIENTHELLO_SEND {  
    if {[matchclass [IP::remote_addr] equals SantaMaria ]} {
    set hostname "middleware-tst.mega-santamaria.com"   
    set bin [binary format S1S1S1S1ca* 0 [expr [string length $hostname] + 5] [expr [string length $hostname] + 3] 0 [string length $hostname] $hostname]   
    SSL::extensions insert $bin 
}
}
0
Comment made 20-Oct-2016 by Marvin 412

Great Kevin,

when HTTP_REQUEST {
# Modify SNI only if remote IP address matches
    if { [matchclass [IP::remote_addr] equals SantaMaria ]} {
        log local0. "[IP::remote_addr] changed SNI" 
        HTTP::header replace Host "middleware-tst.mega-santamaria.com"
    }
}

when SERVERSSL_CLIENTHELLO_SEND {  
    set sni_exists [SSL::extensions exists -type 0]
    if {(!$sni_exists && [matchclass [IP::remote_addr] equals SantaMaria])} {
    set hostname "middleware-tst.mega-santamaria.com"   
    set bin [binary format S1S1S1S1ca* 0 [expr [string length $hostname] + 5] [expr [string length $hostname] + 3] 0 [string length $hostname] $hostname]   
    SSL::extensions insert $bin 
}
}
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

You technically just need 11.4 and above to make this work. Your ingress TCP wildcard VIP should have absolutely nothing applied (assuming you're not decrypting and re-encrypting):

  • Type: Standard
  • Destination address/Mask: 0.0.0.0/0
  • Service Port: 443 (or * All ports)
  • Protocol: TCP
  • VLAN and Tunnel Traffic: enabled on the same tunnel that you used in the http-explicit profile
  • Source Address Translation: SNAT as required
  • Address Translation: unchecked
  • Port Translation: unchecked
  • Default Pool: your gateway pool

Notice that there's no HTTP or SSL profiles attached to this VIP.

0
Comments on this Answer
Comment made 14-Sep-2016 by Andrew 297

I've got that exact configuration, but the VIP is just not intercepting any traffic. I'm also getting the 503 error when looking in the pcap. I might try an older version.

0
Comment made 14-Sep-2016 by Marvin 412

Andrew, Let me know if you are able to solve it with a lower version, because I have exact the same experience with this setup.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Sorry for interrupting you. From my point of view, you might hit ID597099.

597099 SSL forward proxy appears to be unable to handle an SSL handshake inside an explicit proxy 'CONNECT' request. This appears to be the case if the explicit proxy trails the SSL Forward Proxy, or is within the inspection zone. There is no workaround.

https://support.f5.com/kb/en-us/products/ssl-orchestrator/releasenotes/product/relnote-ssl-orchestrator-12-1-0.html

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

597099 SSL forward proxy appears to be unable to handle an SSL handshake inside an explicit proxy 'CONNECT' request. This appears to be the case if the explicit proxy trails the SSL Forward Proxy, or is within the inspection zone. There is no workaround.

I don't believe that case applies here. This is when the F5 is in transparent proxy mode, there's an explicit proxy inside the inspection zone, and the client is attempting to communicate via explicit proxy requests to the "internal" explicit proxy, through the F5 transparent proxy. If you apply SSL Forward Proxy at this F5 ingress point, SSL Forward Proxy is currently not able to decrypt (and re-encrypt) the SSL session created inside the proxy tunnel between the client and the internal proxy.

In this thread, the F5 is an explicit proxy and Marvin and Andrew are just doing SSL Forward Proxy, and at this point not even trying to decrypt the outbound SSL traffic. In the F5 explicit forward proxy scenario, the proxy tunnel is actually established between the client and the ingress TCP wildcard VIP, through the proxy VIP, and the ingress wildcard VIP is the one providing SSL Forward Proxy decrypt/re-encrypt services.

Just to re-iterate, that bug is only relevant when there's an explicit proxy inside the inspection zone, the F5 is in transparent proxy mode, the client is trying to talk directly to the internal explicit proxy, and the F5 is trying to decrypt the SSL session between the client and the internal explicit proxy. You absolutely CAN work around that scenario by putting the ingress F5 in explicit mode (with some additional iRule logic to reformat decrypted HTTP requests to talk to the internal explicit proxy), or by putting the internal proxy in transparent mode.

0
Comments on this Answer
Comment made 04-Sep-2017 by DamP 60

Hi Kevin,

I am trying to apply your solution, do you have any suggestion on the iRule logic to reformat the request in order to use the BIG-IP to create another HTTP Proxy Connect request for the internal explicit proxy? Please see the following thread: https://devcentral.f5.com/questions/ssl-orchestrator-between-client-and-explicit-http-proxy-55334 in order to understand what I am trying to accomplish

Thanks.

Matteo

0
Comment made 05-Sep-2017 by Kevin Stewart

I answered in the other thread, but this use case is expected to be available in BIG-IP 13.1 and SSLO 3.0 (arriving at about the same time).

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hi Kevin,

What's the trick to forwarding the HTTP traffic out the back of the Explicit VIP? The SSL traffic traverses the tcp-forward tunnel to the wildcard VS where it can be managed. How would I forward everything else (in particular, HTTP) where I want (e.g. to another VS or gateway pool)?

I've tried using the HTTP_PROXY_REQUEST event and proxy disable to send it various places. I can successfully send it to another VS however what I really want to do is send it through a security device. The SSL Intercept iApp 1.0 does this for HTTPS via an ingress pool, however I can't get this working for HTTP?

Without a fancy iRule solution, I guess creating routes is the only way to get it where I want.

Any tips?

0
Comments on this Answer
Comment made 18-Oct-2016 by Marvin 412

Kevin, I have a very specific issue that an internal client is trying to access an external webservice using the explicit forward proxy with a SOAPui client and it works just fine. Also usign a webbrowser it works great. However when they try to communicate using an IBM AIX MQ server they are unable to connect to the external HTTPS webservice.

What I have seen in the packet capture is that the client does not send SNI information and the server does not respond with a server hello. The level of encryption and cipher support is not a problem using TLS1.2. Almost sure that SNI support is the problem, so how am I able to inject the SNI information uing the forward proxy? How to deal with this issue when there are similar problems with different external webservices? To be able to alter this behavior I guess the SSL forward proxy license is required, correct?

Looking forward to your fast response. Thanks!

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Hi Andrew, i configure the same thing like what you do. i can open http and https web (youtbe) the problem when open the facebok or download large file via browser. seems like only open 1 connection, it very slow to download or load the facebook web face this problem before?

i run VE, with 8GB RAM and 4 core cpu. i dont think throughput issue.

thanks in advance.

0