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 and VPN

Am about to turn on QOS to give a select subgroup of users (3?) top bandwidth priority for their fat client application that connects to a remote server.

While I would only pick one of these to set, I could configure the QOS either by user IP, destination IP or service in case one of those is superior for the VPN aspect I'm about to bring up.

The users have to launch an application-provided VPN client before starting the application.

From the second to last line in https://support.astaro.com/support/index.php/Using_QoS :

"QoS only works on physical interfaces. This means that VPN tunnels are troublesome or impossible to QoS."

Does this line mean QOS absolutely won't work for us in this instance? 

(Just giving the prioritized users priority for all of their traffic wouldn't do the trick?)


My other concern is that while we control things at our end (IP etc), the other side could change IPs or ports at any time. So I want whatever rule is setup to minimize future changes. Just by user ip is nice but doesn't limit those users from their wasteful traffic. Configuring by destination IP or port/service might be a problem given the VPN piece, don't know.

Should destination IP turn out to be the best way to do this, assume the host side has a range of IPs (not just 1), for security won't reveal what they all are, and we are willing to make a overly broad rule as the lesser of two evils. Then would Network be the best definition type to use? I'm assuming the overly broad subnet mask we'd make up need not match what the host is actually using as long as what we set it ended up broader than theirs (covered all of their IPs)?  I ask in case I'm unable to obtain a specific DNS group setting (that would seem to be the most preferable) when I ask our sometimes uncooperative host.

Please confirm which interface gets the rule as well.

Hope that makes sense. Glad to clarify if not.

Happy New Year.


This thread was automatically locked due to age.
Parents
  • ShrewSoft VPN client Access Manager.
    FQDN - Possibly if we weren't using the VPN. However with it, once the tunnel is up, the application connects via a 192.168.x.x address at present. Feel free to upsell the benefits of getting a FQDN out of the host, I just have to hedge for that not working out too.
    The only VPN use at present is for this specific application, so others=no. There is a small chance of others connecting to the remote server's IP, but negligible at present.

    Here's the thing. As long as this traffic isn't de-prioritized (I think other dumb traffic is winning out too often now) I am hopeful I should only have to allot 1/6th of their bandwidth for this prioritized access.

    I am willing to ignore download traffic coming to us (inbound emails, email bombs), with the exception of non-prioritized traffic someone initiated here such as a video download.

    Astaro 7.511
Reply
  • ShrewSoft VPN client Access Manager.
    FQDN - Possibly if we weren't using the VPN. However with it, once the tunnel is up, the application connects via a 192.168.x.x address at present. Feel free to upsell the benefits of getting a FQDN out of the host, I just have to hedge for that not working out too.
    The only VPN use at present is for this specific application, so others=no. There is a small chance of others connecting to the remote server's IP, but negligible at present.

    Here's the thing. As long as this traffic isn't de-prioritized (I think other dumb traffic is winning out too often now) I am hopeful I should only have to allot 1/6th of their bandwidth for this prioritized access.

    I am willing to ignore download traffic coming to us (inbound emails, email bombs), with the exception of non-prioritized traffic someone initiated here such as a video download.

    Astaro 7.511
Children
No Data