Re: [squid-users] squid 2.6 + transparent + ipfw

From: Andrew Pantyukhin <infofarmer@dont-contact.us>
Date: Sat, 8 Jul 2006 20:36:55 +0400

On 7/8/06, Henrik Nordstrom <henrik@henriknordstrom.net> wrote:
> lör 2006-07-08 klockan 17:55 +0400 skrev Andrew Pantyukhin:
>
> > FWIW, I was able to get the subj going by applying the
> > following patch:
> >
> > http://people.freebsd.org/~sat/diffs/patch-src-client_side.c
> >
> > I'm sure there might be a better way, but the thing is ipfw
> > doesn't change packet headers when forwarding packets.
> > So we just need a placeholder clientNatLookup function that
> > returns a success. I tested it with simple 'GET /' requests
> > and it works
>
> Do I understand you correctly that ipfw returns the real destination
> address in getsockbyname()?

I'm sorry, but I'm not into network programming.

ipfw manpage says that the forward action "does not change
the contents of the packet at all". clientNatLookup() seems to
restore real destination address and port as most firewalls
change them. ipfirewall only changes L2 dest addr when
forwarding to remote host and only sends packet verbatim to
a designated socket when forwarding to local host.

Here's the quote:

"The fwd action does not change the contents of the packet at all.
In particular, the destination address remains unmodified, so
packets forwarded to another system will usually be rejected by
that system unless there is a matching rule on that system to
capture them. For packets forwarded locally, the local address
of the socket will be set to the original destination address of
the packet. This makes the netstat(1) entry look rather weird
but is intended for use with transparent proxy servers."

> Do you know if there is a reasonable method to tell if this was a
> intercepted connection or a normal connection?

I might be wrong, but I think one should compare the address
of an accepted socket to the address of the listening socket.
Received on Sat Jul 08 2006 - 10:36:57 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Aug 01 2006 - 12:00:01 MDT