QoS over IPSec

The only traffic between the two Astaros is IPsec, so the only place you can affect bit rates is at the internal interface where you can limit/prefer traffic towards things inside the network.

You say they slow the connection.  Rather than trying to strangle the printer traffic, it might be better to focus on preferring the traffic you want.  What desired traffic is slowed?

Cheers - Bob

There is a 2 MBit SDSL Connection at the Branch office side. When trey start print jobs (e.g. 20 MB size), these print jobs are using the whole bandwith. So we get problems with the citrix/rdp connection. 
But how can I priorize these pakets(via IPSec) ? I got the same problem as with the printer paket regulation.

Regards 
rockstaddy

Hi rockstaddy,

I think you have to consider the bandwidth optimization of the print jobs using specialized RDP/citrix printing software.
Try a solution like this: ThinPrint

Bye

Isn't that what we got ASG for?

Rather than add a whole bunch of other software can we not teach ASG how to regulate it?

Tom

I suspect that a bandwidth pool on the Remote Astaro's Internal interface favoring RDP traffic to the users in the remote location would resolve the issue, but Rockstaddy hasn't given us enough detail to do anything other than guess.

Cheers - Bob

I guess it's the same, if i try to regulate the print traffic trough the branch office, or if I priorize the RDP/Citrix traffic from the branch the the main office, isn't it?!

@BAlfson: I tried the version with the regulation. All traffic from the printserver (main office) to the branch office network regulated to upper Bandwith 200 KBit. I activated QoS on the internal and external interface (I guess only internal is needed).

regards
rockstaddy

One can't apply QoS to traffic in the VPN tunnel (opened a case on it not too long ago, and that was the answer).  You can limit what hits the internal interface of the Astaro, but once it's in the tunnel, you can't prioritize one service over the other when it flows over the VPN.  You can set it to forward the TOS (DSCP?) tags on the packets, but they don't affect the bandwidth allocation within the VPN.

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