Forum Discussion

Michael_Goetz's avatar
Michael_Goetz
Icon for Nimbostratus rankNimbostratus
Feb 14, 2023

Transparent Forward Proxy iApp

Hello, my organization has used a simple F5 Forward Proxy iApp, built by F5/Websense, for many years.  It functioned exactly as expected - a simple transparent proxy that allowed servers behind the F5 communcate over HTTPS with systems outside our network (not internet).  No cert inspection or any authenication beyond allowed vlans, just an extremely basic "forwarder."  

After upgrade from 13.x to 16.x it no longer functions as expected.  Packet captures show the process stopping at DNS lookups and never making the connect to the outside systems.  Possibly some command in the iApp code no longer exists in v16.

Does anyone know if there is an alternative to this iApp without SWG?  Plenty of posts here point to explicit proxy but rarely a transparent proxy, or a simple proxy without SWG.  Appreciate the assistance!

 

Header from the original iApp implementation if anyone is familiar with it:

#################################################################################
### FORWARD PROXY IAPP
### Version: 1.0 - F5 Networks
###
### Makes use of WISP API - Copyright 2013 Websense, Inc. All Rights Reserved.
### Functionality: Supports a generic, anonymous CONNECT or SOCKS proxy.
###

application delivery

7 Replies

Sort By
  • Paulius's avatar
    Paulius
    Icon for MVP rankMVP
    Feb 15, 2023

    Michael_Goetz From my understanding the transparent forward proxy only functions with SWG. I believe your only option if you do not wish to purchase a APM license and SWG subscription is to configure an explicit forward proxy without SSL inspection. The explicit forward proxy is pretty easy to configure following the following document. I have tested this configuration several times and it works exactly the way you describe just not a transparent forward proxy. I do want to note that if for some reason you perform DNS queries through your management interface of the BIG-IP you will need a DNS server that is accessible through one of the routed interfaces because you cannot for the DNS Resolver in this configuration to go through the management interface no matter what route you put in place because it will always want to leave one of the routed interfaces that you have virtual servers and what not associated to.

    https://community.f5.com/t5/technical-articles/configure-the-f5-big-ip-as-an-explicit-forward-web-proxy-using/ta-p/286647

  • Michael_Goetz's avatar
    Michael_Goetz
    Icon for Nimbostratus rankNimbostratus
    Feb 15, 2023

    Paulius Thank you sir.  The original forward proxy iApp did not require SWG.  Actually I think it was built before SWG was even a product.  We used it from version 11 to version 13.  Only version 14+ seems to have broken it, so it was a method at least at one point in time.  Oddly I cannot find any references to it DevCentral even though it was written by F5.

    I setup the explicit proxy as mentioned in Steve's thread.  It does respond but now we're receving a 503 error.  I saw a reply to Steve's thread which suggested adding the route domain in the profile if a 503 is received, but that did not fix it.

    9 230.341665 X.X.116.153 X.X.115.133 HTTP 357 IN s1/tmm3 : CONNECT externalsystem.com:443 HTTP/1.0
    10 230.341744 X.X.115.133 X.X.116.153 TCP 211 OUT s1/tmm3 : 443 → 58998 [ACK] Seq=1 Ack=132 Win=65024 Len=0 TSval=1446237578 TSecr=1680799487
    11 241.621895 X.X.115.133 X.X.116.153 TCP 283 OUT s1/tmm3 : 443 → 58998 [PSH, ACK] Seq=1 Ack=132 Win=65024 Len=72 TSval=1446248858 TSecr=1680799487 [TCP segment of a reassembled PDU]
    12 241.621903 X.X.115.133 X.X.116.153 HTTP 211 OUT s1/tmm3 : HTTP/1.0 503 Service Unavailable

    Seems like it may not be making the full trip to the external system, and I did not see any DNS requests in the packet capture.

     

    • Paulius's avatar
      Paulius
      Icon for MVP rankMVP
      Feb 15, 2023

      Michael_Goetz If you are not seeing the F5 perform any DNS requests for the forward proxy the DNS Resolver might not be configured correctly and that might be why this is failing. I never had any luck configuring a wildcard DNS Resolver but I was able to configure individual DNS Resolvers entries for each domain we were dealing with and that fixed our issues with DNS queries.

      • Michael_Goetz's avatar
        Michael_Goetz
        Icon for Nimbostratus rankNimbostratus
        Feb 15, 2023

        Paulius Good point!  I've looked into the config portion of the Resolvers list and everything looks correct.  The old iApp used a pool with the name servers as nodes which worked in v13, but coincidentally lack of DNS queries seemed to also be the issue with the iApp too, as indicated in the packet captures after moving to v16.  No specific error either like 'no response' or 'connection refused', just would not perform the lookup part of the routine at all.  Would be great if it was just a DNS issue.

        Asking our network team to check if the F5 has a clear path to the nameservers and will report back.

  • mstark007's avatar
    mstark007
    Icon for Nimbostratus rankNimbostratus
    Jun 13, 2023

    Hey Michael..   Probaby way too late to help you out..  but I had similar issue when upgrading.   We had to modify line 32 on forward_proxy_internal_explicit_proxy_config_irule ...  

    set static::resolver_ip_forward_proxy_internal <your-virtual-server> to the IP address of the virtual server... something like...  

    set static::resolver_ip_forward_proxy_internal "10.10.1.101"

    Proxy is working fine for us on 15.1.8.2

     

     

    M.

  • Michael_Goetz's avatar
    Michael_Goetz
    Icon for Nimbostratus rankNimbostratus
    Jun 13, 2023

    M, thanks for your reply, and also happy to see we're not the only one in the world using the Forward Proxy iApp!  And would you believe I just got this resolved a few weeks ago?  I did not need to change the resolver address but that is good information to know how to do that.

    Here's something that may help if you move to v16.  The HTTP:discard disable command, used by the Forward Proxy iApp in HTTP CONNECT methods, is not operating as it should on v16 and is currently in the bug tracker under Bug ID# 1284589, which may be again be updated in the future to 1284589-2 as a bug on top of a bug was also found in our troubleshooting with F5 Support.

    https://cdn.f5.com/product/bugtracker/ID1284589.html

    F5 Engineering provided us with a hotfix that resolves the issue completely as replacing "HTTP:disable discard" with "HTTP:disable" does not fully fix the issue.  If using the FP iApp and v16 an EHF needs to requested from F5 referencing that bug ID, until when/if the fix makes it into a firmware release.

    Appreciate your response and hope that helps in the future!