problem connecting through PIX to a specific smtp server

I've run into a problem that has me stuck and unfortunately Cisco is a bit of a weak area for me. We've got a client that we just recently inherited that started having problems with e-mail going to a specific server. I checked into it and when I try to telnet into port 25 of the remote server from the Exchange server it times out. Wireshark shows no response whatsoever. But if I conduct the exact same test from the terminal server I can get in with no issue 10 times out of 10. I checked the config in the pix and they're both being natted to the same external address so it doesn't seem like a case of the external server blocking the ip. The Exchange server is having no issues connecting to other smtp servers just this one.

To me it seems like a problem with the pix but I don't see the issue as there are no ACLs blocking outbound traffic and both servers are natted to the same external ip. If anyone could offer some guidance on this one I would appreciate it.

: Saved
:
PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto shutdown
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz security50
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol pptp 1723
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
no fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
access-list outside_access_in permit tcp any host 99.177.37.147 eq smtp
access-list outside_access_in permit tcp any host 99.177.37.147 eq pop3
access-list outside_access_in permit tcp any host 99.177.37.147 eq www
access-list outside_access_in permit tcp any host 99.177.37.147 eq https
access-list outside_access_in permit tcp any host 99.177.37.147 eq 587
access-list outside_access_in permit tcp any host 99.177.37.148 eq 3389
access-list outside_access_in permit tcp any host 99.177.37.144 eq 3389
access-list outside_access_in permit tcp any host 99.177.37.144 eq pptp
access-list outside_access_in permit tcp any host 99.177.37.149 eq 3389
access-list outside_access_in permit tcp any host 99.177.37.149 eq www
access-list outside_access_in permit tcp any host 99.177.37.149 eq https
access-list outside_access_in permit tcp any host 99.177.37.150 eq www
access-list outside_access_in permit tcp any host 99.177.37.150 eq https
access-list outside_access_in permit tcp any host 99.177.37.150 eq 3389
access-list outside_access_in permit tcp any host 99.177.37.151 eq 3389
access-list outside_access_in permit icmp any any
access-list inside_access_in permit ip any any
access-list inside_access_in permit icmp any any
mtu outside 1500
mtu inside 1500
mtu dmz 1500
ip address outside 95.121.134.246 255.255.255.252
ip address inside 10.0.0.2 255.255.0.0
ip address dmz 10.4.105.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) tcp 99.177.37.147 smtp 10.0.0.43 smtp netmask 255.255.25
5.255 0 0
static (inside,outside) tcp 99.177.37.144 pptp 10.0.0.28 pptp netmask 255.255.25
5.255 0 0
static (inside,outside) tcp 99.177.37.144 47 10.0.0.28 47 netmask 255.255.255.25
5 0 0
static (inside,outside) tcp 99.177.37.147 pop3 10.0.0.21 pop3 netmask 255.255.25
5.255 0 0
static (inside,outside) tcp 99.177.37.147 www 10.0.0.21 www netmask 255.255.255.
255 0 0
static (inside,outside) tcp 99.177.37.147 https 10.0.0.21 https netmask 255.255.
255.255 0 0
static (inside,outside) tcp 99.177.37.147 587 10.0.0.21 587 netmask 255.255.255.
255 0 0
static (inside,outside) tcp 99.177.37.149 www 10.0.0.51 www netmask 255.255.255.
255 0 0
static (inside,outside) tcp 99.177.37.149 https 10.0.0.51 https netmask 255.255.
255.255 0 0
static (inside,outside) tcp 99.177.37.150 https 10.0.0.239 https netmask 255.255
.255.255 0 0
static (inside,outside) tcp 99.177.37.150 www 10.0.0.239 www netmask 255.255.255
.255 0 0
access-group outside_access_in in interface outside
access-group inside_access_in in interface inside
route outside 0.0.0.0 0.0.0.0 95.121.134.245 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

Bl8ckr0uter

I am not expert but from what I can see it doesn't look like Telnet is allowed (not that it would need to be). Does show log produce any thing when you are trying to telnet or when you try to send mail? Usually you will see something like blocked due to x access list...

SteveO86

Are you able to connect to this server with a different protocol?
(Just to see if it's an overall connectivity issue or just an SMTP/Telnet issue.)

Does a netstat on the mail server show any attempted connections for port 25?

ChooseLife

Are you testing this using the remote server's IP address?

undomiel

Sorry, doesn't look like I was clear. This is outbound traffic to a remote server. Testing is being done like so:

telnet mail.specificserver.com 25

From the Exchange server (10.0.0.21) it will time out. Conducting the same test from the terminal server (10.0.0.25) results in a successful connection to the destination smtp server. So the traffic flow is as such:

Exchange -> PIX -> Internet -> mail.specificserver.com

So that would be hitting this rule:

access-list inside_access_in permit ip any any

Which would be allowing the traffic. While using wireshark to monitor traffic from the Exchange server I see only outbound and no response. Checking the logs in the pix shows a syn timeout for the connection. Same traffic from the terminal server works.

ChooseLife

I have a slight suspicion that it may be a DNS issue and mail.specificserver.com resolves to two different IP's from these two boxes...

undomiel

Unfortunately that isn't the case. DNS was the first thing I suspected but I verified that the correct ip was being pulled and that both machines were connecting to the same address.

undomiel

An update on this one. Problem turned out to be a proxy on the receiving end's side.

ChooseLife

undomiel wrote: »

An update on this one. Problem turned out to be a proxy on the receiving end's side.

Good to know, thanks for the update