ASA - port redirection to proxy

[jedavis]

Hi All,

Running 8.2.  I have some firewalls on internal network to provide some segmenation and security for critical networks on the inside interface. See attachment. Clients on the inside interface will generate SSL requests for both internal addresses and for internet addresses.  What I need to do is allow SSL port 443 traffic destined for internal addresses to pass through unmodified.  SSL port 443 traffic to internet addresses must be sent to a proxy server.

The set of internal IP subnets is identified in a network object-group. I am currently not NATting anything.  How can I do this?

TIA

-Jeff

[will]

Hi jeff. I played around with a similar deployment for a customer a few months ago. If you had one of those special appliances, which ASA/Cisco can use for URL inspection, that is a configurable parameter in the ASA. that means your proxy has to be of a certain (very limited) type. There are a few vendors that inter-operate with ASA and you can point the request to those style appliances. You probably don't have that, but just throwing it out there - just in case. This also requires some subscription fees.

Another option is to set the default gateway of your ASA to be the proxy server - but that is problematic too. Proxy usually cannot handle all types of traffic, and its a bit dangerous to do this.

In the end, what I would recommend, is deploy proxy auto configuration on the clients - which pretty much bypasses the ASA for "proxy stuff". the traffic would still pass through it on the way to the middleman proxy server in your diagram. IE 9.0 and the newer versions of FireFox can be manipulated by group policy - and most IE clients are ready to go without any group policy configuration. So this is fairly easy.

The proxy auto config script works when you add a DNS entry on your internal DNS servers for the proxy pac file location. Once this is setup, you just need to dump a small (.PAC) file onto a web server (your PAC auto config server). the browser clients pull this file when they open up, pull down the PAC file and then would start using 10.3.3.3, for example. You would put your exclusions webhosts (in the 10.1.1.1/24 subnet) into this file.

You can play with this by developing the PAC file locally on your PC, and then moving file to the web server. the Web server can be any old web server  , serving up just this one file. With IIS, and probably apache, you need to modify the web server to serve up this PAC file with a certain MIME type. that is convoluted the first time, but fairly easy:

http://marckean.wordpress.com/2010/02/09/setting-up-proxy-pac-files-in-iis7-for-proxy-use/

Check ot these M$ and other links:

http://technet.microsoft.com/en-us/library/cc939951.aspx
http://en.wikipedia.org/wiki/Proxy_auto-config

When the clients are not in the office (on the LAN), they will not get the PAC file because the DNS will not feed them up that URL/file. BTW, if the proxy server happens to be a M$ ISA server, then you can do some custom things with that device, similar to the proxy auto config. Search Google for "WPAD ISA pac file," or something like that.

[jedavis]

Thanks for the reply Will.

I guess I didn't clearly explain my goal, which is preventing unauthorized https access to the internet.  A content filtering proxy is one option.   The problem with the client autoconfig approach is that it really doesn't accomplish what we need in that it would still be possible for a rogue client to bypass the autoconfig. This would need to be enforced by the network, not by the client.

In the end it really doesn't matter.  We have changed our approach and this scenario is no longer necessary.  But I do appreciate you taking the time to reply.

Thanks,

-Jeff