[afnog] PIX Configuration Issue

Tue Aug 23 14:36:45 EAT 2005

Hi there,
   Relaying denied in sendmail means you haven't declared what you want to relay. Open /etc/mail/access file, and put in whatever IP or network you want relayed. You can even put an IP from outside ur network U want to relay. The format is like this:
 ex.
#
192.168.0.55        RELAY
192.168.0.56        RELAY
etc
or
192.168.0.0/255.255.255.0    RELAY
I prefer the first format

Type: makemap hash access < access 
to build ur access database. Good luck!

NJIE Paul
System and Network Engineer

---- Original Message ----- 
From: "Brian Candler" <B.Candler at pobox.com>
To: <juki at one2net.co.ug>
Cc: <afnog at afnog.org>
Sent: Wednesday, June 22, 2005 12:23 PM
Subject: Re: [afnog] PIX Configuration Issue

> 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.
> 
> _______________________________________________
> afnog mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv2.cfi.co.ug/mailman/private/afnog/attachments/20050823/0b8677bb/attachment-0001.html