Firewall Wizards mailing list archives

RE: PIX Transparent proxy


From: "Luke Butcher" <Luke.Butcher () alphawest com au>
Date: Thu, 11 Nov 2004 08:22:33 +1100

Since posting this I have made some further discoveries. It seems the
'interface' keyword basically translates to what ever IP is on the
interface at the time. If I change it for another address and try to
http to that address it works as expected.

I then thought I'll just replace interface with any or 0.0.0.0. Bzzzzt,
no joy. Basically it will only do a one to one relationship, so to have
for example a class C as the addresses it will intercept you need a full
C class of machines to  translate the IP adresses to. So to try and
capture all traffic is just unrealistic.

It's a pity because the functionality is almost there, it just needs the
ability to capture a wider range of destination addresses.

--
Luke Butcher

My sister opened a computer store in Hawaii. She sells C shells by the
seashore.

-----Original Message-----
From: Luke Butcher 
Sent: Wednesday, 10 November 2004 10:37 AM
To: firewall-wizards () honor icsalabs com
Subject: Re: [fw-wiz] PIX Transparent proxy

On Fri, 22 Oct 2004 12:13:38 -0700, Juan Pablo Feria
<feria () tpitic com mx> wrote:

on the squid documentation tells about routers, but the configuration

commands are not on the pix...

http://www.squid-cache.org/Doc/FAQ/FAQ-17.html#ss17.5

Anyone has any ideas to send the port 80 requests to the squid box?

I do not believe PIX offers this functionality.

Cisco routers offer two distinct options which will assist in deploying

a "transparent" caching proxy -- route-map (to re-route packets to a 
cache based on the port, protocol or any other ACL match) and  Web 
Cache Communication Protocol (WCCP).

I to was just looking at the same thing the other day.
It appears the PIX will do a static PAT (since version 6.2?) in order to
solve this type of thing.

The command:
  static (inside,outside) tcp interface www 10.0.0.1 www netmask
255.255.255.255
Is apparently the way to go about it. Oh yeah you need the right
access-list on the outside too something like
  access-list outside_in permit tcp any host pu.bl.ic.ip eq www

My dilemma is I can't seem to make it work. I'm not using it in the
Cisco style fashion but more like what Juan wants.

  static (inside,browse_dmz) tcp interface 80 10.0.0.1 3128 netmask
255.255.255.255
  access-list from_browse_dmz permit tcp 192.168.1.0 255.255.255.0 any
eq 80
  access-group from_browse_dmz in interface browse_dmz

This shows nothing in the pix logs, and a tcpdump on 10.0.0.1 shows
nothing hitting it. If I remove the access-list rule it does show the
packets being denied so I think they are being allowed successfully
(also confirmed but hit count on a show access-list. The routing from
browse_dmz to inside also works OK as I tested allowing 3128 directly
and you can get to 3128 fine. I also bumped IE/Mozilla from the equation
by trying a straight - telnet some.host 80


Anyone got any ideas? Maybe able to solve two problems at once.

--
Luke Butcher

It's not winning that matters, it's winning in style that matters... 

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards


Current thread: