[afnog] PIX Configuration Issue

[Brian Candler]

On Wednesday 22 June 2005 12:09, Julius Kidubuka wrote:
> When I do try to pop mail from one of the client PCs' MUA, it doesn't
> return any error whatsoever and also doesn't bring down any mail too
> though I do get the message 'Receive Complete'.

The implication to me is that it connected successfully, but there was simply 
no mail waiting.

To confirm:

    telnet x.x.x.x 110
    user someusername
    pass somepassword
    stat
    quit

will show you how many messages are waiting in the mailbox to be collected, 
and the total size in bytes.

> 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

Your options are:

1. Try putting

192.168.0.55	pc55.localdomain

in /etc/hosts on the mail server

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

> This scenario to me means that the MUA (which in this case is MS Outlook)
> is trying to send the mail via the global pool address .ie. 192.168.0.55
> and not the mail server (192.168.0.5) yet in my server settings (in MS
> Outlook), I have specifically set the pop3 and smtp servers to point to
> 192.168.0.5.

No, the client connected to the MTA just fine, as witnessed by the SMTP 550 
error message returned by the MTA.

You can also confirm this yourself by running

    telnet 192.168.0.5 25
    ehlo me
    mail from:<me at mydomain.com>
    rcpt to:<other at otherdomain.com>

on the client, so you can actually see the exchange for yourself.

You may also find the sendmail error in the mail server's error log 
(typically /var/log/maillog)

> When I do telnet to both ports, the mail server does respond accordingly.

Good. So you definitely have a problem with the server applications 
themselves, not with the IP routing or NAT.

The telnet commands above give you a start to debugging those; also you can 
look in the log files for the applications.

I think you can see now how important it is to describe the symptoms 
accurately - otherwise, it's impossible to know what is actually wrong.

> I got the following output after running the tcpdump simultaneously with
> the telnet:
>
> mail:/home#tcpdump -i eth0 -n -s1500 -X
> Kernel filter, protocol ALL, datagram packet source
> tcpdump: listening on eth0
>
> 00:10:20.231083 211.33.210.30.canocentral 0 > 192.168.0.5.smtp:
> P3563894468: 3563894492 (28) ack 1033798383 win 63829 (DF)
>
> 00:10:20.231083 192.168.0.5.smtp > 211.33.210.30.canocentral 0 P 1.46(45)
> ack 28 win 5840 (DF)

Well, that's part of a session. (P) is a poll. Run the tcpdump first, *then* 
connect from the client, and you'll see the whole exchange, starting with 
SYN/SYN-ACK packets (S), then the data, and finishing with FIN (F). with -X 
you should also see the contents of the packets, headers plus data.

> > That's a perfectly reasonable DMZ config, in some ways better than a
> > single
> > firewall with three interfaces:
> >
> >                                DMZ
> >    outside ------- FIREWALL --------- FIREWALL --------- inside
> >
> > However, since you've chosen to use private IPs in your DMZ, then there's
> > no
> > need to configure NAT on the PIX. (I don't know PIX configuration, so I
> > can't
> > say for sure whether you have NAT enabled, but I see some NAT-related
> > config
> > lines there)
>
> The statement nat(inside) 1 0 0 allows inside (LAN) users to start
> connections on any lower security interface (which in this case is the PIX
> outside interface).

Yes. But all I'm saying is, there's no need to have NAT on the PIX firewall at 
all. If the inside client has address 192.168.10.4, then it can remain 
unchanged as 192.168.10.4 as it hits the server in the DMZ. NAT is only 
needed for connections to the outside world, and can be done on the outside 
router.

This is your personal choice of course, and it will work with two levels of 
NAT as you have it, but usually simpler is better. In the current case, when 
your mail server logs show a connection from 192.168.0.55, you have no idea 
which PC it came from; if NAT were turned off, then you would see the PC's 
actual IP address.

Regards,

Brian.