We have been struggling to try and configure a traffic script so our virtual traffic manager (v18.3) can act as a forward proxy of HTTPS traffic. We found the post for HTTP traffic which seems to work ok. We also found a very old post that had an example TrafficScript to handle HTTPS traffic. The traffic manager balks at trying to apply the HTTP rule as given stating protocol specific rules ust be used instead of generic ones. So we have been trying to conver the old script and having no luck. The script is from https://community.pulsesecure.net/t5/Pulse-vADC-Updates/Stingray-Traffic-Manager-Forward-Proxy-and-T.... That script is shown below. Has anyone been able to get their virtual TM to act as a forward proxy for HTTPS traffic and can maybe suggest tips to get it working?
# The CONNECT request ends with an empty line; the \r is optional: $request = request.getLine("\r?\n\r?\n"); # Check for SSL connect requests. If it's not a CONNECT then break if( ! string.regexMatch($request,"CONNECT (.+?)[0-9]+?) HTTP.*") ) break; # This is an SSL request $host = $1; $port = $2; # Resolve the hostname to an IP address $ip = net.dns.resolveHost( $host ); if ( $ip == "" ) { log.info("Unknown host: '" . $host . "'"); request.sendResponse("HTTP/1.1 404 Unknown Host\r\n\r\n"); } # Select the destination node, and tell the client we're connected. pool.select("Forward Proxy", $ip, $port); # Everything after the first empty line must go to the remote # destination ('back-end'), but everything up to the first line # is only used by the proxy (ZXTM). $to_skip = string.len($request); # Read in the rest of the request (if any). Do not append, # however, as request.get() gives the full string again $request = request.get(); if( string.len($request) == $to_skip ) { request.sendResponse("HTTP/1.1 200 Connection Established\r\n". "Proxy-Agent: ZXTM/Request\r\n\r\n"); } else { request.skip($to_skip); # tell the response rule that it must send the # 'Connection established' status line connection.data.set("must_send_200", 1); }
Thanks,
Michael
Hi Michael,
From the original article, it looks like the rule is intended to be applied to a Generic Client First virtual server. It sounds like you might be trying to apply it to an HTTP virtual server instead, based on the error message you are seeing?
-Andy