topic Hi John,Yes first we need to in Network Security

Incoming SMTP issue with an ASA5512-X

khyron1969 — Tue, 12 Mar 2019 05:05:28 GMT

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

Did you disable rsmtp

Murali — Mon, 17 Nov 2014 01:57:19 GMT

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

khyron1969 — Mon, 17 Nov 2014 19:04:17 GMT

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

Murali — Tue, 18 Nov 2014 17:24:50 GMT

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

khyron1969 — Tue, 18 Nov 2014 19:22:23 GMT

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

Murali — Wed, 19 Nov 2014 08:11:46 GMT

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

khyron1969 — Wed, 19 Nov 2014 22:08:33 GMT

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

Murali — Thu, 20 Nov 2014 19:33:16 GMT

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

khyron1969 — Thu, 20 Nov 2014 23:17:40 GMT

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

khyron1969 — Thu, 20 Nov 2014 23:42:25 GMT

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

Murali — Fri, 21 Nov 2014 07:41:09 GMT

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

Also i realized we didn't

Murali — Fri, 21 Nov 2014 07:57:30 GMT

Also i realized we didn't check the packet-tracer results till now , please check that as well.

Hi Murali,My apologies...I

khyron1969 — Fri, 21 Nov 2014 15:48:15 GMT

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

khyron1969 — Sat, 22 Nov 2014 02:23:03 GMT

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

Vibhor Amrodia — Sat, 22 Nov 2014 09:20:37 GMT

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

Hey John,Actually Vibhor made

Murali — Sat, 22 Nov 2014 14:18:45 GMT

Hey John,

Actually Vibhor made a good point here , because we are overloading the same external interface it is better to put the most specific first in the first in nat order.

If you see below as we are doing static nat for our smtp server for smtp service that should be first in the order of nat flow that we you can determine/confirm using "show nat" command and you can change it by giving nat <number> or as you are already familer with asdm you can simply click on them to change the order.

I guess why we are seeing drop in acl is we only allowed smtp traffic on the outside interface going to SMTP_SERVER so if it's in the right NAT order only then it'll allow.

It's worth a shot , please try and let us know if its fixes the issue.

Thanks

Murali.

Thanks Vibhor and Murali,The

khyron1969 — Sat, 22 Nov 2014 23:52:05 GMT

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