Re: pf rdr + netsed : reinject loop...
On Fri, 31 Aug 2007 22:09:42 +0200 Mel <[EMAIL PROTECTED]> wrote: > On Friday 31 August 2007 18:27:26 Norberto Meijome wrote: > > 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 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. > > > > > > 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 changedmaybe > > 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 > > Figured I'd take a shot at it and it works: > # ./netsed tcp 10101 0 0 s/boo/GET/ > netsed 0.01b by Michal Zalewski <[EMAIL PROTECTED]> > [*] Parsing rule s/boo/GET/... > [+] Loaded 1 rules... > [+] Listening on port 10101/tcp. > [+] Using dynamic (transparent proxy) forwarding. > [+] Got incoming connection from 11.22.33.44:27712 to 127.0.0.1:10101 > [*] Forwarding connection to 55.66.77.88:80 > [+] Caught client -> server packet. > > Renamed the ip's to protect the innocent, but that's all. I typed boo / > HTTP/1.0 and got back a solid page of html. > Patch inlined below sig. I'm surprised no one ever caught up on this, seeing > the makefile is last modified in 2005 :) > Mel, Thanks so very much for putting this together. It works a charm. I may put together some BSD specific documentation for this port, and possible add some build-time options to the port. Also, if memory serves me right, ipfw's divert may not be modifying the packets : i have used ipfw diver with the tcpmss daemon and there were no issues - of course, it may be that tcpmss checked with ipfw's table to see what change had been done, in which case netsed should support it too. Humbled again, grateful and proud of OSS, B _ {Beto|Norberto|Numard} Meijome "I've dirtied my hands writing poetry, for the sake of seduction; that is, for the sake of a useful cause." Dostoevsky 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf rdr + netsed : reinject loop...
On Friday 31 August 2007 18:27:26 Norberto Meijome wrote: > 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 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. > > > > 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 changedmaybe > 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 Figured I'd take a shot at it and it works: # ./netsed tcp 10101 0 0 s/boo/GET/ netsed 0.01b by Michal Zalewski <[EMAIL PROTECTED]> [*] Parsing rule s/boo/GET/... [+] Loaded 1 rules... [+] Listening on port 10101/tcp. [+] Using dynamic (transparent proxy) forwarding. [+] Got incoming connection from 11.22.33.44:27712 to 127.0.0.1:10101 [*] Forwarding connection to 55.66.77.88:80 [+] Caught client -> server packet. Renamed the ip's to protect the innocent, but that's all. I typed boo / HTTP/1.0 and got back a solid page of html. Patch inlined below sig. I'm surprised no one ever caught up on this, seeing the makefile is last modified in 2005 :) -- Mel --- orig/netsed.c 2007-08-31 21:51:51.0 +0200 +++ work/netsed.c 2007-08-31 21:51:31.0 +0200 @@ -11,6 +11,12 @@ #include #include #include +#ifdef USE_PF +#include +#include +#include +#include +#endif #define VERSION "0.01b" #define MAXRULES 50 @@ -254,11 +260,19 @@ signal(SIGCHLD,sig_chld); // Am I bad coder?;> + /* Yeah, comments should be useful and frequent and not in C++ format. */ while (1) { struct sockaddr_in s; int x,l=sizeof(struct sockaddr_in); int conho,conpo; +#ifdef USE_PF +struct pfioc_natlook natlook; +int fd; +socklen_t clen; /* client length */ +struct sockaddr_in *client; /* client socket */ +#endif + usleep(1000); // Do not wanna select ;P if ((csock=accept(lsock,(struct sockaddr*)&s,&l))>=0) { fcntl(csock,F_SETFL,O_NONBLOCK); @@ -266,8 +280,51 @@ l=sizeof(struct sockaddr_in); getsockname(csock,(struct sockaddr*)&s,&l); printf(" to %s:%d\n", inet_ntoa(s.sin_addr), ntohs(s.sin_port)); + /* The logic here is that it receives an unmodified dest address, + * however that's not the case with pf. */ +#ifdef USE_PF + /* We also need the client peer to look up the nat in pf, blatantly + * borrowed from ftp-proxy(8). */ + clen = sizeof(struct sockaddr_in); + client = (struct sockaddr_in *)malloc(clen); + getpeername(csock, (struct sockaddr *)client, &clen); + memset((void *)&natlook, 0, sizeof(natlook)); + natlook.af = AF_INET; + natlook.saddr.addr32[0] = client->sin_addr.s_addr; + natlook.daddr.addr32[0] = s.sin_addr.s_addr; + natlook.proto = IPPROTO_TCP; + natlook.sport = client->sin_port; + natlook.dport = s.sin_port; + /* NOTE: It works with PF_OUT, even though rdr rule is on incoming + * traffic in my tests. More research into natlook.direction is needed + * here. + */ + natlook.direction = PF_OUT; + /* + * Open the pf device and lookup the mapping pair to find + * the original address we were supposed to connect to. + */ + fd = open("/dev/pf", O_RDWR); + if (fd == -1) { + printf("No permission to open /dev/pf, see ya\n"); + exit(EX_UNAVAILABLE); + } + + if (ioctl(fd, DIOCNATLOOK, &natlook) == -1) { + printf( +"pf nat lookup failed %s:%hu\n", + inet_ntoa(client->sin_addr), + ntohs(client->sin_port)); + close(fd); + exit(EX_UNAVAILABLE); + } + cl
Re: pf rdr + netsed : reinject loop...
On Friday 31 August 2007 18:27:26 Norberto Meijome wrote: > 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 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. > > > > 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. OK, I just tried to verify if rdr rewrites dest and indeed it does from netsed's point of view (didn't know my machine could go to 100 load and still catch SIGINT). Now I wonder how ftp-proxy(8) ever gets the server address. Time to view the source. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf rdr + netsed : reinject loop...
On Friday 31 August 2007 19:12:42 Mel wrote: > On Friday 31 August 2007 18:27:26 Norberto Meijome wrote: > > 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 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. > > > > > > 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. > > OK, I just tried to verify if rdr rewrites dest and indeed it does from > netsed's point of view (didn't know my machine could go to 100 load and > still catch SIGINT). > > Now I wonder how ftp-proxy(8) ever gets the server address. Time to view > the source. Ah, here we go: /usr/src/contrib/pf/ftp-proxy/util.c:115: /* * Open the pf device and lookup the mapping pair to find * the original address we were supposed to connect to. */ fd = open("/dev/pf", O_RDWR); if (fd == -1) { syslog(LOG_ERR, "cannot open /dev/pf (%m)"); exit(EX_UNAVAILABLE); } if (ioctl(fd, DIOCNATLOOK, &natlook) == -1) { syslog(LOG_INFO, "pf nat lookup failed %s:%hu (%m)", inet_ntoa(client_sa_ptr->sin_addr), ntohs(client_sa_ptr->sin_port)); close(fd); return(-1); } close(fd); So, in short, netsed needs extra code to deal with pf (and probably others since only a linux iptables example is listed in README) and the port maintainer should add a warning that transparent proxy mode does not (yet) work with pf/ipfw/ipf. In addition you need write access to /dev/pf :) -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf rdr + netsed : reinject loop...
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 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. > > 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 changedmaybe 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 cheers, B _ {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." Augustine 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf rdr + netsed : reinject loop...
On Friday 31 August 2007 15:10:15 Norberto Meijome wrote: > 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. I think you need to figure out what this 'transparent proxy mode' of netsed does, cause it should under no circumstances forward to itself... -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf rdr + netsed : reinject loop...
On Fri, 31 Aug 2007 13:33:53 +0200 Daniel Hartmeier <[EMAIL PROTECTED]> wrote: > 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). Hi Daniel, I tried this but i only managed to lock up the BSD VM a couple of times (not even console access, so it was not just network affected). I am not sure if i've done this correctly .. pass in on $int_if route-to 127.0.0.1 proto tcp from 172.16.82.81 to O.P.Q.R tag ROUTED keep state is that ok ? ( tried also doing route-to 127.0.0.1 $external_addr with no visible change.) I have logging enabled specifically on lo0 , but i dont see any packets going through. I am not entirely sure how netsed will pick up this packets. I've had netsed listening on *:{port} and 127.0.0.1:{port} and it obviously didnt make any difference. Could you point me to any reference / sample of what you mean? thx again, B _ {Beto|Norberto|Numard} Meijome I used to hate weddings; all the Grandmas would poke me and say, "You're next sonny!" They stopped doing that when i started to do it to them at funerals. 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf rdr + netsed : reinject loop...
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 un
Re: pf rdr + netsed : reinject loop...
On Fri, 31 Aug 2007 13:13:12 +0200 Mel <[EMAIL PROTECTED]> wrote: > I think you're looking for tagging, for example: > rdr on $int_if proto tcp from 172.16.82.81 to any tag NETSED -> 127.0.0.1 > port > 10101 > > Then you need to figure out how they come back and pass them through, for > example: > pass in on $int_if proto tcp tagged NETSED keep state > > See pf.conf(5) for more info. The examples section has one for spamd > redirection. Mel, i think you are right. Thanks, I just haven't had my brain switched on. I'll read the documentation and reply back with a solution for the list. thanks so much again! :) B _ {Beto|Norberto|Numard} Meijome Do not take away the camels hump, you may be stopping him from being a camel. 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf rdr + netsed : reinject loop...
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). > 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. 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). Daniel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf rdr + netsed : reinject loop...
On Friday 31 August 2007 12:27:29 Norberto Meijome wrote: > 1) pf.conf has : > > ext_if="em0" > int_if="em1" > nat on $ext_if from $internal_net to any -> ($ext_if) > rdr on $int_if proto tcp from 172.16.82.81 to any -> 127.0.0.1 port 10101 > - > 2) I run netsed in transparent proxy mode as : > > 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 think you're looking for tagging, for example: rdr on $int_if proto tcp from 172.16.82.81 to any tag NETSED -> 127.0.0.1 port 10101 Then you need to figure out how they come back and pass them through, for example: pass in on $int_if proto tcp tagged NETSED keep state See pf.conf(5) for more info. The examples section has one for spamd redirection. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"