From owner-freebsd-hackers Fri Jan 19 21:28: 1 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from arachna.com (dnai-216-15-61-88.cust.dnai.com [216.15.61.88]) by hub.freebsd.org (Postfix) with SMTP id 530E737B401 for ; Fri, 19 Jan 2001 21:27:43 -0800 (PST) Received: (qmail 11966 invoked by uid 1001); 20 Jan 2001 05:32:24 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Jan 2001 05:32:24 -0000 Date: Fri, 19 Jan 2001 21:32:23 -0800 (PST) From: Ian Kallen To: Nick Rogness Cc: freebsd-hackers@freebsd.org Subject: Re: accessing an outside IP from inside a NAT net In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, I've been fiddling with the ipfw syntax, I thought this would do it /sbin/ipfw add divert 80 all from 10.0.0.128/25 to 206.169.18.10 via ep0 but that ain't it. 10.0.0.128/25 has servers, 10.0.0.0/25 has clients, both gateways 10.0.0.1 and 10.0.0.129 run off ep0... yes, I've been reading the ipfw man page and the archives, yet even though the two nets can access each other directly, I haven't been able to get the clients to access any server resources via the 206.169.18.10 nat. Further suggestions? thanks, -Ian -- Ian Kallen | AIM: iankallen | efax: (415) 354-3326 On Fri, 19 Jan 2001, Nick Rogness wrote: > On Fri, 19 Jan 2001, Ian Kallen wrote: > > > > > I'd like a hand figuring out how to access resources on the internal side > > of a NAT net from within it without doing something kludgey with DNS. > > i.e. suppose I run natd with a configuration like this: > > > > # begin /etc/natd.conf > > use_sockets > > same_ports > > port 8668 > > deny_incoming no > > log > > redirect_port tcp 10.0.0.128:80 206.169.18.10:80 > > # end /etc/natd.conf > > > > Now if the DNS for the web server www.foo.com running on 10.0.0.128 > > directs a browser on the 10.0.0.0 net to 206.169.18.10, it doesn't get > > routed back to 10.0.0.128; it just hangs (I'm acutally not sure what's > > happening there, the connction never succeeds). Is there a nice way to > > handle this case without running a dummy DNS just for the 10.0.0.0 > > internal net? > > > Run a firewall rule for diverting packets on your inside > interface for that web server. > > > Nick Rogness > - Drive defensively. Buy a tank. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message