Date: Tue, 09 Mar 1999 11:10:30 -0800 From: Julian Elischer <julian@whistle.com> To: Terry Glanfield <terry@ppsl.demon.co.uk> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Tunnel loopback Message-ID: <36E57226.15FB7483@whistle.com> References: <9903091652.AA04146@ppsl.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36E57226.15FB7483>