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 <daniel@xxxxxxxxxxxxx> 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
[root@localhost /usr/home/luser]# netsed tcp 10101 0 0 s/FOO/BAR
netsed 0.01b by Michal Zalewski <lcamtuf@xxxxxx>
[*] 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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • RE: Transfer a sending packet to upper TCP/IP protocol layer in IM
    ... source and destination MAC addresses are the same for both IP versions. ... the destination NIC of IPv6 packet is the same as the destination NIC of my ... encapped IPv4 packet. ...
    (microsoft.public.development.device.drivers)
  • Re: TOE brain dump
    ... primarily over ATMish core networks. ... "if you can't find header address ... the flow, if you can find a VC from cache, send the packet there" ... destination node address selector bits in header, ...
    (Linux-Kernel)
  • Re: site to site vpn with internal NAT
    ... :interface. ... :192.168.1.101 tries to contact a peer on the remote side, ... so the *destination* IP 192.168.49.x will be changed to the destination ... and since there is a match, the packet will go out over the VPN. ...
    (comp.dcom.sys.cisco)
  • RE: Transfer a sending packet to upper TCP/IP protocol layer in IM
    ... the destination NIC of IPv6 packet is the same as the destination NIC of my ... encapped IPv4 packet. ... you should clearly realize that emulating non-existent IPv6 ...
    (microsoft.public.development.device.drivers)
  • IPFilter 5.0.0 - feedback?
    ... rewrite - change both source and address fields for incoming or ... encap - encapsulated the packet in a new IP header (this will be ... encap is pretty much the same as divert, minus the port numbers to ... REWRITING SOURCE AND DESTINATION ...
    (freebsd-net)