[afnog] PIX Configuration Issue

[Julius Kidubuka]

I am sorry about the delay in response. This is because the entire setup
is located on different premises and also they close for business rather
early and on time :-)

Anyhow, here are my findings;

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

True!

> 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.

Yes, I did perform the test and confirmed that there wasn't any mail for
that user (e-mail account). I did send a couple of e-mails to that
user/e-mail account so I think that the only reason the mail wasn't
delivered to the mail server is that the mail server may be unreachable
from the outside.

With this thought in mind, I decided to perform a couple of tests as shown
below:


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.


Also,

mail# telnet mail.molg.go.ug 110
Trying 81.199.29.54...
Connected to mail.molg.go.ug.
Escape character is '^]'.
+OK ready  <3829.1119480943 at mail.molg.go.ug>
user juki at molg.go.ug
+OK Password required for juki.
pass pass
+OK juki has 0 visible messages (0 hidden) in 0 octets.
^]
telnet> q
Connection closed.


>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?

>> 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?

> Your options are:
>
> 1. Try putting
>
> 192.168.0.55	pc55.localdomain
>
> in /etc/hosts on the mail server

Did that..

> 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....

>> 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.

Did that too (see results above).....

> 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.

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.

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!

Interestingly too, I couldn't get to the PIX outside interface
(192.168.0.2) yet I could go beyond it and even reach the router and mail
server too!


During all this, my router had:

router#sh ip route

S 192.168.10.0/24 [1/0] via 192.168.0.2
C 192.168.0.0/24 is directly connected, FastEthernet0

>> 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.

Any in mind I can take a look at?

> 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.

That's true, thanks :-)

>> 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  > 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  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   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.

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

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.


Guess I still going to have another sleepless night unless...


Rgds,
Juki.