Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Jun 2000 00:24:54 -0700
From:      "Crist J. Clark" <cjc@earthlink.net>
To:        Andy Dills <andy@xecu.net>
Cc:        "purpledreams.com system administrator" <super@purpledreams.com>, freebsd-ipfw@FreeBSD.ORG
Subject:   Re: Hijacking DNS with ipfw
Message-ID:  <20000610002454.A13393@dialin-client.earthlink.net>
In-Reply-To: <Pine.GSO.4.21.0006100102450.4542-100000@shell.xecu.net>; from andy@xecu.net on Sat, Jun 10, 2000 at 01:23:38AM -0400
References:  <003301bfd299$61e21920$a3337218@purpledreams.com> <Pine.GSO.4.21.0006100102450.4542-100000@shell.xecu.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 10, 2000 at 01:23:38AM -0400, Andy Dills wrote:

[snip]

> You're quite possibly right; I've been agonizing over the description of
> fwd in `man ipfw`:
> 
> -===-
> fwd ipaddr[,port]
> 
> Change the next-hop on matching packets to ipaddr, which can be an IP
> address in dotted quad or a host name.  If ipaddr is not a
> directly-reachable address, the route as found in the local routing table
> for that IP is used in stead.  If ipaddr is a local address, then on a
> packet entering the system from a remote host it will be diverted to port
> on the local machine, keeping the local address of the socket set to the
> original IP address the packet was destined for.  This is intended for use
> with transparent proxy servers.  If the IP is not a local address then
> the port number (if specified) is ignored and the rule only applies to
> packets leaving the system. 
> 
> -===-
> 
> The way I understand that is:
> 
> 1) 10.0.0.1 requests DNS from 10.0.0.200
> 2) Via proxy arp, the packet gets sucked into the FreeBSD box. (I'm
> effectively proxy arping the entire internet...long story, but this part
> of the project is working flawlessly)

Looks good to here...

> 3) I fwd it to the localhost:53, and the source address of the reply is
> set to 10.0.0.200, and the dest address is set to 10.0.0.1.

OK, who would be doing this change of source address if there is
no NAT daemon?

> Am I incorrect? Maybe we'll have to wait for one of the ipfw developers to
> give some insight.

My rule of thumb has always been to remember that ipfw(8) never
actually changes the contents of a packet, it just changes where it 
gets piped to (except for some rare occasions). If any source address
changes were to be made in the response packets, it would have to be
named doing it, not ipfw(8).
-- 
Crist J. Clark                           cjclark@alum.mit.edu


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000610002454.A13393>