This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

QoS over IPSec

Hi guys,
is there still a way to realize QoS trough a IPSec tunnel?
Backround:
A branch office is connected to the main office via IPSec VPN. ASG on both sides. All clients are working over citrix (server at the main office). When they start big print jobs, they slow down the connection. I wanted use QoS to regulate this, but it dosen't work. Now I heard that QoS dosen't work through a tunnel. Is this true? Is there any other way to regulate this?
Thanks for all kind of help...


This thread was automatically locked due to age.
Parents
  • Actually, Bruce, I don't think you can limit/favor explicitly what hits the Internal interface, as "shaping of inbound traffic is optimized internally by various techniques such as Stochastic Fairness Queuing (SFQ) or Random Early Detection (RED)."

    That's the reason one can't explicitly favor/limit particular services inside a VPN tunnel - by the time the traffic is ready to leave the External interface, everything looks like IPsec traffic headed to the External interface of the other site - all of the packets are '[IP of local External interface] -> IPsec -> [IP of remote External interface]'.

    Rockstaddy, it's still not clear to me exactly what your situation is; which traffic in which direction is slowed and which traffic in which direction seems to be the cause.  Do I understand correctly that you are having slowness because there isn't enough bandwidth for "Responses by the Citrix servers" to "Users in the remote location"?  And that you think that this is because "Print-streams from the Citrix servers to printers in the remote location" are filling the bandwidth?  If so, are all of these packets RDP packets?

    I also am not sure what you tried, so my guess might still be an option.  Did you create a bandwidth pool on the Internal interface of the remote location?  On that, did you limit traffic from the Citrix servers to the printers in the remote location to 200Kb?

    If you have a second WAN connection, then it would be possible to put the printer traffic on a second interface.  It's my impression that you can't have two interfaces connected to the same subnet, so I guess that you can't use another interface with the same WAN connection.

    Cheers - Bob
Reply
  • Actually, Bruce, I don't think you can limit/favor explicitly what hits the Internal interface, as "shaping of inbound traffic is optimized internally by various techniques such as Stochastic Fairness Queuing (SFQ) or Random Early Detection (RED)."

    That's the reason one can't explicitly favor/limit particular services inside a VPN tunnel - by the time the traffic is ready to leave the External interface, everything looks like IPsec traffic headed to the External interface of the other site - all of the packets are '[IP of local External interface] -> IPsec -> [IP of remote External interface]'.

    Rockstaddy, it's still not clear to me exactly what your situation is; which traffic in which direction is slowed and which traffic in which direction seems to be the cause.  Do I understand correctly that you are having slowness because there isn't enough bandwidth for "Responses by the Citrix servers" to "Users in the remote location"?  And that you think that this is because "Print-streams from the Citrix servers to printers in the remote location" are filling the bandwidth?  If so, are all of these packets RDP packets?

    I also am not sure what you tried, so my guess might still be an option.  Did you create a bandwidth pool on the Internal interface of the remote location?  On that, did you limit traffic from the Citrix servers to the printers in the remote location to 200Kb?

    If you have a second WAN connection, then it would be possible to put the printer traffic on a second interface.  It's my impression that you can't have two interfaces connected to the same subnet, so I guess that you can't use another interface with the same WAN connection.

    Cheers - Bob
Children
No Data