From owner-freebsd-stable Wed Dec 8 14: 5: 5 1999 Delivered-To: freebsd-stable@freebsd.org Received: from nisser.com (c1870039.telekabel.chello.nl [212.187.0.39]) by hub.freebsd.org (Postfix) with ESMTP id ECD8614C1D for ; Wed, 8 Dec 1999 14:04:58 -0800 (PST) (envelope-from roelof@nisser.com) Received: from nisser.com (roelof [10.0.0.2]) by nisser.com (8.9.3/8.9.2) with ESMTP id XAA03998; Wed, 8 Dec 1999 23:04:52 +0100 (CET) (envelope-from roelof@nisser.com) Message-ID: <384ED624.5EA4E41D@nisser.com> Date: Wed, 08 Dec 1999 23:05:24 +0100 From: Roelof Osinga Organization: eboa - engineering buro Office Automation X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mw@freibergnet.de Cc: FreeBSD Stable Subject: Re: ifpw forwarding problem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Martin Welk wrote: > > Your problem is, that forwarding packets by rules to other hosts is not > the same as forwarding packets to hosts through a NAT environment. Look > at the natd man page, search for the redirect options mentioned there. Thanks. I did do that, but for testing purposes I tried to redirect it through the other NIC as well. The natd has been told to listen only on the ep1 NIC. > In my case, there's a FreeBSD machine doing NAT here. It has two IP > addresses on the outer world interface, but this shouldn't be a > significant difference. Actually it is identical to what I have. > I have a file named natd.conf that's loaded on startup doing a > "natd -f natd.conf" - you may put it somewhere in the file system > where you like it and use the absolute path, I've chosen /etc. Dito. > use_sockets > same_ports > port 8668 > deny_incoming no > alias_address aaa.aaa.aaa.aaa > redirect_port tcp bbb.bbb.bbb.bbb:5900 aaa.aaa.aaa.aaa:5900 Second thing I tried, but with the difference that I rely on "deny incoming no" to be the default. In my case though I would probably should be using proxy_rule with type encode_ip_hdr since it's intended for webtraffic. It would be nice to know where the hits are coming from. > In this case, the port 5900 (which is by default used for a first VNC > session) is redirected to an interal Windows box that can be accessed > this way. That's why I explicitly drop them . > aaa.aaa.aaa.aaa is the external network address of the router, > bbb.bbb.bbb.bbb the internal host (192.168...) Funny in that I did try with nisser:/home/www/Slak$ cat /etc/natd.conf # as used in rc.conf.local -use_sockets -same_ports #-redirect_port tcp 212.187.0.39:8080 10.0.0.3:80 redirection enabled. It didn't work when accessing that IP address from within. Which is why I tried the internal NIC. > You need to do that this way in a NAT'ed environment because someone > has to change the IP addresses as they are needed to make it work > properly. Yeah, but this is the internal NIC . > For the ipfw setup, a directive like > ... Same as the one I listed. > But if it works in this case, you have now a good starting point to > do more :-) Alas it did not work in my case. However, that was with IPFIREWALL_FORWARD enabled. Turned out that made my system quit unstable, or rather erratic. After a couple of hours I switched back to the previous kernel. Didn't matter whether or not I had redirection rules active either for ipfw or natd. So maybe that is why natd redirection failed. Don't know, can't try yet since it's a live system. Which reminds me, do you happen to know if natd responds to HUP? The manpage doesn't mention it. > No RTFM intended, but I found the following man pages very helpful when > I started with ipfw/natd and so on: divert(4), dummynet(4), ipfw(8), > ipfirewall(4). Although dummynet has to do with bandwidth limiting > and delaying (this is integrated into the IPFW functionality), it gives > some further information that helps to understand how packets pass > through the firewall. All of which I've read one time or another. Most multiple times . Anyway, since my rules mimick your (barring the "deny_incoming no") and yours do work, I know at least it's not the rules. The natd rules, that is. I'll try with the kernel as is at the next opportunity. Thanks. Roelof -- Home is where the (@) http://eboa.com/ is. Telekabel home http://nisser.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message