From owner-freebsd-hackers Sat Jan 25 17:06:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA05450 for hackers-outgoing; Sat, 25 Jan 1997 17:06:37 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA05435 for ; Sat, 25 Jan 1997 17:06:31 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.coverform.lan [127.0.0.1]) by awfulhak.demon.co.uk (8.8.4/8.7.3) with ESMTP id SAA11494; Sat, 25 Jan 1997 18:42:21 GMT Message-Id: <199701251842.SAA11494@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: Archie Cobbs Cc: hackers@freebsd.org, ari.suutari@ps.carel.fi, cmott@srv.net Subject: Re: ipdivert & masqd In-reply-to: Your message of "Thu, 23 Jan 1997 23:59:50 PST." <199701240759.XAA01349@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Jan 1997 18:42:20 +0000 From: Brian Somers Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [stuff about ping turnarounds not being diverted deleted] > > Brian, > Can I take it from you recent email to the hackers list that > you solved the problem? > > -Archie Nope - as Ari Suutari wrote to me and said: Hi, About two sockets - you might also need them. My first version used also only one socket, but there were some cases where kernel packet filtering loop avoidance code was confused when incoming and outgoing packets were put into same socket. The result was that some packets were not diverted which in turn resulted in connection failures. With separate sockets for incoming and outgoing packets everything works fine. The idea in natd is that user makes modifications in /etc/rc.firewall to set it up. The test script is only for testing - you are not expected to use it for anything else. (perhaps I should mention this in README file). Both these main programs are very much alike for obvious reasons: all the brains is in the code written by Charles. Ari S. On investigation, he's correct. Tcp & udp return setup packets coming into the machine with masqd running seem to disappear - masqd sees them, but when it injects them back into the divert socket they disappear (the app never sees them). This shows itself when you try to initiate a tcp/udp connection through the divert sockets from the machine running masqd.... a timeout occurs. However, machines that are having packets forwarded through the masqd machine are fine. I'll have a look at the divert code and see if I can come up with anything interresting. running masqd are -- Brian , Don't _EVER_ lose your sense of humour....