ASA ACL Question (SMTP and RDP)

[EricGoldsmith]

All,

I inherited an ASA 5510 and have very limited experience with ACLs.  There are two main problems I'm running into:

1. We have a multifunction device that sends scans as email but they never go out.  I attempted to make an access list to allow SMTP traffic but when they do pass the test runs when applied I lose Internet access.

2. It's the same issue but with RDP traffic.

Attached is the running config for the ASA.  Any help would be appreciated.

[Maykol Rojas]

Hi,

Unfortunately, I cannot see your config, can you tell me the following info?

Source interface

Source IP

Destination Interface

Destination IP

Then do the following:

packet-tracer input tcp 1025 3389

And paste the output.

Mike

[EricGoldsmith]

Thanks for replying.  Sorry it took so long to get back to you.  The information you asked for is below.

Source interface:  Ethernet 0/1

Source IP:  209.118.65.194

Destination Interface:  Ethernet 0/0

Destination IP:  172.16.0.1

Result of the command: "packet-tracer input outside tcp 209.118.65.194 1025 172.16.0.1 3389"

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   172.16.0.1      255.255.255.255 identity

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

Result:
input-interface: outside
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

[Jouni Forss]

Hi,

The Attachement file cant be opened. I think this is due to a problem on the forums that was on when you posted the original question/post. So I cant see your configuration unless you share it again

To my the "packet-tracer" output seem like you are targeting an ASA interface IP address perhaps? Is this true?

- Jouni

[EricGoldsmith]

Hi,

Yes it is targeting the ASA interface IP.  I'm not sure that everything is configured correctly since I just took this over and am learning on the fly.

Attached is the running config.  Thanks again for the help.

[Jouni Forss]

Hi,

I think the "packet-tracer" you were supposed to take was something that is coming from "inside" interface and heading "outside"

packet-tracer input inside tcp 172.16.0.100 1234 1.2.3.4 25

packet-tracer input inside tcp 172.16.0.100 1234 1.2.3.4 3389

These would show you if RDP and SMTP would go through the firewall from the "inside" to "outside". The source and destination IP address are naturally made up by me and might not be any actual device on a given network.

I dont see a problem with the current configurations.

You have a default PAT translation configuration

nat (inside,outside) source dynamic any interface

It will basically

• Do PAT translation by using the "outside" interface public IP address
• It does this for traffic from "inside" to "outside"
• Source address can be anything

You also have the following ACL

access-list inside_access_in extended permit ip 172.16.0.0 255.255.254.0 any

access-list inside_access_in extended permit tcp 209.118.65.192 255.255.255.252 172.16.0.0 255.255.254.0

This basically allows all TCP/UDP traffic from the LAN network of 172.16.0.0/23

The second line seems off to me as that kind of traffic wont be hitting the ACL and the public source network isnt located on your LAN.

Also this route command seems useless

route inside 172.16.0.0 255.255.254.0 192.168.1.2 1

Notice that the network you have the route for is the network that is configured for your "inside" interface.

Are you having problems with the configuration you attached?

- Jouni

[EricGoldsmith]

I ran both the tests and they came back allowing access.  The problem I'm having is coming from outside in.  When I attempt to RDP external it doesn't connect.  What do I need to make for the external network, if any, so that it should work?

[Jouni Forss]

Hi,

In the original post you were talking about connections that are initiated from your "inside" network to "outside" networks.

Do you at the moment have a need to access some device specifically from the Internet (behind "outside" interface)?

If this is the case then we would need to use Port Forward / Static PAT to make it possible for someone to connect to a device in your network with the public IP address you have on the "outside" interface.

And I guess that Port Forward / Static PAT is the only choice at this point since you only have a /30 size network on your "outside" interface so the only available IPs in that subnet are already used up.

At the moment any device on your "inside" network should be able to connect to Internet with no problems. For connections that are initiated from the "outside" networks you will need ACL and more importantly NAT configurations. Let me know how the situation is.

- Jouni

[EricGoldsmith]

Hi,

Yes everything internally works correctly.  I wanted to be able to RDP to the site when I'm not here but I have other ways of connecting and would rather not needlessly overcomplicate things.

Thanks for your help, I greatly appreciate it.

EG

[Jouni Forss]

Hi,

In the case you would want to get to some internal host with RDP from the Internet, then you could use the following configurations.

object network SERVER-RDP

host

nat (inside,outside) static interface service tcp 3389 3389

access-list outside_access_in remark Allow RDP connections

access-list outside_access_in permit tcp any object SERVER-RDP eq 3389

access-group outside_access_in in interface outside

If you have found the information helpfull, please rate

- Jouni