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 for VoIP via IPSec VPN

Hello,

I couldn't find an answer to the subject question. My company has two locations, both protected by Astaro ASG220 (with separate Internet access):
Site1: 3 mbit/s (symmetrical)
Site2: 1.5 mbit/s (symmetrical)

There are two parallel VPN channels for site-to-site (s2s):
1. SSL VPN, connecting two remote sites for user data exchange, etc.
2. IPSec VPN, connecting two remote networks with Avaya IP Office 500 phone system equipment (basically, only two control units facing each other over the VPN via their VoIP interfaces).

The Avaya Phone sytem configured with the following DiffServ settings:
DSCP (Hex): B8; DSCP: 46
DSCP Mask (Hex): FC; DSCP Mask: 63
SIG DSCP (Hex): 88; SIG DSCP: 34
It requires 8 channels by 64 kbit/s per channel for s2s connection bandwidth. I was suggested by the phone system supplier to use 8 x 80 = 640 kbit/s calculation.

Two VPNs and Internet traffic obviously compete with voice traffic at External interfaces of each Astaro.

Here is what I did with great help of Bob (BAlfson):

1. On External interfaces (Network/Quality of Service), I activated QoS on External:
Site1: Downlink kbit/s: 3072; Uplink kbit/s: 3072; Download Equalizer, Upload Optimizer (Limit Uplink unchecked)
Site2: Downlink kbit/s: 1536; Uplink kbit/s: 1536; Download Equalizer, Upload Optimizer (Limit Uplink unchecked)

2. Created the following traffic selectors (not too sure if this part is right):
 * VoIP over IPSec VPN 46: External --> IPSec --> [Public IP of the other Astaro]; DSCP-Bits value: 46
 * VoIP over IPSec VPN 26: External --> IPSec --> [Public IP of the other Astaro]; DSCP-Bits value: 26
 * VoIP over IPSec VPN 63: External --> IPSec --> [Public IP of the other Astaro]; DSCP-Bits value: 63
 * VoIP over IPSec VPN 34: External --> IPSec --> [Public IP of the other Astaro]; DSCP-Bits value: 34

3. On External interface (of each Astaro) created Bandwidth Pools:
 * VoIP over IPSec VPN. Bandwidth (kbit/s): 640 kbit/s, including all four traffic selectors above.

To test this, I started copying a large file across the sites, and phoned somebody on the other site. It was not very good, some packets were dropped (intermittent voice), some packets were disordered (pro-pa-gate would sound sometimes like pro-gate-pa). But overall, it was much better than without any QoS.

I guess, I need to define some additional traffic selectors, according to the DiffServ specs. It is also important not to add any non-VoIP traffic selectors to the Bandwidth Pools.

I know, the solution exists, we just have to find it, and it would be a great knowledge for everyone. I would greatly appreciate any help, in particular, how to configure DiffServ on Astaro.


This thread was automatically locked due to age.
  • I've just skimmed the thread, but the traffic selectors you initially set look like you were on the right track. Essentially you want to apply QoS rules to guarantee bandwidth for VOIP as it is leaving the external interface of each firewall (outbound voice stream), and again as it is leaving the internal interface of each firewall (inbound voice stream). 

    When VOIP traffic is leaving the external interface, it is within the encrypted IPSec tunnel, and can't be recognized as VOIP traffic, except by TOS or DSCP bits. Make sure that Site to Site VPN >> IPSec > Advanced > Copy TOS (Type of Service) value is enabled. By default it isn't. You can cheat if your tunnel only handles IPSec traffic, and just use the IPsec definitions in your traffic selector.

    When traffic is leaving the internal interface, the QoS maximum available bandwidth for the internal interface is probably set to the full link speed(100Mbps or 1Gbps). This won't work unless your internet speed matches your LAN speed. You will need to set the internal interface bandwidth speeds to reflect your internet available bandwidth speeds, so that the QoS engine will know when it needs to kick in, and guarantee bandwidth for VOIP traffic. If it thinks you have 100Mbps, but you only have 10 Mbps of internet speed, and you're using all of it, then the QoS engine will still think that you have 90 Mbps of capacity left, and never kick in.
  • Thanks for chiming in, Alan!

    When VOIP traffic is leaving the external interface, it is within the encrypted IPSec tunnel, and can't be recognized as VOIP traffic, except by TOS or DSCP bits. Make sure that Site to Site VPN >> IPSec > Advanced > Copy TOS (Type of Service) value is enabled. By default it isn't. You can cheat if your tunnel only handles IPSec traffic, and just use the IPsec definitions in your traffic selector.

    So, I bet this is the real problem Costak is having, and that QoS with DSCP would have been impossible with the SSL site-to-site.

    When traffic is leaving the internal interface, the QoS maximum available bandwidth for the internal interface is probably set to the full link speed(100Mbps or 1Gbps). This won't work unless your internet speed matches your LAN speed. You will need to set the internal interface bandwidth speeds to reflect your internet available bandwidth speeds, so that the QoS engine will know when it needs to kick in, and guarantee bandwidth for VOIP traffic. If it thinks you have 100Mbps, but you only have 10 Mbps of internet speed, and you're using all of it, then the QoS engine will still think that you have 90 Mbps of capacity left, and never kick in. 

    This confuses me a bit. I understand that QoS for VoIP traffic leaving the Internal interface would use a traffic selector for the VoIP ports, and wouldn't require the use of DSCP values. However, the VPN travels on a 1.5Mbps connection, so why would QoS for VoIP packets have any effect applied to the 100Mbps Internal connection unless over 98.5Mbps of its bandwidth were being used because of local traffic?

    Cheers - Bob
  • Astaro only applies QoS rules when packets leave an interface. Incoming packets arrive on one interface, but a QoS rule cannot be applied until it is leaving another interface. By slowing the packets of some sessions as they leave an interface, Astaro can limit the transfer rate of some sessions, and make bandwidth available for others.
  • Thank you so much guys for your great help!

    Eventually, my phone system registers no packets being lost!
    However, when I did testing, I generated a high volume Internet traffic at both sites, and phoned to the other site again. There was no packets missed or disordered, but for some reason, voice was like a low bit rate sound. Imagine a sound with bit rate of ~8 kbit/s... Under normal load, sound is clear. I spoke to the phone system supplier, the codec is G.711 ULAW 64k, and it doesn't change the compression, it is always 64k, so it has nothing to do with this.

    Maybe I did my traffic selectors wrong?

    Here is my configuration now (identical for each site):

    1. Site-to-Site VPN / IPSec / Advanced: Copy TOS (Type of Service) value SELECTED!

    2. The declared bandwidth of the IPOfficeInternal interface has been reduced to match the Internet connection speed.

    3. External interface traffic selectors (used to create External ITF Bandwidth Pool):
     - VoIP over IPSec VPN 46: External --> IPSec --> [Public IP of the other Astaro]; DSCP-Bits value: 46
     - VoIP over IPSec VPN 63: External --> IPSec --> [Public IP of the other Astaro]; DSCP-Bits value: 63
     - VoIP over IPSec VPN 34: External --> IPSec --> [Public IP of the other Astaro]; DSCP-Bits value: 34

    4. Internal interface traffic selectors (used to create IPOfficeInternal ITF Bandwidth Pool):
     - VoIP local 46: IPOfficeInternal --> Any --> IPOfficeNetwork; DSCP-Bits value: 46
     - VoIP local 63: IPOfficeInternal --> Any --> IPOfficeNetwork; DSCP-Bits value: 63
     - VoIP local 34: IPOfficeInternal --> Any --> IPOfficeNetwork; DSCP-Bits value: 34

    How does this co-relate with the phone system DiffServ specification:
    DSCP (Hex): B8; DSCP: 46
    DSCP Mask (Hex): FC; DSCP Mask: 63
    SIG DSCP (Hex): 88; SIG DSCP: 34


    I set the traffic selectors just by guessing. Did I do it right? I hope, here is the source of the LAST problem.
  • Sorry, forgot to add:
    Both External and IPOfficeInternal interfaces have these unchecked:
     * Download Equalizer - unchecked
     * Upload Optimizer - unchecked
    I tested with these being ON and OFF, the voice quality was better with "OFF" (under the same other conditions: high volume Internet traffic).
  • Bob, I just re-read your question, and I didn't answer you very well. 
    In my first post, I said:
    You will need to set the internal interface bandwidth speeds to reflect your internet available bandwidth speeds, so that the QoS engine will know when it needs to kick in


    What I should have also said, was that you set the values in Quality of Service (QoS) > Status, by editing the internal interface. Set the upload and download bandwidth to reflect the internet available bandwidth. If you have a 2Mbps down, 1Mbps up internet connection, then set the internal bandwidth to be 1Mbps down, and 2Mbps up. That way, QoS will know how much bandwidth is being used, and can guarantee bandwidth when necessary.
  • Costak, is voice low quality in both directions, or does the other end hear the sound fine, but you hear low quality?
  • That's exactly what it is, Alan.
    Under a heavy concurring traffic, one site has a brilliant clear voice while the other site has ~8kbit/s. There is no difference, who initiated the call.
  • Under Network>> QoS> Status, what bandwidth is set for your Internal interface?
  • Site1:
    External:
     * Downlink kbit/sec: 3072
     * Uplink kbit/sec: 3072
    IPOfficeInternal
     * Downlink kbit/sec: 3072
     * Uplink kbit/sec: 3072

    Site2:
    External:
     * Downlink kbit/sec: 1536
     * Uplink kbit/sec: 1536
    IPOfficeInternal
     * Downlink kbit/sec: 1536
     * Uplink kbit/sec: 1536

    Site1 has problem with voice quality all the time.