From owner-freebsd-hackers Sun Feb 1 18:58:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA19707 for hackers-outgoing; Sun, 1 Feb 1998 18:58:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19569 for ; Sun, 1 Feb 1998 18:56:55 -0800 (PST) (envelope-from rivers@dignus.com) Received: from ponds.dignus.com (ponds.vnet.net [166.82.177.48]) by elvis.vnet.net (8.8.8/8.8.4) with ESMTP id VAA16774 for ; Sun, 1 Feb 1998 21:57:59 -0500 (EST) Received: from lakes.dignus.com (lakes [10.0.0.3]) by ponds.dignus.com (8.8.5/8.8.5) with ESMTP id WAA04280 for ; Sun, 1 Feb 1998 22:17:22 -0500 (EST) Received: (from rivers@localhost) by lakes.dignus.com (8.8.7/8.6.9) id WAA02139 for freebsd-hackers@freefall.cdrom.com; Sun, 1 Feb 1998 22:01:27 -0500 (EST) Date: Sun, 1 Feb 1998 22:01:27 -0500 (EST) From: Thomas David Rivers Message-Id: <199802020301.WAA02139@lakes.dignus.com> To: freebsd-hackers@freefall.FreeBSD.org Subject: natd "strangness".. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe hackers" Ok - I just want to mention a natd issue I seem to have tripped over; perhaps it's corrected in a newer version. First - this is a 2.2.5-RELEASE setup - everything's just straight 2.2.5-RELEASE> Here's the situation: _________ +----------+ +--------+ / \ | lakes |---- (ether) ---- | ponds |=== (modem) == | Internet | +----------+ +--------+ \ / --------- lakes is 10.0.0.3 (ether net) ponds is 10.0.0.1 (ether net) ponds is 166.82.100.202 (Slip to my ISP.) So, as you can imagine - I'm running natd on 'ponds' to be able to connect from the internal network to the internet-at-large. Now, if I start up netscape on 'ponds' (with the DISPLAY pointing back to 'lakes') - things work fine, since 'ponds' is on the internet. But - if I start up netscape on 'lakes' - things _mostly_ work fine. It seems, however, that large requests can get bogged down, or not get through at all (as if some packet reconstruction was messing up natd.) I've done this by running netscape on both machines, pointing to the same sight. The netscape running on 'ponds' will get to the site just fine, while the one on 'lakes' will bail out after some time indicating the server wasn't working... this is especially true for something like, an audio stream for example. The symptom is that a large "something" (graphics, audio, etc....) takes much longer, or is even impossible to receive, on 'lakes' - while it works just fine on 'ponds'... at exactly the same time. About the only thing I can imagine going on here is natd... And, I'm guessing it has to do with piggy-back'd ACKs or perhaps some other packet issues... Any thoughts? Does anyone have suggestions as to what I could check? Just for info - here's my rc.firewall rules. They are someone complicated, the rules for sl1 are to handle a situation where I'm connected to work (which uses it's own internal IP numbers). The rule via sl0 at the end is to handle connecting to the "internet-at-large". Could there be some interaction(s) here? ipfw -f flush ipfw -f add 10 divert 32001 ip from any to 192.42.243.0/24 via sl1 ipfw -f add 11 divert 32001 ip from 192.42.243.0/24 to any via sl1 ipfw -f add 12 divert 32001 ip from 149.173.0.0/16 to any via sl1 ipfw -f add 13 divert 32001 ip from any to 149.173.0.0/16 via sl1 ipfw -f add 14 divert 32001 ip from 10.23.0.0/16 to any via sl1 ipfw -f add 15 divert 32001 ip from any to 10.23.0.0/16 via sl1 ipfw -f add 16 divert 32001 ip from 10.253.0.0/16 to any via sl1 ipfw -f add 17 divert 32001 ip from any to 10.253.0.0/16 via sl1 ipfw -f add 20 divert 32000 ip from any to any via sl0 ipfw -f add pass ip from any to any - Thanks - - Dave Rivers -