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.
