[afnog] PIX Configuration Issue

[Brian Candler]

On Thursday 23 June 2005 13:05, Julius Kidubuka wrote:
> With this thought in mind, I decided to perform a couple of tests as shown
> below:

Good thinking.

> mail# telnet mail.molg.go.ug 25
> Trying 81.199.29.54...
> Connected to mail.molg.go.ug.
> Escape character is '^]'.
> 220 mail.molg.go.ug ESMTP Sendmail 8.11.3/8.11.3/SuSE Linux 8.11.1-0.5;
> Thu, 23 Jun 2005 01:50:12 +0300
> ehlo me
> 250-mail.molg.go.ug Hello mail.domain-name [x.x.x.x], pleased to meet you
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250-SIZE
> 250-DSN
> 250-ONEX
> 250-XUSR
> 250 HELP
> mail from:<juki at molg.go.ug>
> 250 2.1.0 <juki at molg.go.ug>... Sender ok
> rcpt to:<juki at one2net.co.ug>
> 550 5.7.1 <juki at one2net.co.ug>... Relaying denied
> quit
> 221 2.0.0 mail.molg.go.ug closing connection
> Connection closed by foreign host.

OK. Firstly, is "mail.molg.go.ug" the machine in your DMZ? I don't have your 
previous message to hand at the moment, but is 81.199.29.54 NATted to 
192.168.0.5 in your outside router?

Secondly, what domain are the mailboxes in? Judging by your POP3 session, it's 
"molg.go.ug". Therefore, to deliver mail to this mailbox, you need:

MAIL FROM:<juki at one2net.co.ug>      <-- the sender address (or just <>)
RCPT TO:<juki at molg.go.ug>           <-- the recipient address
DATA
Subject: test

hello world!
.

What you did was the other way round: you connected from outside your network 
(presumably), and tried to submit a mail whose destination was also outside 
your network. Your machine was correct to reject in this case; if it didn't, 
it would be an open relay, and anyone could connect and relay spam through 
it.

In general, a mail server like this should be configured:
1. To deliver mail from anyone TO user at molg.go.ug   (incoming delivery)
2. To deliver mail FROM 192.168.x.x TO anyone       (outgoing relaying)
and to reject anything else.

> From the tests above, it is clearly evident that the mail server is
> reachable from the outside via both ports, that is, 110 and 25. This then
> raises one question, where is all the mail that I have sent to the
> juki at molg.go.ug account being delivered?

Well, a good place to start is your mail logs:

    # tail -f /var/log/maillog

And then, from another machine, send a message to juki at molg.go.ug. You should 
see log messages appended. ^C to stop the 'tail' process.

If this is a default sendmail configuration, then I would guess it is 
delivering to /var/spool/mail/juki or /var/mail/juki. Try looking at this 
file:

    # cat /var/spool/mail/juki

If the mail *is* being delivered there, then the problem is that your pop3 
server is looking in a different location for the mailbox contents. This 
means looking at the pop3 server manpages or other documentation; I don't use 
qpopper.

> >> When I do try to send mail to say, juki at one2net.co.ug, I get the error
> >> message as below:
> >>
> >> 'juki at one2net.co.ug' on 6/22/2005 12:55pm
> >> 550 5.7.1 <juki at one2net.co.ug>... Relay denied. IP name lookup failed
> >> [192.168.0.55]
> >
> > OK, that's a pretty clear error from your MTA.
> >
> > - the client connected to the MTA
> > - the source IP address of the client is 192.168.0.55 (after being
> > NATted) - the MTA is configured so that the client IP address *must* have
> > reverse DNS, otherwise sending is denied
>
> Reverse DNS... how do I go about this then?

Unfortunately, you cannot set up reverse DNS for private IP addresses 
(including 192.168.x.x), unless:
1. you run your own caching DNS server
2. your clients point to this caching DNS server, rather than (say) one at 
your ISP
3. you then configure your DNS cache as authoritative for 168.192.in-addr.arpa 
and insert PTR records for your reverse DNS

It would be better if you could use public IPs in your DMZ, but you say you 
don't have sufficient IP space available.

Failing that, you need to configure your MTA *not* to do reverse DNS lookups 
on incoming connections. Sendmail is a total pig to configure. I can't help 
you with configuring such ancient and broken software; you may have to find a 
sendmail mailing list and ask there.

> > 1. Try putting
> >
> > 192.168.0.55	pc55.localdomain
> >
> > in /etc/hosts on the mail server
>
> Did that..

OK, that shows sendmail is actually doing a DNS lookup directly, not calling 
the gethostbyaddr() system call which looks in /etc/hosts before looking in 
the DNS.

> > 2. Try getting rid of sendmail, and replace it with a modern MTA (e.g.
> > exim or postfix) which can have its relaying policy more easily
> > controlled
>
> I'd really love to use Exim or otherwise but it's not a decision I can
> make entirely by myself. My hands are tied here.... :-)
>
> I just got to make-do with the sendmail I have running....

Really? Try telling your boss how many security break-ins have been due to 
sendmail over the past years (answer: too many to count). Try telling your 
boss that if he/she wants to implement policy controls, such as controlling 
who can send where, or spam filtering, or adding signatures, or virus 
scanning, or LDAP lookups, or controlling E-mail by time of day, it varies 
from very difficult to completely impossible with sendmail. Try showing your 
boss what /etc/sendmail.cf or /etc/mail/sendmail.cf actually looks like, and 
try to get him/her to decipher it.

Point out that many modern Linux distributions have binned sendmail in favour 
of something else, for all these reasons.

> > You may also find the sendmail error in the mail server's error log
> > (typically /var/log/maillog)
>
> I did check the mail server's error log and found the following errors:
>
> a) Timeout waiting for input from [81.199.29.78] during message collect
>
> b) Unable to get canonical name of client 192.168.0.55: Unknown Host (1)
> [pop_init.C:799]
>
> >From error(b) above, the implication I get is that the server believes the
>
> connection is from 192.168.0.55 and not from 192.168.10.79 (just like
> Brian mentioned in a previous posting). This could be due to the confusion
> from the NAT on the PIX.

Ack. I have no idea which source file pop_init.C is, by the way; it doesn't 
seem to be part of sendmail (at least, not the version of sendmail 
distributed with FreeBSD 5.4 which I have on the machine I'm typing this)

> With this in mind, I decided to try two options namely;
>
> 1. I totally disabled NAT on the PIX. With the NAT disabled, I could only
> get as far as my gateway address (192.168.10.254) on any LAN PC.

If you cannot ping 192.168.0.5 from 192.168.10.x, you need to check if it's 
the outbound path or the return path which is broken.

I suggest you run tcpdump on 192.168.0.5, then try to ping it from 
192.168.10.x.

If tcpdump shows the packets arriving (and the pings going out), then the 
problem is the ping responses getting back to 192.168.10.x. This may be 
because of a missing static route on the border router, or the border router 
having access controls, or the border router wrongly NATting the packet even 
though it's being resent on the same interface, or the PIX policy not 
allowing the packets back in.

If tcpdump doesn't show any pings arriving, then PIX policy is not allowing 
the traffic out.

If packets are arriving at the mailserver, you can always try adding a static 
route back:

   route add -net 192.168.10.0 -netmask 255.255.255.0 [gw] 192.168.0.2

"gw" is needed for Linux boxes if I remember rightly, but not FreeBSD.

If adding that makes it work, then it would show a problem with the border 
router.

> 2. I removed the global rule on the PIX and changed the NAT rule from
> nat(inside) 1 0 0 to nat(inside) 0 192.168.10.0 255.255.255.0. With this
> one NAT rule enabled, I could get to my LAN gateway (192.168.10.254) plus
> both border router interfaces (that is, 192.168.0.1 & 81.199.29.54) and
> that was it. I couldn't go beyond the router outside interface at all!

Sounds to me like the border router isn't doing NAT for that address. Again, 
traffic capturing is useful. If you ping the mailserver from 192.168.10.x, 
what source IP address do you see in tcpdump?

> > Good. So you definitely have a problem with the server applications
> > themselves, not with the IP routing or NAT.
>
> Any in mind I can take a look at?

For connections to port 25, your application is sendmail; for connections to 
port 110, it's your pop3 server (qpopper I think you said?)

> I do follow here, but with NAT turned off, I couldn't get beyond my
> gateway as described above.

Ack. Someone who knows PIX configuration may have to help you here.

Also, try turning on logging on the PIX. If your outbound packets are logged 
as rejected/discarded by the PIX, then the problem is clearly PIX policy 
configuration. You may need to configure the PIX to say "allow outbound TCP 
connections from 192.168.10.0/24 to anywhere", for example.

> Someone did mention something to do with port-forwarding on the PIX, which
> after doing some reading, which entails having to disable some NAT and
> also make use of a public address for the mail server (which address I
> don't have at my disposal). This still brings me back to square one, that
> is, issues of disabling some NAT on the PIX.

Hopefully you won't need port forwarding on the PIX, unless you have servers 
on the internal network which need to be reached from outside (in which case, 
those servers probably ought to live in the DMZ anyway)

Cheers,

Brian.