D'oh! Well, at least that matches my testing. Any thoughts for a work around?
Maybe a policy on the inside interface that matches traffic to the address pool designated for AnyConnect (or otherwise) clients? Although marking priority on an inbound policy will do nothing, no?
Perhaps a crude attempt to reserve bandwidth? Shape all traffic through the ASA down to x% of the available to leave a gauranteed y% for VPN use? Again I guess this will need to be applied on the inside interface...
For VPN specific traffic, since it will be traversing through the Internet, QoS is not that necessary as the Internet is normally the bottle neck anyway. I guess if your ASA is quite a busy ASA, it will ensure that the VPN traffic gets prioritise but as soon as it hits the internet, there is nothing you could do.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...