Date: Sun, 29 Dec 2002 08:57:41 -0600 From: "Jack L. Stone" <jackstone@sage-one.net> To: Matthew Seaman <m.seaman@infracaninophile.co.uk>, freebsd-questions@FreeBSD.ORG Subject: Re: Firewall Forwarding Syntax Message-ID: <3.0.5.32.20021229085741.0118b548@mail.sage-one.net> In-Reply-To: <20021229144531.GA53817@happy-idiot-talk.infracaninophi> References: <3.0.5.32.20021228141220.0125d188@mail.sage-one.net> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
At 02:45 PM 12.29.2002 +0000, Matthew Seaman wrote:
>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
>
Thanks for going to all this trouble, Matthew. I had a "gut" feeling it was
going to be the DNS. Now, I've just got to decide whether to go BIND9 or
add another DNS service on one of the other machines.... and make it work.
Happy New Year!
Best regards,
Jack L. Stone,
Administrator
SageOne Net
http://www.sage-one.net
jackstone@sage-one.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.5.32.20021229085741.0118b548>