Today we cannot do QoS on traffic within IPSec tunnels; this is something that we’re investigating for future potential.
but,Technically we can still apply QoS to encrypted IPSec traffic itself on the ingress/egress interfaces that terminate the tunnel, but that would apply the controls to the tunnel as a whole.
We also copy DSCP bits from tunneled data packets to the IPSec packet to ensure that networks can give the proper QoS to the tunneled packet
Aditi has attempted to answer your question, can you elaborate a bit more on what you are requesting? Do you simply want the ability to prioritize some traffic over other traffic but still share the same peer gateway and phase-2 security associations, the ability to create separate phase-2 security associations for different traffic and apply different priorities for these different P2 SAs, or something else?
The SRX automatically copies the DSCP bits from the original packet to the IPsec packet so that the network devices between the two VPN gateways can provide the appropriate processing on the encrypted traffic. In this way, we should be able to use this to apply QoS for ipsec traffic…even though we don’t support Qos on st0. We can do ingress policing on the plaintext traffic, assuming the traffic is not looped back into the device.
if you want all esp traffic to have higher priority over other traffic , you can but an egress firewall filter (mf filter) on the external interface on which ipsec is egressing with a match term of "from protocol 50" and a then term to a forwarding class you want to assign esp traffic.
create your scheduler map and apply it on teh external interafce too.
In the particular case of branch SRX devices, it is also possible to provide per tunnel queuing, shaping and RED using virtual channels.
While it is not possible to apply QoS on tunnel interfaces directly, virtual channels can be used to achieve the same end result
In simple terms, virtual channels allow you to create a group of queues, similar to what you would get when doing per unit schedulers, but with all those queues being independent of any interface. In a normal configuration each logical or physical interface has a set of queues and traffic is queued based on the egress interface where is routed to. When using virtual channels, a firewall filter is used to associate traffic to a group of queues (i.e. virtual channel).
When doing IPSec you can use this to obtain a per tunnel QoS, in the following way: 1) Traffic is classified on the ingress interface (using standard BA or MF classifiers). This classification changes the packet's meta-header and it is maintained after the packet is encapsulated in IPSec 2) The packets are encapsulated and encrypted 3) A firewall filter can be used on the egress interface matching the remote address of the IPSec tunnel (so it identifies all packet from the same IPSec tunnel) and associates all packet from the same tunnel to a given virtual channel
I've attached a sample configuration that hope it will help clarifying some of these concepts.
