marking VPN packets
datchcha
Member Posts: 265
forum,
Is there a way i can mark vpn packets on an ASA5505? I want to perform bandwidth based on port, but my traffic is going through the network via vpn tunnel.
Background: A point-to-point vpn tunnel, with ms-sql and port: 25 traffic. The ms-sql traffic is saturating the bandwidth of my vpn trunk.
Question: What would be the best way to limit this issue on the network products or a solution which would fit multipule topologies?
thanks.
Is there a way i can mark vpn packets on an ASA5505? I want to perform bandwidth based on port, but my traffic is going through the network via vpn tunnel.
Background: A point-to-point vpn tunnel, with ms-sql and port: 25 traffic. The ms-sql traffic is saturating the bandwidth of my vpn trunk.
Question: What would be the best way to limit this issue on the network products or a solution which would fit multipule topologies?
thanks.
Arrakis
Comments
-
Ahriakin Member Posts: 1,799 ■■■■■■■■□□If you mean tag the packets so that devices further down the line can also apply QOS then nope I don't think you can. You can only prioritize traffic within the ASA itself as either normal or high priority for the interface Qs. Your best bet would be to see if your next Switch/Router can do it for you (but then they'll have to be able to recognize ESP, presuming you're using IPSec).
Your best solution might be to limit the rate inside the ASA for your selected traffic, i.e. before it is encrypted/transmitted. It won't give you true QOS but you could define limits so it never saturates links beyond itself.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
APA Member Posts: 959If there are routers sitting behind the ASA's you could use qos pre-classify and shape the SQL traffic..... (rate-limit)
Qos Pre-classify allows you to use the QoS marking in the pre-tunnel headers.. you can also use the post-tunnel headers but if your shaping is based on IP addresses then the post-tunnel headers especially if using IPSec tunnel mode will have different IP addresses....
Hope this is of some help to you....
CCNA | CCNA:Security | CCNP | CCIP
JNCIA:JUNOS | JNCIA:EX | JNCIS:ENT | JNCIS:SEC
JNCIS:SP | JNCIP:SP -
datchcha Member Posts: 265Ahriakin wrote:If you mean tag the packets so that devices further down the line can also apply QOS then nope I don't think you can. You can only prioritize traffic within the ASA itself as either normal or high priority for the interface Qs. Your best bet would be to see if your next Switch/Router can do it for you (but then they'll have to be able to recognize ESP, presuming you're using IPSec).
Your best solution might be to limit the rate inside the ASA for your selected traffic, i.e. before it is encrypted/transmitted. It won't give you true QOS but you could define limits so it never saturates links beyond itself.Arrakis -
Ahriakin Member Posts: 1,799 ■■■■■■■■□□Ya know I was wrong. I didn't think the ASA preserved QOS markings when tunneling traffic as an endpoint. Apparently it will replicate any TOS or DSCP markings from the original to the VPN packet headers.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
-
APA Member Posts: 959that is what occurs for QoS with IPSec VPN's
the problem is ....if you use IPSec Tunnel mode the QoS markings are then based on the new IP headers inserted which have the IP address of the tunnel end points.... hence QoS pre-classify is needed to allow defined QoS policies at the interface level based on the original IP headers before IPSec encapsulation....
IPSec transport mode is fine as no new IP headers so QoS markings relate to the actual devices communicating...... Which means they get correct prioritization\shaping\policing when traversing the egress interface....
CCNA | CCNA:Security | CCNP | CCIP
JNCIA:JUNOS | JNCIA:EX | JNCIS:ENT | JNCIS:SEC
JNCIS:SP | JNCIP:SP