[afnog] PIX Configuration Issue

[Julius Kidubuka]

Thanks for the response Brian!

> It would be good if you could report exactly what solved the problem. That
> means that the list readers can see solutions, as well as problems :-)

My apologies for this. I'll endeavour to post my solution soon.

> What exactly do you mean "can't pop and send mail"? What exactly are the
> symptoms - i.e. what exactly do the clients try to do, and what exactly is
> the error message they see?

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

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]

>From this, I do see that the address, 192.168.0.55, is the global pool
address that is assigned to the client PC (192.168.10.79) from which the
mail is trying to be sent. This is shown after running the following
command off the PIX;

pixfirewall#sh xlate
Global 192.168.0.55 Local 192.168.10.79


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.

> Since you can ping, my first guess is that this is a layer 4-7 problem, or
> else firewalling of TCP. So the first test I would do on the clients is:
>
>     telnet x.x.x.x 25
>     telnet x.x.x.x 110
>
> where x.x.x.x is the mailserver IP, and see exactly what response I get
> back.

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

> I would also try running tcpdump on the mailserver at the same time:
> something
> like
>
>     tcpdump -i eth0 -n -s1500 -X

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)


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

The other global(outside).... just lets me create a pool of addresses that
inside users use to access the router inside interface and then beyond
(that is, after the router has also done its NAT).

> The way I'd do it is to turn off NAT, and then on the router put a static
> route:
>
> ip route 192.168.10.0 255.255.255.0 192.168.0.2
> This is so that any machine in the DMZ which tries to send a packet to
> 192.168.10.x will send it to their defaultroute (the router) which in turn
> will forward it to the PIX.

I have done this...

> I'd then make sure that everything could ping everything else internally,
> and
> open TCP connections (setting a 'permit everything' policy on the PIX
> first
> if necessary).

Done this too....

> Then I'd clamp down the policies, e.g. so that machines on
> 192.168.10.x could make outgoing connections to the mailserver, but not
> vice
> versa. That is, make it be a firewall.
>
> Finally I'd then enable NAT on the border router to allow everything to
> access
> the Internet, and set whatever port-forwarding rules are necessary for
> inbound services (e.g. port 25 to mailserver)

>From my router confs, I have done the following to enable inbound services
to the mail server;

ip nat inside source static tcp 192.168.0.5 25 81.199.29.54 25 extendable
ip nat inside source static tcp 192.168.0.5 110 81.199.29.54 110 extendable
ip nat inside source static tcp 192.168.0.5 143 81.199.29.54 143 extendable


Even after I have done all this, I still can't get to send/receive mail
off the LAN PCs using my preferred MUA.

More ideas are certainly welcome.


Regards,
Juki.