On Fri, 31 Aug 2007 13:33:53 +0200
Daniel Hartmeier <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 31, 2007 at 08:27:29PM +1000, Norberto Meijome wrote:
>
> > rdr on $int_if proto tcp from 172.16.82.81 to any -> 127.0.0.1 port 10101
> > netsed tcp 10101 0 0 s/FOO/BAR
>
> > The traffic from XP gets redirected just fine to netsed, which replaces the
> > bytes just fine. BUT the changed packets (the output of netsed) get
> > reinjected somewhere so that the rdr hits them again, sending them back to
> > netsed ad infinitum. ( yes, i managed to hit a load of 700+ without
> > anything ever leaving BSD ...quite cool)
>
> I'm pretty sure the endless loop you describe does not pass through pf,
> except for the first iteration. In the first iteration, pf replaces the
> destination address with 127.0.0.1, and the packet goes to netsed.
> netsed changes the payload, but leaves the destination address
> (127.0.0.1 now). It sends the packet out, and since the destination
> address is 127.0.0.1, it sends it to itself. Hence the loop, which does
> not involve pf any further (i.e. there's no 'redirecting again' or such,
> AFAICT).
I was just reaching the same conclusion after some strong coffee
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 172.16.82.81:1178 to 127.0.0.1:10101
[*] Forwarding connection to 127.0.0.1:10101
[+] Got incoming connection from 127.0.0.1:51337 to 127.0.0.1:10101
[*] Forwarding connection to 127.0.0.1:10101
[+] Caught client -> server packet.
Applying rule s/FOO/BAR...
[*] Done 1 replacements, forwarding packet of size 466 (orig 466).
[+] Caught client -> server packet.
[+] Got incoming connection from 127.0.0.1:53272 to 127.0.0.1:10101
[*] Forwarding connection to 127.0.0.1:10101
[*] Forwarding untouched packet of size 466.
[+] Got incoming connection from 127.0.0.1:56367 to 127.0.0.1:10101
[*] Forwarding connection to 127.0.0.1:10101
[+] Caught client -> server packet.
[*] Forwarding untouched packet of size 466.
[+] Got incoming connection from 127.0.0.1:50565 to 127.0.0.1:10101
[*] Forwarding connection to 127.0.0.1:10101
[+] Caught client -> server packet.
[*] Forwarding untouched packet of size 466.
[+] Got incoming connection from 127.0.0.1:61660 to 127.0.0.1:10101
[*] Forwarding connection to 127.0.0.1:10101
[+] Caught client -> server packet.
[*] Forwarding untouched packet of size 466.
[+] Got incoming connection from 127.0.0.1:51520 to 127.0.0.1:10101
[*] Forwarding connection to 127.0.0.1:10101
[+] Caught client -> server packet.
[*] Forwarding untouched packet of size 466.
[+] Got incoming connection from 127.0.0.1:63554 to 127.0.0.1:10101
[*] Forwarding connection to 127.0.0.1:10101
[+] Caught client -> server packet.
[*] Forwarding untouched packet of size 466.
---
From another run, sockstat -4 shows (starting from bottom, which seem to have
the starting
connections):
root netsed 3201 3 tcp4 *:10101 *:*
root netsed 3201 4 tcp4 127.0.0.1:10101 127.0.0.1:64110
root netsed 3201 5 tcp4 127.0.0.1:55906 127.0.0.1:10101
root netsed 3200 3 tcp4 *:10101 *:*
root netsed 3200 4 tcp4 127.0.0.1:10101 127.0.0.1:57224
root netsed 3200 5 tcp4 127.0.0.1:64110 127.0.0.1:10101
root netsed 3199 3 tcp4 *:10101 *:*
root netsed 3199 4 tcp4 127.0.0.1:10101 127.0.0.1:55434
root netsed 3199 5 tcp4 127.0.0.1:57224 127.0.0.1:10101
root netsed 3198 3 tcp4 *:10101 *:*
root netsed 3198 4 tcp4 127.0.0.1:10101 127.0.0.1:64816
root netsed 3198 5 tcp4 127.0.0.1:55434 127.0.0.1:10101
root netsed 3197 3 tcp4 *:10101 *:*
root netsed 3197 4 tcp4 127.0.0.1:10101 127.0.0.1:61595
root netsed 3197 5 tcp4 127.0.0.1:64816 127.0.0.1:10101
root netsed 3196 3 tcp4 *:10101 *:*
root netsed 3196 4 tcp4 127.0.0.1:10101 127.0.0.1:58293
root netsed 3196 5 tcp4 127.0.0.1:61595 127.0.0.1:10101
root netsed 3195 3 tcp4 *:10101 *:*
root netsed 3195 4 tcp4 127.0.0.1:10101 172.16.82.81:1179
root netsed 3195 5 tcp4 127.0.0.1:58293 127.0.0.1:10101
root netsed 3194 3 tcp4 *:10101 *:*
root netsed 3194 4 tcp4 127.0.0.1:10101 127.0.0.1:53543
---
so it does seem that one netsed is feeding the other...
This explains why using pf tags isn't helping here, probably for this reason
I'm only now getting acquired in depth with PF (been using ipf and ipfw until
now... ) , so i'm sure that's not helping me either.
>
> > rdr on $int_if proto tcp from 172.16.82.81 to O.P.Q.R -> 127.0.0.1 port
> > 10101
> > netsed tcp 10101 O.P.Q.R 0 s/FOO/BAR
> >
> > How do I modify this setup so that netsed packets aren't caught again by
> > pf's rdr and sent back into netsed ? I'm happy to try other tools /
> > setups...
>
> Two approaches are possible:
>
> a) You modify netsed so it will query pf about the original destination
> address (O.P.Q.R), and re-insert that before sending out its modified
> packet. The DIOCNATLOOK ioctl(2) call can be used for that, see pf(4)
> for details and e.g. the squid source (ports) for how it's used.
I see... but i dont think i have the time to go down this path.I imagine there
isn't a way to generate a unique tag in pf and then rdr a second time (on lo0
this time) after a lookup of the original destination (which got changed for
localhost:10101 in the first rdr...)
>
> b) Instead of replacing the destination address in pf with rdr, try
> leaving it as it is, but use route-to (lo0) to get the packet routed to
> the loopback interface. This would require netsed to listen on
> INADDR_ANY (or use a raw socket, I haven't checked its source code).
hmm, netsed binds to a specific port (in my case, 10101) on all IPs of my
machine. So I would have to bind it to INADDR_ANY on , say, lo0...
Thanks a lot for your thorough reply Daniel, much appreciated.
_________________________
{Beto|Norberto|Numard} Meijome
Two things have come out of Berkeley, Unix and LSD.
It is uncertain which caused the other.
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
Warned.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
