From owner-freebsd-doc@FreeBSD.ORG Tue Sep 21 17:11:50 2010 Return-Path: Delivered-To: freebsd-doc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2C7A106566B for ; Tue, 21 Sep 2010 17:11:50 +0000 (UTC) (envelope-from Jeremy.Spring@us.lawson.com) Received: from TX2EHSOBE010.bigfish.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by mx1.freebsd.org (Postfix) with ESMTP id 642A38FC16 for ; Tue, 21 Sep 2010 17:11:50 +0000 (UTC) Received: from mail164-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 8.1.340.0; Tue, 21 Sep 2010 16:56:45 +0000 Received: from mail164-tx2 (localhost.localdomain [127.0.0.1]) by mail164-tx2-R.bigfish.com (Postfix) with ESMTP id A627DD08313 for ; Tue, 21 Sep 2010 16:56:45 +0000 (UTC) X-SpamScore: -30 X-BigFish: VPS-30(zz542N1432N1447R9371Pzz1202hzz8275bh8275dhz2dh2a8h) Received: from mail164-tx2 (localhost.localdomain [127.0.0.1]) by mail164-tx2 (MessageSwitch) id 1285088205413175_1716; Tue, 21 Sep 2010 16:56:45 +0000 (UTC) Received: from TX2EHSMHS041.bigfish.com (unknown [10.9.14.243]) by mail164-tx2.bigfish.com (Postfix) with ESMTP id 5F9B31208050 for ; Tue, 21 Sep 2010 16:56:45 +0000 (UTC) Received: from USSPW044.corpnet.lawson.com (208.92.249.34) by TX2EHSMHS041.bigfish.com (10.9.99.141) with Microsoft SMTP Server (TLS) id 14.0.482.44; Tue, 21 Sep 2010 16:56:43 +0000 Received: from xchgm01.corpnet.lawson.com ([fe80::c903:b967:a3f7:aabd]) by USSPW044.corpnet.lawson.com ([::1]) with mapi; Tue, 21 Sep 2010 11:56:43 -0500 From: "Spring, Jeremy" To: "freebsd-doc@freebsd.org" Date: Tue, 21 Sep 2010 11:56:40 -0500 Thread-Topic: doc correction Thread-Index: ActZrW4o5w7wdedYRQGgwfu3qyKHegAAEbsA Message-ID: <538D6120D2245A4DB61D6A0556AD05CD1AC8130B@XCHGM01.corpnet.lawson.com> References: <538D6120D2245A4DB61D6A0556AD05CD1AC80AEA@XCHGM01.corpnet.lawson.com> <44mxrbujhi.fsf@be-well.ilk.org> In-Reply-To: <44mxrbujhi.fsf@be-well.ilk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Reverse-DNS: mail.lawson.com Subject: RE: doc correction X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 17:11:50 -0000 Thanks for the reply. I recently found out that packet filtering (pf) was = also enabled on this machine at the same time I was trying to setup nat / i= pfw. I haven't used pf before and am not sure how it would affect a natd /= ipfw setup. Maybe it would be ok to throw this issue out. -----Original Message----- From: Lowell Gilbert [mailto:lgusenet@be-well.ilk.org]=20 Sent: Tuesday, September 21, 2010 11:53 AM To: Spring, Jeremy Cc: freebsd-doc@freebsd.org Subject: Re: doc correction Jeremy.Spring@us.lawson.com (Spring, Jeremy) writes: > I setup nat translation and port forwarding on my FreeBSD 8.1-RELEASE mac= hine. It took me a while to get this working because I had to find out by = trial and error that the interface to forward packets through is NOT the in= terface connected to the Internet as the documentation suggests, but rather= , is the interface connected to my private network. > > My final nat command string is: > /sbin/natd -redirect_port tcp 10.13.55.4:3389 3389 -n em1 > > where em0 is connected to the Internet, em1 is connected to my private ne= twork, and I want to forward incoming RDP traffic destined for my public fa= cing IP to 10.13.55.4. The documentation suggests that I should be using m= y Internet facing interface (em0), but this doesn't work. The documentatio= n I am looking at is at http://www.freebsd.org/doc/en_US.ISO8859-1/books/ha= ndbook/network-natd.html. Please let me know if you have any questions. No, normally one *would* run natd on the external interface. It shouldn't matter a whole lot in the common case of a single internal and a single external interface, but if you get more interfaces inside, you really want to have them handled by the same process. I don't currently have any redirect_port options to play with, but my tech-support crystal ball tells me that the problem was probably with how you got the packets chosen to go into natd in the first place.