From owner-freebsd-ipfw Sun Sep 29 23:39:34 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EFF237B401 for ; Sun, 29 Sep 2002 23:39:32 -0700 (PDT) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EE9943E65 for ; Sun, 29 Sep 2002 23:39:31 -0700 (PDT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.12.6/8.12.6) with ESMTP id g8U6dTOp001255; Sun, 29 Sep 2002 23:39:29 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.12.6/8.12.6/Submit) id g8U6dTFf001254; Sun, 29 Sep 2002 23:39:29 -0700 (PDT) (envelope-from david) Date: Sun, 29 Sep 2002 23:39:29 -0700 (PDT) From: David Wolfskill Message-Id: <200209300639.g8U6dTFf001254@bunrab.catwhisker.org> To: freebsd-ipfw@freebsd.org Subject: Weird problem with ipfw (possibly natd/libalias, but I doubt it) Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Appropriate redirection strongly encouraged; please keep my address on recipient headers, as I'm not currently subscribed to -ipfw@. As is my custom on alternate Sundays, I updated an internal server and our firewall to today's -STABLE. (I track -STABLE daily on my laptop, so I have some idea what I'm getting into.) For the first time since I started this schedule -- over a year ago -- I needed to fall back to -STABLE from 15 Sep. (only on the firewall, though). What happened is that a specialized application that my spouse uses -- and has been using without incident for several months -- failed its (internal) authentication when she tried to connect when the firewall was running today's -STABLE. I rebooted the firewall from the alternate boot slice (as fallback), and now it works. I have a packet capture of each of a working and failing session. Of course, some of the differences are because of different timestamps, and the protocol is proprietary (and coyright by the service she's using). I have a single static IP address (residential Pac*Bell DSL, from back when static IP addresses were what they assigned). I generally allow traffic that is initiated from within; for TCP traffic, I use the "established" flag, and for UDP traffic, I use dynamic rules. The traffic in question appears to all be TCP. I set up each of the machines in question with 3 slices: * 1 has a / and /usr * 2 has a / and /usr * 3 has /var In this case, I had been running off of slice 2, so I used newfs/dump/restore to copy ad0s2{a,e} to ad0s1{a,e} (respectively), then changed /etc/fstab on ad0s1a so that / was ad0s1a and /usr was ad0s1e. I then rebooted the box and verified that things were generally (still) working. I then mounted /usr/src and /usr/obj from my build machine and did the * make installkernel * make installworld * mergemaster * reboot (after having done the full upgrade on the build machine, followed by a "make buildkernel" for each machine's kernel). This is the process I've been using for these machines for over a year (and I've done similar things before that). No problems were encountered during the process for either machine, and all other applications of which I know worked just fine -- including Web browsing, IRC, mail (I run my own SMTP server), DNS... Note, in particular, that the ipfw rules were copied, and that no changes were made to them (or to the natd configuration, for that matter). And I thought we were in code freeze.... :-{ Suggestions for identifying the nature of the problem would be heartily welcomed, though my ability to actually test the effects of the changes will be reduced, as I'm unwilling to lose domestic tranquility by causing unnecessary disruption. Thanks, david -- David H. Wolfskill david@catwhisker.org To paraphrase David Hilbert, there can be no conflicts between the discipline of systems administration and Microsoft, since they have nothing in common. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message