cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3282
Views
0
Helpful
16
Replies

Incoming SMTP issue with an ASA5512-X

khyron1969
Level 1
Level 1

I have reviewed numerous support discussions on this particular issue, but I am still unable to properly configure my ASA 5512-X to receive SMTP email. I can send email, and have access to all other services that I setup.  I did create a network object for my Mail server and I am fairly certain this issue has something to do with my static NAT setup.

My current configuration is listed below...any assistance would be greatly appreciated.

I am new to the Cisco ASA appliance, and I am learning CLI as I go.  I also have ADSM setup.  

 

CONFIGURATION:


: Hardware:   ASA5512, 4096 MB RAM, CPU Clarkdale 2792 MHz, 1 CPU (2 cores)
:
ASA Version 9.3(1)
!

names
!
interface GigabitEthernet0/0
 nameif Verizon
 security-level 0
 ip address 100.39.18.94 255.255.255.0
!
interface GigabitEthernet0/1
 description Local Norco Domain
 nameif Norco.local
 security-level 100
 ip address 10.0.0.10 255.255.255.0
 dhcprelay server 10.0.0.1
!
interface GigabitEthernet0/2
 description SCE-DRAS SERVER
 nameif SCE-DRAS
 security-level 0
 ip address 192.168.10.1 255.255.255.0
!
interface GigabitEthernet0/3
 shutdown
 no nameif
 no security-level
 no ip address
!
interface GigabitEthernet0/4
 shutdown
 no nameif
 no security-level
 no ip address
!
interface GigabitEthernet0/5
 shutdown
 no nameif
 no security-level
 no ip address
!
interface Management0/0
 management-only
 nameif management
 security-level 100
 ip address 192.168.1.1 255.255.255.0
!
boot system disk0:/asa931-smp-k8.bin
boot system disk0:/asa912-smp-k8.bin
ftp mode passive
dns domain-lookup Verizon
dns domain-lookup Norco.local
dns server-group DefaultDNS
 name-server 10.0.0.1
 name-server 68.238.96.12
 name-server 68.238.64.12
 domain-name norco.local
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
object service HTTP-19560
 service tcp destination eq 19560
object service HTTP-65535
 service tcp destination eq 65535
object service HTTP-8933
 service tcp destination eq 8933
object service HTTP-8943
 service tcp destination eq 8943
object service RTP
 service udp destination range 19560 65535
object service SIP-TCP-8943
 service tcp destination range 8933 8943
 description IPPHONE - SIP
object service SIP-UDP-8943
 service udp destination range 8933 8943
 description IPPHONE - SIP
object service smtp
 service tcp destination eq smtp
object network SMTP-SERVER
 host 10.0.0.1
object-group network IPHONE-SERVERS
 description VERIZON IP-PHONE SERVERS
 network-object 128.177.14.0 255.255.255.0
 network-object 128.177.36.0 255.255.255.0
 network-object host 199.19.195.241
 network-object host 199.19.195.243
 network-object host 199.19.195.250
object-group service GENERAL-ACCESS tcp
 description GENERAL SERVICES ACCESS
 port-object eq ftp
 port-object eq www
 port-object eq https
 port-object eq smtp
object-group service IP-PHONE-SERVICE
 description PHONE SYSTEM ACCESS RULES
 service-object object HTTP-19560
 service-object object HTTP-65535
 service-object object HTTP-8933
 service-object object HTTP-8943
 service-object object RTP
 service-object object SIP-TCP-8943
 service-object object SIP-UDP-8943
 service-object tcp-udp destination eq 1025
 service-object tcp destination eq www
 service-object tcp destination eq https
 service-object udp destination eq domain
 service-object udp destination eq ntp
 service-object tcp-udp destination eq domain
 service-object tcp-udp destination eq www
 service-object tcp-udp destination eq sip
 service-object tcp destination eq domain
 service-object tcp destination eq smtp
 service-object tcp destination eq ssh
 service-object tcp destination eq telnet
 service-object udp destination eq dnsix
 service-object udp destination eq www
object-group service General-TCP-UDP-Access
 service-object tcp-udp destination eq domain
 service-object tcp-udp destination eq www
 service-object tcp destination eq domain
 service-object tcp destination eq ftp
 service-object tcp destination eq www
 service-object tcp destination eq https
 service-object udp destination eq www
 service-object udp destination eq ntp
 service-object udp destination eq radius
access-list Verizon_access_in extended permit object-group IP-PHONE-SERVICE object-group IPHONE-SERVERS any
access-list Verizon_access_in extended permit tcp any object SMTP-SERVER eq smtp
access-list Verizon_access_out extended permit object-group IP-PHONE-SERVICE any object-group IPHONE-SERVERS
access-list Verizon_access_out extended permit object-group General-TCP-UDP-Access any any
access-list Verizon_access_out extended permit tcp any any eq smtp
access-list SCE-DRAS_access_out extended permit ip any any
access-list SCE-DRAS_access_in extended permit ip any any
pager lines 24
logging enable
logging asdm informational
mtu Verizon 1500
mtu Norco.local 1500
mtu SCE-DRAS 1500
mtu management 1500
ip verify reverse-path interface Verizon
no failover
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-731-101.bin
no asdm history enable
arp timeout 14400
no arp permit-nonconnected
nat (Norco.local,Verizon) source dynamic any interface
nat (SCE-DRAS,Verizon) source dynamic any interface
!
object network SMTP-SERVER
 nat (Norco.local,Verizon) static interface service tcp smtp smtp
access-group Verizon_access_in in interface Verizon
access-group Verizon_access_out out interface Verizon
access-group SCE-DRAS_access_in in interface SCE-DRAS
access-group SCE-DRAS_access_out out interface SCE-DRAS
route Verizon 0.0.0.0 0.0.0.0 100.39.18.1 1
route Norco.local 10.10.0.0 255.255.255.0 10.0.0.7 2
timeout xlate 3:00:00
timeout pat-xlate 0:00:30
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
user-identity default-domain LOCAL
http server enable
http 192.168.1.0 255.255.255.0 management
http 10.0.0.0 255.255.255.0 Norco.local
no snmp-server location
no snmp-server contact
crypto ipsec security-association pmtu-aging infinite
crypto ca trustpoint _SmartCallHome_ServerCA
 no validation-usage
 crl configure
crypto ca trustpoint ASDM_Launcher_Access_TrustPoint_0
 enrollment self
 subject-name CN=10.0.0.10,CN=ciscoasa
 crl configure
crypto ca trustpoint ASDM_Launcher_Access_TrustPoint_1
 enrollment self
 subject-name CN=10.0.0.10,CN=ciscoasa
 crl configure

telnet timeout 5
ssh stricthostkeycheck
ssh timeout 5
ssh key-exchange group dh-group1-sha1
console timeout 0
dhcpd update dns both override
!
dhcpd address 192.168.10.2-192.168.10.5 SCE-DRAS
dhcpd dns 68.238.96.12 68.238.64.12 interface SCE-DRAS
dhcpd enable SCE-DRAS
!
dhcpd address 192.168.1.2-192.168.1.10 management
dhcpd enable management
!
dhcprelay information trust-all
threat-detection basic-threat
threat-detection scanning-threat
threat-detection statistics host
threat-detection statistics port
threat-detection statistics protocol
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
ssl encryption rc4-sha1 aes128-sha1 aes256-sha1 3des-sha1
ssl trust-point ASDM_Launcher_Access_TrustPoint_1 Norco.local
ssl trust-point ASDM_Launcher_Access_TrustPoint_1 Norco.local vpnlb-ip
webvpn
 anyconnect-essentials
 no error-recovery disable
dynamic-access-policy-record DfltAccessPolicy
!
class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum client auto
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp
  inspect ip-options
 class class-default
  user-statistics accounting
!
service-policy global_policy global
smtp-server 10.0.0.1
prompt hostname context
service call-home

1 Accepted Solution

Accepted Solutions

Hi,

The issue is actually with the order of NAT statements that's why you see the drop on the ASA device for the packet tracer.

Change the Order of NAT statement and that should fix this issue:-

nat (Norco.local,Verizon) source dynamic any interface
nat (SCE-DRAS,Verizon) source dynamic any interface
!
object network SMTP-SERVER
 nat (Norco.local,Verizon) static interface service tcp smtp smtp

Change the Manual NAT for Dynamic to Auto NAT:-

object network 0.0.0.0

subnet 0 0

nat (Norco.local,Verizon) dynamic interface

object network 0.0.0.0-1

subnet 0 0

nat (SCE-DRAS,Verizon) dynamic interface

Thanks and Regards,

Vibhor Amrodia

View solution in original post

16 Replies 16

Murali
Level 1
Level 1

Did you disable rsmtp inspection in the default global policy ? if yes can enable and check once.

Thank you

Murali

Hi Murali,

 

My apologies for the delayed response...were you referring to esmtp inspection?

I did originally disable ESMTP inspection, I just tried re-enabling but am still having the same issue...outgoing email is working, incoming is not.

Thanks,

John

 

 

 

Hi John,

My bad i meant esmtp .config related to your snmp server looks good to me. If you can try packet capture and post it here that should give us something to look at.

 

capture TEST access-list CAP

show capture TEST

 

Thanks

Murali

Hi Murali,

I attempted the capture via CLI using the command:

capture TEST access-list Verizon_access_in

but the show capture TEST results were 0 packets captured.

I used the ASDM packet capture wizard and posted those results...during the capture I sent several test emails from the outside in.  It doesn't appear that anything with service SMTP ever hits the incoming access-list.  The traffic appears to be all phone traffic.

For the CLI, should I have created a new temporary access-list called CAP for all ip traffic?

Thanks and take care,

John

 

Hi John,

Yes first we need to create ACL called CAP (just a name) and call that during capture , it's interesting you are not hits for the mail traffic. 

You can include only smtp related traffic in the access-list you create and double check if no traffic is hitting that if that is the case then we may have it take a different direction(could be routing or any other issue we don't know yet)

Thanks

Murali
 

Hi Murali,

I played with this for a bit today...I created a capture and access list for only smtp traffic. The results are included below...I sent three test emails...all three generated an immediate RST.  The packets were captured on the Verizon interface

Thanks and Take care,

John

Hello John,

I reviewed the packet capture and i suspect issue could be related ASA tcp source port randomization. Now by DEFAULT tcp randomization is enabled and what it does is to improve the security ASA intercepts the client connections and randomizes the source port so that tcp source port prediction based hijacking/attacks can be prevented but i guess ASA will not do randomization for NATed address so i think we are sending the same source port number and as a results because it maintains the state table RST are happening .

If possible could you disable TCP randomization feature only for SMTP traffic and check if it works for you ?

You can use below example ( you can be as specific as you want for the ACL)

 

1) access-list SMTP_ACL extended permit tcp host 100.39.18.94 any eq smtp

2) class-map SMTP_CLASS
 match access-list SMTP_CAP
 
3) policy-map SMTP_POLICY
 class SMTP_CLASS
 set connection random-sequence-number disable

Thank you

Murali

 

Hi Murali,

I setup the access-list, class-map, and policy-map as indicated above, but it did not fix the problem...

Unfortunately, I realized I was incorrect in my statement yesterday...I rechecked the file I uploaded (as I captured additional data today after the additions above)...and noted that there is incoming SMTP traffic that appears to be passing through the outside interface...It was a coincidence that I sent three emails and had 3 RST responses...I checked the addresses for those 3 RST packets and they were not from me...the ones I sent generated a SYN.

I have yet to run a capture on the internal interface...I'll perform a capture and see if I find anything...if I do I'll upload the file...

Thanks for your assistance and patience.

Regards,

John

 

 

Hi Murali,

I captured the data from the inside (Norco.local) interface and there is only outgoing smtp traffic...I wondering if there is an issue with my NAT and routing of the SMTP traffic...

Thanks,

John

 

Hello John,

 

Could you confirm if you've used the correct ACL's to capture the traffic because as you said we only see outgoing SMTP traffic in the capture.

If not you can create another ACL that has source as outside (if you know the ip mention it otherwise say any ) destination as inside for smtp port.

 

Thank you

Murali.

 

P.S: As we are in two different timezones it's taking sometime to fix your issue . I feel sorry for that

Hi Murali,

My apologies...I probably should have provided the ACL I used for the uploads:

For the first upload I used (file ASA_CAP-2.txt):

access-list asa_cap extended permit tcp any4 any4 eq smtp

cap asa_cap interface verizon access-list asa_cap

This appears to show both inbound and outbound SMTP traffic on the outside interface.

 

For the second upload I used (file ASA_CAP-6.txt):

access-list asa_cap extended permit tcp any4 any4 eq smtp

cap asa_cap interface Norco.local access-list asa_cap

 

This appears to show only outbound SMTP traffic on the inside interface...nothing coming in.

I'll re-examine and see if I missed anything though...and I'll look at the packet-tracer results as well.

 

No worries about the time-zones...as a newbie to ASA I've been trying to figure this out for several weeks, so I'm currently switching between a working cisco SA-520 and the ASA5512-x.  I can only "play" for a short time here and there during the course of the day as I learn, so the pace is actually working out just fine. I am appreciative of your efforts and assistance...

Take care,

John

 

 

 

 

Hi Murali,

I ran the packet tracer routine...please let me know if I did this correctly...the results are below.  The results indicate the traffic is denied by the implicit rule, but I'm not sure why....

 

ciscoasa(config)# packet-tracer input verizon tcp 209.85.213.176 smtp 100.39.18.94 smtp

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
in   100.39.18.94    255.255.255.255 identity

Phase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         via 100.39.18.1, Verizon

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

Result:
input-interface: Verizon
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

Hi,

The issue is actually with the order of NAT statements that's why you see the drop on the ASA device for the packet tracer.

Change the Order of NAT statement and that should fix this issue:-

nat (Norco.local,Verizon) source dynamic any interface
nat (SCE-DRAS,Verizon) source dynamic any interface
!
object network SMTP-SERVER
 nat (Norco.local,Verizon) static interface service tcp smtp smtp

Change the Manual NAT for Dynamic to Auto NAT:-

object network 0.0.0.0

subnet 0 0

nat (Norco.local,Verizon) dynamic interface

object network 0.0.0.0-1

subnet 0 0

nat (SCE-DRAS,Verizon) dynamic interface

Thanks and Regards,

Vibhor Amrodia

Thanks Vibhor and Murali,

The problem has been resolved!

As I did my research into this issue, I saw numerous posting about ensuring the proper order for NAT...I made a bad assumption that the NAT rule for a network object was treated independent of a standard NAT rule, so I never even looked at the order...

I appreciate the efforts from both parties as I learned quite a bit from the experience.

 

Thanks and regards,

John

Review Cisco Networking for a $25 gift card