From owner-freebsd-questions Mon Sep 1 04:49:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA21752 for questions-outgoing; Mon, 1 Sep 1997 04:49:03 -0700 (PDT) Received: from groa.uct.ac.za (groa.uct.ac.za [137.158.128.7]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA21708 for ; Mon, 1 Sep 1997 04:48:33 -0700 (PDT) Received: from rv by groa.uct.ac.za with local (Exim 1.70 #1) id 0x5UxG-0002ZI-00; Mon, 1 Sep 1997 13:47:38 +0200 Subject: Re: Problem with packet alias/natd To: brian@awfulhak.org (Brian Somers) Date: Mon, 1 Sep 1997 13:47:37 +0200 (SAT) Cc: freebsd-questions@freebsd.org In-Reply-To: <199708312039.VAA06045@awfulhak.demon.co.uk> from "Brian Somers" at Aug 31, 97 09:39:51 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Message-Id: From: Russell Vincent Sender: owner-freebsd-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Brian Somers wrote: > When the machine on the private network gets the connection, it sends > stuff back to the real public-network machine, routing through the > gateway. The gateway un-alters the packet so that the public machine > sees it as a connection to the gateway box. Ok, I am getting closer to understanding the fundamentals of natd (I think I am going to have to write something for the handbook if I ever get this working). :-) I have been thinking the other way around. I have a machine on the private/internal network wishing to access the public network. i.e: The connection is initiated the opposite to what you mention. > Your setup is with three machines on the same network. Because (as > you've pointed out) the receiving machine (137.158.128.7) knows how > to get back to the sending machine, and does so without going through > the gateway, the sending machine will just drop all of the reply > packets as being garbage. The real situation is a little more complex, but I was using that example as a simpler test. My ultimate aim is to setup a proxy configuration to, but I am learning with "simpler" stuff. I did configure the receiving machine's (137.158.128.7) arp/routing table to forward the packets back to the natd machine (and it was getting them). Here is a trace: ipfw: 00080 divert 8888 tcp from 137.158.128.114 to any 23 00082 divert 8888 tcp from 137.158.128.7 23 to any natd: # natd -v -p 8888 -n de0 -redirect_address 137.158.128.7 0.0.0.0 In [TCP] 137.158.128.114:1575 -> 137.158.128.10:23 aliased to 137.158.128.114:1575 -> 137.158.128.7:23 In [TCP] 137.158.128.7:23 -> 137.158.128.114:1575 aliased to 137.158.128.7:23 -> 137.158.128.114:1575 tcpdump on natd machine: # tcpdump -qn port telnet 13:10:29.349921 137.158.128.114.1575 > 137.158.128.10.23: tcp 0 13:10:29.356520 137.158.128.114.1575 > 137.158.128.7.23: tcp 0 13:10:29.357198 137.158.128.7.23 > 137.158.128.114.1575: tcp 0 (DF) 13:10:29.357774 137.158.128.7.23 > 137.158.128.114.1575: tcp 0 (DF) i.e: natd doesn't seem to be mapping the address back again. Perhaps I need to play with the in/out ports in natd? > The only way you'll get this setup to work is to put the source and > destination machines on different networks with the natd machine on a > gateway in between. I will give that a go, just to get something working - that will give me a baseline from which to customise, although I did hack around a little without much luck. I know a little more now, though. :-) > I'll bet (at a guess) that this isn't going to suit :( Not really, but I can live with it. My first requirement is to setup a proxy archie server (there will be others, so I want something generic). A machine with a single interface and outside the firewall will act as the proxy, re-addressing packets as if it is sending them out and fixing the return packets. i.e: Point your archie client at this machine and it will forward your request to the real server and send the results back. > A simpler solution is to disable port 23 on the 137.158.128.10 machine > in inetd.conf, and write your own program that listens on port 23 and > does smart things based on the source address (ie, spawns a child > that opens a connection to 137.158.128.7 and does the select/read/ > write bit between the two), or just spawns a telnetd. That is another option, although I am just confused as to why my test doesn't work. Perhaps I am just under the impression that natd can do more than it really can. I was using natd's 'alias address' assuming it would use that as the source address for outgoing packets, but it seems not. :-( Does someone have a working natd configuration that they don't mind sending me to modify as a baseline to start with? Thanks for the info. -Russell