From owner-freebsd-questions Sun Dec 29 6:45:48 2002 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD69137B401 for ; Sun, 29 Dec 2002 06:45:44 -0800 (PST) Received: from smtp.infracaninophile.co.uk (ns0.infracaninophile.co.uk [81.2.69.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E5F543E4A for ; Sun, 29 Dec 2002 06:45:43 -0800 (PST) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost.infracaninophile.co.uk [IPv6:::1]) by smtp.infracaninophile.co.uk (8.12.6/8.12.6) with ESMTP id gBTEjb9Y053999 for ; Sun, 29 Dec 2002 14:45:37 GMT (envelope-from matthew@happy-idiot-talk.infracaninophile.co.uk) Received: (from matthew@localhost) by happy-idiot-talk.infracaninophile.co.uk (8.12.6/8.12.6/Submit) id gBTEjWMJ053998 for freebsd-questions@FreeBSD.ORG; Sun, 29 Dec 2002 14:45:32 GMT Date: Sun, 29 Dec 2002 14:45:32 +0000 From: Matthew Seaman To: freebsd-questions@FreeBSD.ORG Subject: Re: Firewall Forwarding Syntax Message-ID: <20021229144531.GA53817@happy-idiot-talk.infracaninophi> Mail-Followup-To: Matthew Seaman , freebsd-questions@FreeBSD.ORG References: <3.0.5.32.20021228110912.012ed640@mail.sage-one.net> <3.0.5.32.20021228110912.012ed640@mail.sage-one.net> <3.0.5.32.20021228141220.0125d188@mail.sage-one.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3.0.5.32.20021228141220.0125d188@mail.sage-one.net> User-Agent: Mutt/1.5.1i X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 28, 2002 at 02:12:20PM -0600, Jack L. Stone wrote: > > I want the packets to remain intact, but delivered correctly. I'm not even > sure if this is the right direction to take to solve the problem. Perhaps > an explanation of the delimma: > > I have a FBSD gateway (with NAT & caching DNS) on a server and the public > interface identifies incoming packets and routes them to the proper machine > using IP aliases in the interface -- fairly typical I suppose as per > example as follows, with rl0 as the internal and rl1 as external interfaces: > > ifconfig_rl0="inet 192.168.0.1 netmask 0xffffff00" > ifconfig_rl1="inet 123.45.678.001 netmask 255.255.255.248" > ifconfig_rl1_alias0="inet 123.45.678.002 netmask 255.255.255.255" > ifconfig_rl1_alias1="inet 123.45.678.003 netmask 255.255.255.255" > etc, etc..... > > Then, I use NAT to do redirect from above external IPs to machines on > private network. > -redirect_address 192.168.0.7 123.45.678.002 > -redirect_address 192.168.0.5 123.45.678.003 > etc, etc..... > > PROBLEM: > Any emails sent (via Sendmail) out of machine 192.168.0.5 leaves and goes > to the gateway, resolves itself as 123.45.678.003 just fine and goes OUT > for delivery. BUT, the gateway machine (or any other machine on the private > network) cannot find its way to that machine fro deliver of emails. Any > mails coming from the outside enteres the gateway and is sent to the > machine 123.45.678.003/192.168.0.5 just fine... just not from within the > LAN.... they must know also know the 192.168.0.5 IP to get there. The above > -redirects does not do it for INTERNAL emails. This is only a problem where > copies of emails sent OUT contain copies to go BACK to internal machines -- > such as majordomo mail lists. > > To try to make it simpler, any mails that leave an internal machine must go > to the default gateway, 192.168.0.1 and then gets confused and cannot find > its way back to that same machine to deliver copies of emails. OK. I think that the best approach to this is not to think of it as a sendmail or an ipfw problem, but as a DNS problem. Your problem, in a nutshell, is that hosts inside your network (including your gateway machine) need to contact your mail (or whatever) server directly on your private network, i.e. at 192.168.0.7, whereas hosts outside your network need to connect to the nat'ed alias address 123.45.67.2 on your gateway machine. So the simple answer to your troubles is to set up your DNS so that on an internal machine, looking up your mail server in the DNS gets a response like: % host smtp.example.com smtp.example.com has address 192.168.0.7 smtp.example.com mail is handled (pri=10) by smtp.example.com and from anywhere else in the world, the response looks like: % host smtp.example.com smtp.example.com has address 123.45.67.2 smtp.example.com mail is handled (pri=10) by smtp.example.com Now, one way you might do that is just to use a separate DNS box for internal clients, which contains a set of zone files for the example.com domain with the internal numbers, and set up resolv.conf on all your internal machines to point to it. However, you've already got a perfectly good DNS server and I'm sure you don't want the hassle of maintaining two machines where one would do. That's alright, but you will need to install BIND 9 from ports, which is fully capable of presenting a different view of the network depending on where the question comes from. So in your named.conf on your authoritative server you would have something like this: acl internalnet { 192.168.0.0/24; } options { [...] } view "private" in { match-clients { internalnet; }; zone "." in { type hint; file "named.root"; }; zone "example.com" in { type master; file "internal/example.com.db"; }; zone "0.168.192.in-addr.arpa" in { type master; file "internal/0.168.192.in-addr.arpa.db"; }; zone "0.0.127.in-addr.arpa" in { [...] }; } // view "private" view "public" in { match-clients { any; }; zone "." in { type hint; file "named.root"; }; zone "example.com" in { type master; file "external/example.com.db"; }; zone "67.45.123.in-addr.arpa" in { type master; file "external/67.45.123.in-addr.arpa.db"; }; }; // view "public" Note that if you use views at all in your named.conf, all zone statements must occur inside a view statement. See the BIND documentation the port installs in ${PREFIX}/share/doc/bind9/arm/ or on the net at http://www.nominum.com/content/documents/bind9arm.pdf Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message