PERFORCE change 132710 for review

[Qing Li]

> -----Original Message-----
> From: Andre Oppermann [mailto:andre at freebsd.org] 
> Sent: Tuesday, January 08, 2008 2:13 PM
> To: Adrian Chadd
> Cc: Perforce Change Reviews
> Subject: Re: PERFORCE change 132710 for review
> 
> Adrian Chadd wrote:
> > On 08/01/2008, Andre Oppermann <andre at freebsd.org> wrote:
> > 
> >> Reinventing the wheel?  Have a look at IPFIREWALL_FORWARD which 
> >> supports transparent proxying as well.
> > 
> > Yes, but redirects it to a local listen() socket, 
> effectively spoofing 
> > the destination IP. The client (ie, the computer making the 
> connect()) 
> > thinks its talking to the original destination.
> > 
> > This is meant to implement the other end - spoofing the local IP on 
> > sockets that you connect() to, spoofing the local IP and not the 
> > destination IP. This is intended to let a FreeBSD box (with 
> relevant 
> > symmetrical routing) pretend to be a client on a connect() 
> to a remote server.
> > 

	"with symmetrical routing" I assume you are referring to
	in-line deployment ...

> > If this can be done within pf/ipfw right now then please 
> let me know. 
> > :)
> 
> The IPFIREWALL_FORWARD functionality should be able to do 
> that as well.  

	Yup.  :)    

	You could actually IPFIREWALL_FORWARD to 127.0.0.1 as 
	long as you have updated in_pcb.c to allow for spoofed
	socket.

>
> The direction of the spoof capture doesn't 
> really matter as long as you reverse the rule from the 
> traditional transparent proxy example.
>

	I don't quite understand what you mean here, but
	the directionality really do matter if you don't
	want to leak packets from a guard policy (well, more
	accurately how many packets that are allowed to leak).

>
>  The only missing 
> piece is binding a local socket to a non- local IP address.  
> That you have to address in netinet/in_pcb.c either with 
> global sysctl or a individual socket option.  Should only 
> take a dozen lines or less to do that (including the sysctl 
> or socket option code).
> 

	Yup. That's the key piece here.

	-- Qing


> --
> Andre
> 
> 
>