Qos VPN-IPsec

Discussion in 'Cisco' started by link, Jan 21, 2009.

  1. link

    link Guest

    Perhaps you can help me :)

    We have various remote offices with Voip(Asterisk) connected with
    VPN´s (IPsec). This is the topology in all remote offices:

    LAN (VLAN DATA & VLAN VoIP) – Firewall Fortinet (VPN´s Ipsec) – ROUTER
    (Cisco 1800 Series)

    I need to do Qos in the Router Cisco (fortinet doesn't have Qos) but
    the packets that arrived to the router are encrypted by Fortinet
    (IPsec). How could I apply Qos to encrypted traffic to prioritize VoIP
    traffic in these routers??

    Best Regards,
     
    link, Jan 21, 2009
    #1
    1. Advertisements

  2. link

    bod43 Guest

    Firstly, you can only prioritise outbound traffic, just
    in case you had not noticed that:)

    Unless the fortinet can set some QoS bits in the L3 DS byte
    or the L2 CoS bits then you can't.

    Oh maybe you can?!

    Voice payload packets tend to be the same length and different
    from most data packets so you could classify them on the
    length and very probably get the effect that you wanted
    almost all of the time or more.
    Each codec will produce voice packets of a particualr length
    and I am pretty sure that the IPSEC header is always the
    same length for a particular length input packet.

    Another approach would be to consider putting then in
    a diffrent IPSEC tunnel with at least one different end
    address. Perhaps if you arrange to get the packets to the
    fortigate with the QoS bits set it will copy them
    to the new IPSEC header. This is the cisco behaviour I
    believe as long as the input port is configured to "trust QoS".

    Finally you might want to look at IPSEC Tunnel mode
    vs Transport mode. One of these I think preserves the
    IP header.

    This all depends on getting QoS going on the 1800. I have
    had variable luck with 877 but maybe the 1800 has a more
    complete implementation?
     
    bod43, Jan 21, 2009
    #2
    1. Advertisements

  3. link

    bod43 Guest

    You might also move the VPN to the cisco. This would
    require a crypto feature set and I am not sure of the 1800
    crypto performance.
     
    bod43, Jan 21, 2009
    #3
  4. link

    link Guest

    "Another approach would be to consider putting then in
    a diffrent IPSEC tunnel with at least one different end
    address. Perhaps if you arrange to get the packets to the
    fortigate with the QoS bits set it will copy them
    to the new IPSEC header. This is the cisco behaviour I
    believe as long as the input port is configured to "trust QoS". "

    I have different IPSEC tunnels for data and voice.

    How could I config Qos in Cisco Router to apply more priority to IPSec
    voice ??
     
    link, Jan 21, 2009
    #4
  5. link

    bod43 Guest

    There is the possibility we are not on the same
    wavelength here. I meant by seperate tunnels,
    having different IP addresses for the endpoints.

    If that is the case you could classify the traffic on the different
    IP addresses then do the recommended LLQ.

    What kind of outside interface do you have?
     
    bod43, Jan 21, 2009
    #5
  6. link

    link Guest

    In have Serial Interface. 2Mbps point to point.
     
    link, Jan 21, 2009
    #6
  7. link

    bod43 Guest

    I should imaging that QoS will work on that without
    problems. I have never tested it though.
     
    bod43, Jan 21, 2009
    #7
  8. link

    link Guest

    Ok, I will try it with LLQ and ip destination.

    Thanks!!
     
    link, Jan 21, 2009
    #8
  9. link

    link Guest


    In the command -> match destination-address mac

    I have to put MAC of the other Fortinet??

    thanks
     
    link, Jan 21, 2009
    #9
  10. link

    bod43 Guest

    no.

    You are obviously new to this. MAc-addresses
    are only 'valid' on a single ethernet hop.

    Are you sure that you can differentiate the voice
    traffic using the IPSEC peer's ip addresses?

    You would want to match dest IP or source IP or both

    *IF* you can indeed differentiate the traffic from the
    tunnel endpoint addresses (ipsec peers).

    something like - from memory mostly so may be errors

    class-map CM.voice
    match access-group ACL.CM.voice

    ip access-list ext ACL.CM.voice
    permit ip host ipsec.source.for.voice host ipsec.dest.for.voice

    policy-map PM.voice
    class CM.voice
    priority 300 ! 300k for voice
    set dscp ef ! if you like, just in case someone somewhere cares

    int se 0
    service-policy PM.voice

    Note:-
    "priority" provides absolute priority for the 'voice'
    *AND*
    limits 'voice' to 300k

    You need to work out how much to allow for the voice traffic.
     
    bod43, Jan 21, 2009
    #10
  11. link

    link Guest

    Yes, I´m newbie in Qos technologies..

    Sorry, one more question.

    "permit ip host ipsec.source.for.voice host ipsec.dest.for.voice"

    ipsec.source.for.voice -> public ip of fortinet?
    host ipsec.dest.for.voice -> public ip of remote fortinet?

    Thanks for your help.
     
    link, Jan 21, 2009
    #11
  12. link

    News Reader Guest

    Wouldn't your VoIP equipment already be setting DSCP in the IP headers
    to differentiate these from data?

    The local IPSec endpoint may also be copying the DSCP of the inner IP
    header to the outer encapsulating IP header.

    A sniffer would determine the answers to both.

    If your voice traffic is already marked, and the encapsulated voice
    traffic is already marked, then you may only need to address output
    policy (congestion management and avoidance) on the router.

    Best Regards,
    News Reader
     
    News Reader, Jan 21, 2009
    #12
  13. link

    bod43 Guest

    Well yes. BUT - this is only useful *IF* these addresses are
    unique to the voice traffic.

    YOU HAVE STILL NOT COMMENTED ON THIS
    CRITICAL ISSUE.

    If the same addresses are being used by the non-voice traffic
    then you will not be able to Classify the voice traffic using this
    technique. The packet length method is very likely
    to work well. Voice data is UDP so along with the length
    this will most likely correctly identify something like 99.99%
    of the traffic. I would put a wager on it. Beleive me - that is a
    very rare thing.

    As [News Reader] has stated below the voice equipment
    may well be setting the DS byte or CoS bits appropriately. If
    so you *may* be able to utilise that, The problem is that the
    internal switches will either be QoS aware and will by default
    be removing the QoS bits, or they may be dumb and may
    well be transparent and be passing the QoS bits unaltered.

    What model are your internal switches?

    With the current state of the technology none of this is easy.
    There does not seem to be an alternative to either
    understand what is going on or to employ someone
    who does.
     
    bod43, Jan 22, 2009
    #13
  14. link

    link Guest

    I have cisco 3750G and Cisco 2960G.

    The destination address is different for the voip and the data. Then
    if i put in this ACL the destination address of public IP of remote
    site (Remote Firewall) and in the source address put the public ip of
    local firewall, It will work. This is correct??

    ip access-list ext ACL.CM.voice
    permit ip host ip.public.of.local.fortinet
    host.ip.public.of.remote.fortinet

    regards,
     
    link, Jan 22, 2009
    #14
  15. link

    bod43 Guest

    There are so many addresses:)
    I have no idea if these are the "public" IPSEC peer's
    addresses of the internal phones and PCs addresses
    that you are referring to.

    It will not be possible to match on any internal addresses
    since they will be encrypted.

    If you post the addresses you are using, say
    a bit disguised but with the first and last octecs
    intact and state which are public addresses
    and which are private.

    The addresses we need are the IPSEC peer's
    addresses and the phones addresses at both ends.

    You have still not convinced me that you have in fact
    got two IPSEC 'tunnels' and this scheme wont
    work unkess you have seperate IPSEC peer
    addresses for the voice and the data.
     
    bod43, Jan 22, 2009
    #15
  16. link

    link Guest

    This is the topology more os less

    193.10.X.X
    Data Lan (10.10.18.0/24) -
    source
    <- Router Cisco----(212.15.X.X)Stonegate Firewall----Data LAN
    Swcore (10.10.18.2) ->
    (10.10.18.1)Firewall (194.30.XX.XX) --- (194.30.XX.XX) Cisco Router
    (10.X.X.X) ---------------
    WAN-----------------
    Asterisk (10.10.20.11)-<- 10.X.X.X <-Router Cisco ---- (194.80.X.X) Firewall Fortinet---
    Asterisk

    IP IPCES DEST (192.168.1.60)
    The VoIP VPN is between two PBX only.

    best regards
     
    link, Jan 23, 2009
    #16
  17. link

    link Guest

    This is the two VPNs:

    Firewall Fortinet 1
    IPSEC DST -> 194.30.XX.XX (Fortinet2)
    SRC -> Asterisk1(10.10.20.11)
    DST -> Asterisk2(192.168.1.60)

    IPSEC DST -> 217.XX.XXX.XX (Stonegate)
    SRC -> DataLan(10.10.18.0/24)
    DST -> DATArmtLan(192.168.0.0/16)

    Firewall Fortinet 2
    IPSEC DST -> 212.30.X.XXX (Fortinet1)
    SRC -> Asterisk(2)192.168.1.60
    DST -> Asterisk110.10.20.11

    Stonegate
    IPSEC DST -> 212.30.X.XXX(Fortinet1)
    SRC -> DararmLan(192.168.0.0/16)
    DST -> DataLAn(10.10.18.0/24)


    best regards,
     
    link, Jan 23, 2009
    #17
  18. link

    bod43 Guest


    Sorry for the delay. Not fully examined your material
    yet, but at first glance that all looks ok to me.

    Will have a detailed look tomorrow.
     
    bod43, Jan 26, 2009
    #18
  19. link

    link Guest

    Ok, I´ll wait. :)

    Thanks for your Help.
     
    link, Jan 26, 2009
    #19
  20. link

    bod43 Guest

    OK well that looks all OK.
    Two VPN's one for voice, one for data so you can
    match on the IPSEC peer addresses.

    Easy as pie:)
     
    bod43, Jan 28, 2009
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.