Cisco Pix problem or Microsoft Exchange? Can email anybody except the one domain that sits behind the same firewall as I

first, is the exchange server configured to relay the domain specifically to the 1.x server.  if not, i'd try that first as then it takes DNS out of the picture.

second, from the 5.x server, do this
telnet 192.168.1.x 25
does it receive a mail banner, if so then the pix is fine.  if not, then we need to look at the static entries and the acls to ensure that it allows that traffic.

I am unable to telnet to t1.x fromt he 5.x  i also tried telneting the actuall domain

telnet (5.X Exchange server) 25  and nothing

then we need to check the pix config.  after you post the static,global/nat, and acls pieces of the config should be able to check to ensure those servers can communicate
my guess is its an acl issue, however it could be a xlate issue potentially

access-list 90 permit ip 192.168.0.0 255.255.252.0 192.168.24.0 255.255.252.0
access-list 90 permit ip 192.168.24.0 255.255.252.0 192.168.0.0 255.255.252.0
access-list 90 permit ip 192.168.28.0 255.255.252.0 192.168.0.0 255.255.252.0
access-list 90 permit ip 192.168.0.0 255.255.252.0 192.168.28.0 255.255.252.0
access-list 80 permit ip 192.168.0.0 255.255.252.0 192.168.254.0 255.255.255.0
access-list dmz_nat0 permit ip 192.168.255.0 255.255.255.0 192.168.0.0 255.255.2
52.0
access-list inside_nat0 permit ip 192.168.0.0 255.255.252.0 192.168.254.0 255.25
5.255.0
access-list inside_nat0 permit ip 192.168.0.0 255.255.252.0 192.168.24.0 255.255
.252.0
access-list inside_nat0 permit ip 192.168.24.0 255.255.252.0 192.168.0.0 255.255
.252.0
access-list inside_nat0 permit ip 192.168.28.0 255.255.252.0 192.168.0.0 255.255
.252.0
access-list inside_nat0 permit ip 192.168.0.0 255.255.252.0 192.168.28.0 255.255
.252.0
access-list inside_netzero permit ip 192.168.0.0 255.255.252.0 192.168.28.0 255.
255.252.0
pager lines 30
logging on
logging monitor debugging
logging buffered warnings
logging trap notifications
logging history notifications
logging queue 4096
logging host inside 192.168.1.111
interface ethernet0 10baset
interface ethernet1 auto
interface ethernet2 auto
interface ethernet3 auto
mtu outside 1500
mtu inside 1500
mtu dmz 1500
mtu ldplaw 1500
ip address outside 208.62.
ip address inside 192.168.1.1 255.255.252.0
ip address dmz 192.168.255.1 255.255.255.0
ip address ldplaw 192.168.5.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm

no failover
failover timeout 0:00:00
failover poll 15
failover ip address outside 0.0.0.0
failover ip address inside 0.0.0.0
failover ip address dmz 0.0.0.0
failover ip address ldplaw 0.0.0.0
no pdm history enable
arp timeout 300
global (outside) 1 208.62.29
global (outside) 1 208.62.
global (dmz) 1 interface
global (ldplaw) 1 interface
nat (inside) 0 access-list inside_nat0
nat (inside) 1 192.168.0.0 255.255.252.0 0 0
nat (dmz) 1 192.168.255.0 255.255.255.0 0 0
nat (ldplaw) 1 192.168.5.0 255.255.255.0 0 0

alias (inside) 208.62.X X 192.168.255.162 255.255.255.255
alias (inside) 208.62.X X 192.168.255.142 255.255.255.255
alias (inside) 208.62.X X 192.168.255.10 255.255.255.255
alias (ldplaw) 208.62.X X 192.168.5.2 255.255.255.255
static (dmz,outside) 208.62.X X 192.168.255.146 netmask 255.255.255.255 0 0
static (dmz,outside) 208.62.X X 192.168.255.142 netmask 255.255.255.255 0 0
static (dmz,outside) 208.62.X X 192.168.255.25 netmask 255.255.255.255 0 0
static (dmz,outside) 208.62.X X 192.168.255.162 netmask 255.255.255.255 0 0
static (dmz,outside) 208.62 X X 192.168.255.141 netmask 255.255.255.255 0 0
static (dmz,outside) 208.62.X X 192.168.255.165 netmask 255.255.255.255 0 0
static (inside,dmz) 192.168.0.0 192.168.0.0 netmask 255.255.255.0 0 0
static (dmz,outside) 208.62.X X 192.168.255.191 netmask 255.255.255.255 0 0
static (dmz,outside) 208.62.X X 192.168.255.10 netmask 255.255.255.255 0 0
static (ldplaw,outside) 208.62.X X 192.168.5.2 netmask 255.255.255.255 0 0
conduit permit tcp host 208.62.X X eq www any
conduit permit tcp host 208.62.X X eq www any
conduit permit tcp host 208.62.X X eq ftp any
conduit permit tcp host 208.62.X X eq ftp-data any
conduit permit tcp host 208.62.X X eq www any
conduit permit tcp host 208.62.X X eq ftp any
conduit permit tcp host 208.62.X X eq ftp-data any
conduit permit tcp host 208.62.X X eq smtp any
conduit permit tcp host 208.62.X X eq ssh 65.65.0.0 255.255.0.0
conduit permit icmp any any echo-reply
conduit permit tcp host 208.62.X X eq www any
conduit permit tcp host 208.62.X X eq ftp any
conduit permit tcp host 208.62.X X eq ftp-data any
conduit permit tcp host 208.62.X X eq 97 any
conduit permit tcp host 208.62.X X eq 4096 any
conduit permit udp host 208.62.X X range 7777 7778 any
conduit permit tcp host 208.62.X X range 7777 7778 any
conduit permit tcp host 208.62.X X eq www any
conduit permit tcp host 208.62.X X eq www any
conduit permit tcp host 208.62.X X eq https any
conduit permit tcp host 208.62. X X eq https any
conduit permit tcp host 208.62.X X eq https any
conduit permit tcp host 208.62.X X eq smtp any
conduit permit tcp host 208.62.X X eq www any
conduit permit tcp host 208.62.X X eq 97 any
conduit permit tcp host 208.62.X X eq https any
conduit permit tcp host 208.62.X X eq 3389 any
conduit permit icmp host 192.168.5.2 any echo
route outside 0.0.0.0 0.0.0.0 208.62.29.65 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 si
p 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute

here is what I would do
no static (inside,dmz) 192.168.0.0 192.168.0.0 netmask 255.255.255.0 0 0
static (inside,dmz) 192.168.1.0 192.168.0.0 netmask 255.255.252.0 0 0
static (dmz,inside) 192.168.255.0 192.168.255.0 netmask 255.255.255.0
access-list dmz-in permit tcp host 192.168.255.X host 192.168.0.Y eq smtp
access-list dmz-in interface dmz
clear xlate

The first two lines just makes its so the static entry matches the mask that is given to the inside network. The third makes it so the dmz to inside connections ensure to keep their ips.  The next two lines add an acl to that the mail server on the 255 network can communicate to the 0 mail server.  the final line clears the translation table since the statics were altered.
after doing that try another telnet test.
if that doesn't work, then we need to look at the logs as I believe that should've worked.

Well, thre DMZ is a 4rd and seperate interface on this PIX.

Interface 1:  (Inside) 192.168.1.X My LAN
Interface 2:  (DMZ) 192.168.255.X My DMZ
Interface 3:  (Inside) 192.168.5.X My LDPLAW (this is the new interface for a seperate company that reside behind my PIX but seperate from my LAN.

I need 5.X to be bale to telent the 1.x

The DMZ is fine.

oops, sorry, i was thinking DMZ and inside there

honestly , this is what I would do then
no global (ldplaw) 1 interface
static (inside,ldplaw) 192.168.1.0 192.168.1.0 255.255.252.0
static (ldplaw,inside) 192.168.5.0 192.168.5.0 255.255.255.0
this will make it so the translation done between the two interfaces effectively just let traffic route.  This is because the orig IP will be mapped back to itself.  Now you just add the correct ACLs and you should be good.  Don't forget about doing the 'clear xlate' after you modify the static/global entries.

The only other way to do this is provide a global statement for the inside interface so all the ldplaw clients can be PAT'ed to that and be translated that way

When i try to add the static  entries I get


number of maximum connections should lie between 0 and 65535
Usage:  [no] static [(internal_if_name, external_if_name)]
                {<global_ip>|interface} <local_ip> [dns] [netmask <mask>]
                [<max_conns> [<emb_limit> [<norandomseq>]]]
        [no] static [(internal_if_name, external_if_name)] {tcp|udp}
                {<global_ip>|interface} <global_port>
                <local_ip> <local_port> [dns] [netmask <mask>]
                [<max_conns> [<emb_limit> [<norandomseq>]]]

sorry, so used to doing one-to-one static entries I keep forgetting about the netmask keyword
static (inside,ldplaw) 192.168.1.0 192.168.1.0 netmask 255.255.252.0
static (ldplaw,inside) 192.168.5.0 192.168.5.0 netmask 255.255.255.0

that will work, sorry about that

Thank you so much for your help.

I got this error
FL-JAJ-PIX(config)# static (inside,ldplaw) 192.168.1.0 192.168.1.0 netmask 255$
global address overlaps with mask
Usage:  [no] static [(internal_if_name, external_if_name)]
                {<global_ip>|interface} <local_ip> [dns] [netmask <mask>]
                [<max_conns> [<emb_limit> [<norandomseq>]]]
        [no] static [(internal_if_name, external_if_name)] {tcp|udp}
                {<global_ip>|interface} <global_port>
                <local_ip> <local_port> [dns] [netmask <mask>]
                [<max_conns> [<emb_limit> [<norandomseq>]]]

this will happen if you have either the source interface or destination interface using a range or IP that overlaps with a global/nat entry.  It should have still added the entry.  The thing to remember here is that static entries are the NAT way to do things and thus take precedence over the global/nat, or PAT, way of doing things.  

So if there is a direct conflict between the two, the static entry wins out.  However this warning should only show in cases like these where the subnet and mask match that of one in a global/nat entry.

hope that made sense

Well I could not get the PIX to cooperate, so I took the exchange sever and added it to the same local network as the other.  I am still having the same issue.  I don't think it can be thre PIX becuase both servers are on 192.168.1.X

Server1 can email Server 2 and any other external recipient
Server2 can email externals recipients but cannot email Server1

I am dreading making the call to MS but If I cannot ghet this resolved I may just have to.

so just to be clear, when you do this from server 2 you are still getting a time out
telnet 192.168.1.x 25

if so, turn off all firewalls including checking packet filtering on server2 for now.  then use wireshark to do a traffic capture on both servers.  do another telnet and see what packets are showing up
for server 1 do a capture filter of:  ip host <<server2 ip>>
and for server 2: ip host <<server1 ip>>

if the packets are going back and forth, then it may shed some light on the server being configured in a way that is rejecting the application level connection and not rejecting the packet level connection

OK, the solution to this issue was in Exchange

I created an SMTP Connector and was then able to route mail between both domains behind the PIX.

Thank you for your help.