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

Problem with QOS bandwidth limiting

We have an Astaro V7 at our HQ, remote sites attached via VPN (not necessarily having astaro at their end).
We have a WSUS server at HQ and WSUS proxies at the remote sites, which regularly sync their data from HQ.
In order not to flood possibly small remote site uplinks, I wanted to cap bandwidth for such syncing to 100kbps.

For this I configured two Traffic Selectors:
HQ-WSUS -> Any -> Any
and
Any -> Any -> HQ-WSUS
I added a bandwidth pool to "Internet" interface with guaranteed 10kbps and upper bandwidth 100kpbs and both traffic selectors checked and enabled it ("green").

It seems that this does not work (I have an ongoing synchronization at a permanent rate of about 130kBps, i.e. about 10 times the allowed speed or the full bandwidth of that tiny remote link).

Do I need to enable global bandwidth limitations for my interfaces (under Network -> Quality of Service (QoS) -> Status) for things to work? I tried so, but no change.

I tried to add a bandwitdh pool to "Internal" interface with same settings and selectors, but this does not change anything, either.


This thread was automatically locked due to age.
  • I don't think the second traffic selector is necessary; in any case, it would only have an effect with the Internal interface, just as the first only has an effect when used with the External interface.  Assuming you aren't running the Astaro in bridge mode, QoS should work with the first selector applied to the External interface.

    If you have a DMZ or multiple networks connected through your Astaro, you might want to consider creating a new Network definition named, for example, "Internet" as 0.0.0.0/0 bound to the External interface.  Then, replace your traffic selector with 'HQ-WSUS -> Any -> Internet'.

    Cheers - Bob
    PS As AlanT points out below, I missed the fact that this is via VPN
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • When traffic is sent through a VPN tunnel, QoS can only see the traffic after it has been encrypted. This means that all it is able to see is IPSec traffic between the external addresses of the tunnel endpoints, and not the traffic inside the tunnel. Astaro has the ability to:
    a) apply QoS to packets with DiffServ bits set (TOS/DSCP) 
    b) tag the encrypted tunnel packet with the same DiffServ bits that are set on the original packet

    This way, you can apply QoS rules on traffic within an encrypted tunnel. This is commonly used in VOIP traffic, but unfortunately, I know of no way to enable diffserv tagging for WSUS traffic. 
    Instead, you may need to create QoS rules on the remote end of the tunnels, and put the same rules you created above on the internal interfaces at that end.
  • OK, I think this thread at least cleared up a few parts of bandwidth limiting etc. I had only vague notions of. To get things straight, 
    1) A traffic selector A->..->B always refers to the traffic. It does not matter which host originally initiated e.g. a TCP connection; thus it might refer to a download initiated by B as well as an upload initiated by A. This is of course also necessarily so in order to allow different limits in different directions.
    2) Traffic can only be shaped at the interface where it leaves the router. All is done by sending packtes in a possibly new order or delayed - after all you cannot control when an incoming packet happens to knock at your door (but isn't there the good old "source quench" ICMP message?)
    3) It would be nice to logically separate routing and tunnelling, i.e. a packet first leaves the (virtual) router and then enters the tunnel as transport medium. At least this idea would allow bandwidth limit to apply to tunneled traffic. However, this is not how it works. Apparently I was mislead by the fact that the forwarding decision ("yes/no") occurs before the tunnel and had imagined that the speed decision would happen at the same instance ("yes, immediately/yes, if you can/no, not at all")

    Anyway, thanks for the helpful input
  • Some module / method should be integrated to allow ASG admins to tag / retag traffic. Many providers are setup now with auto qos in their core switches which classifies and queue's traffic by diffserv code point value.

    The following is a very good read on modern QoS and how it applies to linux. Should provide a simple construct to do so on linux...

    http://mkr.oerks.de/ip-qos-magdeburg2001.pdf
  • feature.astaro.com

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • I know this isn't exactly what was asked, but Astaro added new Auto QoS features in 7.500, which are pretty cool.

    Now, under QoS settings per interface, there are two new checkboxes to enable:
    Download Equalizer:  If enabled, Stochastic Fairness Queuing (SFQ) and Random Early Detection (RED) queuing algorithms will avoid network congestion. In case the configured downlink speed is reached, packets from the most downlink consuming stream will be dropped.
    Upload Optimizer: If enabled, this option will automatically prioritize outgoing TCP connection establishments (TCP packets with SYN flag set), acknowledgment packets of TCP connections (TCP packets with ACK flag set and a packet length between 40 and 60 bytes) and DNS lookups (UDP packets on port 53). 

    I've played with these, and they make a HUGE difference on the overall performance when your pipe becomes congested. Worth taking a look at - especially if your connection ever hits 100% usage. You just need enable it on any external interfaces to see a difference.
  • ... Astaro has the ability to:
    a) apply QoS to packets with DiffServ bits set (TOS/DSCP) 
    b) tag the encrypted tunnel packet with the same DiffServ bits that are set on the original packet
    This way, you can apply QoS rules on traffic within an encrypted tunnel. This is commonly used in VOIP traffic...

    This sounds so promising to me, as I was trying to utilize Astaro for site-to-site VoIP communication via IPSec VPN channel with no luck so far.
    Would you guys please help me configure DiffServ on two Astaro (one at each location). The phone system located on separate networks at each site. It requires DiffServ configuration:
    DSCP (Hex): B8; DSCP: 46
    DSCP Mask (Hex): FC; DSCP Mask: 63
    SIG DSCP (Hex): 88; SIG DSCP: 34
    How should I configure the Astaro?