Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

QOS grabbing those return packets

Hi Guys,

I have a QOS question. Im trying to QOS return packets with random port numbers.

I'm doing basic outgoing dynamic NAT overloading to an outside address. (DSL)

I'm also doing some static NAT to redirect connections to from the outside address to my web server.

I have a QOS policy on the outgoing DSL interface to classify the packets into one of three queues. (high, medium, low speed with different shaping / priorities on each. The QOS packet matching is handled by mostly by nbar

One of the main packets I prioritize is RDP (MS Remote Desktop).

I use the custom NBAR line "ip nbar custom remote_desktop dest tcp 3389"

This works great.. every time I make an RDP connection from my local lan to somewhere on the internet the packets get correctly classified and all is good.

The problem begins when I RDP INTO my network from the internet.

The return packets are not being QOS'd

Here's the packet flow

* The packet with TCP 3389 dest hits my router from the internet dialer interface.

* The router does not care about QOS in any way at this point as I only have outgoing QOS enabled.

* The packet is natted to the internal server

* The server turns around and replies to the packet.... but... as with most TCP sessions, the reply uses random port numbers to respond.

* The reply packet reaches the router and the router places it into the default QOS group as the port does not match 3389

So does anyone have any idea how I can QOS the return packets?

Here's a config snippit (using an 1800)


ip nbar custom remote_desktop dest tcp 3389


class-map match-any qos-high

match protocol citrix

match protocol ssh

match protocol dns

match protocol telnet

match protocol snmp

match protocol dhcp

match protocol remote_desktop

class-map match-any qos-low

match protocol smtp

match protocol ftp

match protocol exchange

match protocol printer

match protocol nntp

match protocol secure-ftp

match protocol rcmd

class-map match-any qos-limit

match access-group qos-limit


policy-map qos-policy-internet

class qos-low

(do lots of things in here)

class qos-high

(do lots of things in here)

class qos-limit

(do lots of things in here)

class class-default


interface VLAN1

description Local LAN

ip address

ip nat inside


interface Dialer1

description Internet Connection

ip nat outside

ip inspect insp-fw-in in

ip inspect insp-fw-out out

service-policy output qos-policy-internet


ip nat inside source route-map NAT-MAP interface Dialer1 overload

ip nat inside source static tcp 3389 interface Dialer1 3389


ip access-list extended nat-outbound

remark NAT ACL

remark Permitted addresses to NAT

permit ip any

remark External IP Address does not need natting (dont log its attempts)

deny ip host <outside IP> any

remark Deny All and log all other traffic trying to NAT

deny ip any any log


route-map NAT-MAP permit 1

match ip address nat-outbound


I can think of a few ways to perform this QOS including using reflexive access lists or tag the packets on the windows server but that all seems hard. There must be an easy way to do this.

Any ideas would be appreciated.




Re: QOS grabbing those return packets


The reply packets will be destined to a ramdom port because the original connection came from a random port. But what about their source address - won't that be TCP 3389? So couldn't you match the TCP source port with an extended access list?

ip access-list fromRTD

 permit tcp any eq 3389 any

Kevin Dorrell


New Member

Re: QOS grabbing those return packets


I had a look at that. It all seems to depend on the protocol being used. Some services use a static source port but most come from a random.

Unfortunately RDP seems to have a random port for both source and dest.


Re: QOS grabbing those return packets

In that case, it will be necessary to do some deeper protocol inspection, rather like is done for passive FTP. I suppose there isn't a pre-defined nbar definition for RDT?

Kevin Dorrell