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. ###
@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.
@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.
@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.
@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.
@Michael_Goetz sounds like a plan. On a device that I currently manage, if a FQDN that isn't configured as a resolve properly will still show DNS request but will not have a response back from the DNS caching server that you are querying. If you do the following tcpdump and receive nothing it is most likely an issue with the forward proxy and how it maps the Virtual Servers to the DNS resolver.
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"
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.
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!
