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.
  • Wait a minute!  I thought all of the data and voice traffic was going through the same tunnel!  Try this:
    • Disable the SSL VPN
    • Add the data networks to the IPsec tunnel

    Does it work now?

    Having two different VPN connections is a different solution than using DSCP.  Using DSCP allows you to prefer specific traffic in one tunnel.  With an IPsec tunnel and an SSL tunnel, you prefer the traffic in the SSL Tunnel by creating a traffic selector of 'External (Address) -> HTTPS -> {other site}' and creating a Bandwidth Pool with it on the External interface.

    Cheers - Bob
    PS Great post, Costak.  Precise information presented clearly.  Thanks for helping to add to the combined knowledge here.
  • Both voice and data exist in the same IPSec channel, I know this for sure. It looks like the control units of the phone system do exchange some non-voice information as well, so if I disable DSCP, the voice quality will be very poor.

    I recently did one more change to the configuration:
     * removed the VoIP over IPSec VPN 26: External --> IPSec --> [Public IP of the other Astaro]; DSCP-Bits value: 26 traffic selector.
    These three are remaining:
    * 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
    So far it looks better than before (!) I monitor this all day long with IP Office System Status program that came with the phone system.

    With DSCP enabled, I think, this may work through the same VPN channel, I agree, but I can't test it right now, as this may impact the business.

    I will post the result of testing by the end of today.

    Thank you very much Bob for your great help!
  • No, unfortunately, the voice transmission still loses packets. The amount of lost is in the range of 3.5 to 8%, not every conversation though. People still complain...

    I don't believe, Internet connection fluctuates below 640kbit/s.

    What else can I do?

    What will happen, if I reduce the declared bandwidth (Network/QoS/Status) of External from 1536 to 1024 without limiting the uplink?
  • In general, you should not allocate more than 95% of the total available bandwidth.  If you have a T-1, then 1536 is the right number.

    The article I read said that only a small reservation was needed for SIP (value: 26), but it did specify a reservation.

    Do you also have QoS activated on the Astaro on the other end?  On both ends, do you have the 'Download Equalizer' selected?  If both sides have bandwidth pools to guarantee outbound VoIP traffic, then it would be interesting to see whether it works better to have 'Download Equalizer' checked or unchecked on both sides.

    Can you tell what kinds of packets are getting lost?

    Cheers - Bob
  • Both firewalls configured "symmetrically".

    Both have 'Download Equalizer'. I let it run unchecked for about 20 minutes, the lost package count got a significant increase: up to 84%! Turned it back on (both ends).

    Regarding the type of packets being lost, unfortunately, I have no tool to see it...
  • Anything in the Intrusion Prevention log on either side?
  • Bingo!

    Site1, Intrusion Prevention System log (Very small excerpt):
    2010:07:20-14:57:05 firewall-1 ulogd[3293]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" seq="0" initf="eth7" dstmac="00:1a:8c:15:8c:97" srcmac="00:e0:07:85:3d:a2" srcip="192.168.101.15" dstip="192.168.100.15" proto="17" length="200" tos="0x18" prec="0xa0" ttl="99" srcport="49160" dstport="49160" 
    2010:07:20-14:57:06 firewall-1 ulogd[3293]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" seq="0" initf="eth7" dstmac="00:1a:8c:15:8c:97" srcmac="00:e0:07:85:3d:a2" srcip="192.168.101.15" dstip="192.168.100.15" proto="17" length="200" tos="0x18" prec="0xa0" ttl="99" srcport="49160" dstport="49160" 
    2010:07:20-14:57:07 firewall-1 ulogd[3293]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" seq="0" initf="eth7" dstmac="00:1a:8c:15:8c:97" srcmac="00:e0:07:85:3d:a2" srcip="192.168.101.15" dstip="192.168.100.15" proto="17" length="200" tos="0x18" prec="0xa0" ttl="99" srcport="49160" dstport="49160" 
    2010:07:20-14:57:07 firewall-1 ulogd[3293]: id="2105" severity="info" sys="SecureNet" sub="ips" name="UDP flood detected" action="UDP flood" fwrule="60013" seq="0" initf="ipsec0" srcip="192.168.100.15" dstip="192.168.101.15" proto="17" length="200" tos="0x18" prec="0xa0" ttl="98" srcport="49154" dstport="49154" 

    Site2, Intrusion Prevention System log:
    [Nothing related]

    The 192.168.100.x and 192.168.101.x are the networks with IPO control units only. The time is exactly one of those when the loss of packets was reported.

    Does it mean that traffic was blocked?
  • On site #1 forgot to update Source/Destination exceptions in Intrusion Prevention System after configuring the subnets for IP Office.
    Updated... Continue monitoring...
  • Problem persists.
    Just tried to load the sites with some significant web traffic and did a phone call to the other site, it was poor [:@]

    Does it make sense to create a few new traffic selectors like:
    * VoIP from External 46: External --> Any --> IPOfficeSubnet; DSCP-Bits value: 46
    * VoIP from External 63: External --> Any --> IPOfficeSubnet; DSCP-Bits value: 63
    * VoIP from External 34: External --> Any --> IPOfficeSubnet; DSCP-Bits value: 34

    and use them as a new bandwidth pool at internal IPOfficeSubnet interface?
  • Are the VoIP subnets listed in 'Local networks' for Intrusion Prevention on both sides?  Once you get IPS to quit eating VoIP packets, it might be worth trying with 'Download Equalizer' disabled again.  The way I understand it, it tosses random packets in an effort to be "fair" to all traffic - I think you want to be unfair to non-VoIP packets, but I don't know if the 'Download Equalizer' knows that.

    I can't imagine that it would help to shape traffic leaving the Internal interface.

    Cheers - Bob