From owner-freebsd-hackers  Tue Mar  9 11:21:27 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
	by hub.freebsd.org (Postfix) with ESMTP id 6EB3A14F82
	for <freebsd-hackers@FreeBSD.ORG>; Tue,  9 Mar 1999 11:21:15 -0800 (PST)
	(envelope-from julian@whistle.com)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id LAA13520;
	Tue, 9 Mar 1999 11:10:54 -0800 (PST)
Received: from current1.whistle.com(207.76.205.22)
 via SMTP by alpo.whistle.com, id smtpdA13501; Tue Mar  9 19:10:40 1999
Message-ID: <36E57226.15FB7483@whistle.com>
Date: Tue, 09 Mar 1999 11:10:30 -0800
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.8-RELEASE i386)
MIME-Version: 1.0
To: Terry Glanfield <terry@ppsl.demon.co.uk>
Cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: Tunnel loopback
References: <9903091652.AA04146@ppsl.demon.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Terry Glanfield wrote:
> 
> Hi,
> 
> I've been trying to use a FreeBSD (3.0-RELEASE and 3.1-RELEASE) tunnel
> device (/dev/tunN) to push packets back onto the IP stack[1] with some
> success.  Firstly I redirect all packets on one interface (ed0) to
> the tunnel using IPFilter:
> 
>         pass in quick on ed0 to tun0 all
> 
> Then with a simple read/write loop attached to /dev/tun0 I can bounce
> all packets back in again.  This works up to a point.
> 
> I'm finding that a single icmp packet send into tun0 results in
> thousands of packets entering my read/write loop before one packet
> finally finds its way out again.  If I insert a short sleep between
> the read and write calls the number of packets are reduced but the
> overall time taken remains constant (~1 second).  Hacking the loopback
> into the kernel (if_tun.c) results in a similar time scale but
> hundreds of thousands of packets being bounced around.
> 
> I get the feeling I'm missing something obvious.  Short-term state
> information or optimisations maybe?  Any pointers would be much
> appreciated.
> 
> Regards,
> Terry.


You might find that using ipfw and divert sockets is a much more natural
fit to this problem.

Divert sockets can be used instead of or in conjunction with the tun
device.

> 
> [1] The idea is to mix NAT and SKIP on the same box by doing the SKIP
> encryption on a different interface before it hits NAT.
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message


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