On Fri, 31 Aug 2007 17:40:06 +0200
Mel <[EMAIL PROTECTED]> wrote:

> > netsed's output is (part ) :
> > ---
> > Script started on Fri Aug 31 07:52:12 2007
> > [EMAIL PROTECTED] /usr/home/luser]# netsed tcp 10101 0 0  s/FOO/BAR
> > netsed 0.01b by Michal Zalewski <[EMAIL PROTECTED]>
> > [*] Parsing rule s/FOO/BAR ...
> > [+] Loaded 1 rules...
> > [+] Listening on port 10101/tcp.
> > [+] Using dynamic (transparent proxy) forwarding.
> >
> > [+] Got incoming connection from to
> > [*] Forwarding connection to
> > [+] Got incoming connection from to
> > [*] Forwarding connection to
> > [+] Caught client -> server packet.  
> I think you need to figure out what this 'transparent proxy mode' of netsed 
> does, cause it should under no circumstances forward to itself...

it simply forwards the packet to the dst_ip:dst_port it originally had. But, as 
Daniel H pointed out, those packets had been rewritten by pf's rdr to go TO 
netsed's ip:port .... hence netsed wont change anything.  It works fine in 
non-proxy mode, but as I said in my first msg, that is not an option for me. 

So the obvious question is how to get the packets to netsed's IP:PORT without 
having the packet's original destination IP/PORT changed....maybe incorporating 
the netsed code into a socks5-compatible server (in my case, the app that 
generates the packets understands SOCKS). Alas, I am drawing a blank here atm.

Otherwise, i can only think that a new netgraph node would perform better than 
my current pf + netsed approach....


{Beto|Norberto|Numard} Meijome

"Ninety percent of the time things turn out worse than you thought they would.
 The other ten percent of the time you had no right to expect that much." 

I speak for myself, not my employer. Contents may be hot. Slippery when wet. 
Reading disclaimers makes you go blind. Writing them is worse. You have been 
freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to