Cisco ASA – Allowing external access to a secure server via RDP

You've got it right; the destination on SMTP traffic is going to be the server that it's attempting to send to, which could be anywhere.

Building the rule on the inside interface was the correct thing to do, as it's controlling traffic that's coming into the inside interface from your internal network.

Should be good to go!

To begin -- simple is not a word that should be used to describe Quality of Service. The entire word itself is a loaded term.

Instead of rehashing a lot of details about ASA QoS here, reference this answer.

Below is the ASA 8.4 CLI necessary to create a priority queue and handle a specific volume of calls based on a certain bitrate.

• Understand that policing only happens in the out direction on the ASA interface on which it is configured.
• Based on G.711 voice codec @ 87.5 kilobits per second Ethernet layer 2 data rate (includes all overheads)
• Based on a 218 byte average complete Ethernet frame size per voice payload interval. For more see this.
• Based on a need to handle 10 calls at a time (87.5 Kilobits per second * 10 = 875 Kilobits per second). Note that this is only in the out direction. We can't "prioritize" incoming traffic unless you control that path as well.
• Based on a maximum delay of 200 milliseconds between the VoIP endpoints.
• Using an extended access-list with source and destination IP for matching VoIP traffic. Another option is to use IP DSCP if the phones are marking. By using a simple ACL we can verify the service-policy later on with show service-policy flow.

Numbers used for queue-limit and tx-ring-limit determined using the worksheet in the configuration guide and then massaged. The numbers used here could be drastically different depending on your requirements.

access-list voip-traffic remark [[ match inside to Call Manager ]]
access-list voip-traffic extended permit ip 10.0.0.0 255.255.255.0 host 1.2.3.4

priority-queue outside
queue-limit 100  ! based on factors listed earlier, very important number
tx-ring-limit 5  ! based on factors listed earlier

! create class-map

class-map voip-class
 match access-list voip-traffic

! create policy-map, advise not using a global policy

policy-map outside-policy
 class voip-class
  priority

! assign policy to interface, in this case outside

service-policy outside-policy interface outside

• In this case the outside-policy can be assigned to the outside interface and you can still implement a global-policy that is by its nature assigned to the outside interface as well -- as long as there are not QoS actions on any of the class's listed in the global-policy. The QoS actions of the outside-policy will be in effect and the non-QoS actions (inspects, etc.) of the global-policy will stay effect.

You can view priority-queue statistics with show priority-queue statistics outside.

You can verify that the traffic itself will hit the priority queue with a command like show service-policy flow host 10.0.0.100 host 1.2.3.4 which will show you how the existing service policies on all interfaces would react to the traffic specified.