Sorry to disagree with Lynn, but the magic words here are "quite a while". This strongly suggests to me that an earlier guess, that the observed "failures" actually are DNS-based delays, is the right guess ... and that "quite a while" is around 3 minutes.

What to do about it?

First, maybe your mail server can be configured not to do reverse lookups. I'm not a qmail expert so can't help there.

Second, if you do not want your mail server to be able to do DNS lookups, then the router's response -- an icmp "port unreachable" response -- is a correct response. A slightly better response is to send a udp REJECT packet ... some clients recognize this but do not understand icmp port unreachable (dig through ancient archives for discussion of why LEAF routers normally leave port 113 open for the theory here). You would do this by adding a Shorewall rule to ACCEPT dport-53-udp traffic from the DMZ.

Third, if you do want your mail server to be able to resolve these reverse lookups ... where do you want it to do so? What DNS server (or orher mechanism) do you want to provide? Options (for these on-LAN lookups) are:

put the information in /etc/hosts on the DMZ machine (this may or may not work with qmail; MTAs are notorious for using ONLY DNS, not /etc/hosts, and I don't know about qmail in this regard)

run a DNS sever authoritative for the LAN on the LEAF router

run a DNS server authoritative for the LAN on the LEAF mail server

run a DNS server authoritative for the LAN on some LAN host, and let the DMZ server have access to it through the firewall (this is what I do here, running BIND on a full-strength-Linux LAN server).

From your comments below, it appears you are trying to do #2, using tinydns. If you want to do it that way, someone else will have to answe those questions, as I've never set up that package (on LEAF or any other host) ... as I recall, it has problems lsitening on multiple interfaces ... but I may be remembering wrong.

Sorry I cannot take you all the way to an answer, but with the problem identified as a DNS misconfiguration, surely someone else here knows the details you need to wrap this up.

At 09:32 PM 12/21/2003 -0500, Kory Krofft wrote:
Ray,

I was able to connect to the pop server using telnet it seemed to take quite a while to get a response but I was able to retreive and read the test message sent to lrpqmail.

>
>I don't know your setup well enough to tell you what is going on in
>the
>Shorewall DROP log, but since it involves ports 67 and 68, it has
>something
>to do with DHCP leases, not anything to do with POP3.

I was getting a lot of log entries from DHCP queries so I added the DROP to stop the logging of the rejects.

>
>Last thing ... the tcpdump output you sent indicates that after the
>POP3
>connection is initiated, the POP3 server is trying to do a reverse
>lookup
>on the source IP address. Several packets indicate  this, the first
>being --
>
>16:37:26.524013 192.168.10.1.59258 > 192.168.1.254.53:  28701+
>
>PTR? 1.10.168.192.in-addr.arpa. (43) (DF)
>
>The router responds with a "port unreachable" packet:
>
>16:37:29.547086 192.168.10.254 > 192.168.10.1: icmp:
>192.168.10.254 udp port 53 unreachable [tos 0xc0]
>
>This certainly indicates some sort of a configuration error, but not
>knowing the details of your setup, I can;t say what that error is.
>It does
>make me guess that the POP3 server does not reply, after the initial
>reply,
>because it cannot do a lookup on the IP address. Or ... a blue-sky
>thought
>here ... how long do you wait before giving up? DNS failures can, in
>some
>cases, cause delays of up  to 3 minutes in responses.
>
What would be the proper way for the router to reply to this reverse lookup?
/etc/hosts on the router looks like this:
127.0.0.1       localhost.kroffts.home localhost
192.168.1.254   markii
192.168.1.1     coventry.kroffts.home coventry
192.168.10.1    www.kroffts.com dmz kroffts_web

/etc/resolv.conf on router:
domain kroffts.home
nameserver 127.0.0.1
nameserver 192.168.1.254

/etc/hosts on dmz:
127.0.0.1       localhost
192.168.1.254   markii
192.168.10.1    kroffts_web.kroffts.com kroffts_web mail.kroffts.com
191.168.1.1     coventry.kroffts.home   coventry


/etc/resolv.conf on dmz: domain kroffts.com nameserver 127.0.0.1 nameserver 192.168.1.254 nameserver 192.168.10.254

What can you tell me about The /etc/tinydns-private/root/data file from the router? Does this look correct?

kroffts.home::localhost
1.168.192.in-addr.arpa::localhost
+markii.kroffts.home:192.168.1.254    <the router>
=mail.kroffts.com:192.168.10.1          <the dmz host>

I am not running any DNS daemons on the dmz. Should I be? I had wanted to use DHCP to configure the DMZ host but I could not get it to work on two separate networks. I know it should, but it didn't so I set up the eth0 on the dmz host as static.
from the /etc/network/interfaces file on the dmz host:


auto eth0
iface eth0 inet static
        address 192.168.10.1
        masklen 24
        broadcast 192.168.10.255
        gateway   192.168.10.254

Thanks again,

Kory




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to