VoIP over VPN Tunneling

Hamed,

My company recently implemented a 5 site VoIP installation and we've used Linux devices as Firewall/Router/VPN devices and thus far have had no problems using them on a daily basis.  Even with those connections that are running across dynamically assigned Digital Subscriber Line connections, the frequency of loss is nominal.

Have you considered what VoIP protocol you will be using, as SIP tends to require more overhead than H323?  Another thing to consider is that some PBXs will assign an 802.1p tag to packets leaving the hub, but a lot of SIP endpoints do not assign those same tags to packets destined for the hub.

What kind of PBX are you planning on using for this implementation?

Regards,

Andrew

You might want to contact Koolspan.  They make an encrytion/vpn device that works quite well for this.

Hi,

Thanks for your posts... we decided to do this with cisco...

We used 3640 in one end (C3640-IK8O3S-M), Version 12.2(12) and 3662 on the other end of the link (C3660-JK9O3S-M), Version 12.2(7)...

We ran IPSec with crypto and currently there is major the 3640's CPU ussage! eg for 20 calls (g729) the usage is 60%! anything more than 2 E1s is complete death for that router i beleive. We double checked everything to make sure all uncessary services are disbaled but still the same cpu usage... so that router must be changed!

There are occasionall call disconnects which i still have to debug to see whether its the tunnel or anuthing else!

That brings me to the worst problem which is really bad performance on telnet/http or any such protocols... for example it is impossible for us to view a live debug of a gateway on this tunnel... the connection either times out or there are significant delays on displaying the content!

I guess because voip uses smaller packets it all works on that! I dont think i would be trying VPN with a linux as a dedicated cisco 3640 with 20 calls (g729 around 280k overall) is failing misrably not to mention configuration difficulties that i may have on the linux. I also must use route-map on one end of the link to make the outgoing packets to travel via tunnel so i think that even makes it more difficult on the linux...

Regards
Hamed

It could ba a configuration issue on the routers.
Are you using just VPN or are you using a GRE tunnel together with VPN?

I would advise against using GRE as it adds an extra packet overhead which is significant for VoIP traffic, adds extra load on the router, and causes MTU problems which can slow down traffic which uses large packet sizes significantly.

Here are the configs:

version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname UkTunnel
!
no logging buffered
no logging console
no logging monitor
enable secret 5 XXXXXXX
!
ip subnet-zero
ip wccp version 1
ip cef
!
!
no ip domain-lookup
ip domain-name nixtechnologies.com
!
ip audit notify log
ip audit po max-events 100
no crypto isakmp enable
!
!
crypto ipsec transform-set encrypt-sec esp-des
!
crypto map tunell local-address Ethernet1/0
crypto map tunell 8 ipsec-manual
 set peer 81.xx.xx.11
 set session-key inbound esp 1001 cipher 1234abcd1234abcd authenticator 01
 set session-key outbound esp 1000 cipher abcd1234abcd1234 authenticator 01
 set transform-set encrypt-sec
 match address 100
!
call rsvp-sync
!
!
!
!
!
!
!
!
interface Tunnel1
 ip address 10.10.10.1 255.255.255.252
 tunnel source Ethernet1/0
 tunnel destination 81.xx.xx.11
!
interface Ethernet1/0
 description ConnectionToNet
 ip address 82.xx.xx.184 255.255.255.192
 no ip redirects
 ip route-cache policy
 keepalive 3
 full-duplex
 no cdp enable
 crypto map tunell
!
interface Serial1/0
 no ip address
 shutdown
 no cdp enable
!
interface Ethernet1/1
 description ME-LAN
 no ip address
 no ip redirects
 half-duplex
 no cdp enable
!
ip classless
ip route 0.0.0.0 0.0.0.0 82.xx.xx.129
ip route 82.xx.xx.96 255.255.255.224 10.10.10.2
no ip http server
ip pim bidir-enable
!
logging trap debugging
access-list 100 permit gre host 82.xx.xx.184 host 81.xx.xx.11
access-list 100 permit ip host 82.xx.xx.184 host 81.xx.xx.11
access-list 100 permit icmp host 82.xx.xx.184 host 81.xx.xx.11
no cdp run
!

that was only the one in UK... however their are both identical but with otherone has UK's ips and corresponding session key

You have the crypto-map applied to the ethernet interface so the VPN is not going over GRE which is good.
You do still have 'Interface Tunnel1' in your configuration though. I would remove this section of the config incase it is causing any problems.

I was under impression that the tunnel1 is making the peering between UK GW and the Other Remote GW... i think removing it will bring the connection down! Am i wrong?

On second inspection it appears as though you are using GRE as the tunnel interface is bound to the internal interface.

Who set the routers up for you?
I would advise that they are reconfigured not to use a GRE tunnel.

We configured it here althought we used help from cisco's manuals/website which kinda allways suggested using tunnel for the VPN activity! I am now confused, i dont even know how the packets are going to travel from one GW to the other without that GRE tunnel in place... any hints or suggestions for typical config would be appreciated to explain your method of doing this...

What we are doing here is we have a subnet of public addresses which are routed to the IP address set on ethernet interface of this router, we want to allow the devices in the remote location to use these IPs while being on a secured encalpsulated packets (hidden from the ISP)...

You want the remote location to use the IP's on your local routers external interface?
You have lost me here.

You would normally have a basic VPN connection between the sites and each site can access the other sites machines using their own private internal IP address.

Here is what im trying to do:

- i have a subnet 82.xx.66.96/27 which is routed to IP 82.xx.65.184. the IP routing was done in our core IP router connected to ISPP.
- 82.xx.65.184 is configured on interface Ethernet1/0 of the VPN designated gateway in UK (c3640) (local router)
- 81.xx.80.11 is configuired on ethernet 0/0 of router in the other country (remote router)
- all above are public addresses pingable from anywhere.

We want subnet 82.xx.66.96/27 to be used in the remote loaction. For example i set them on a PC (eg 82.xx.66.99) in the remote network, anyone from the public internet net should be able to see that PC!

The main objective is to prevent the ISP in the remote location to see what is exchnage on that link hence we like to do encryption to avoid them sniffing around our ports to identify h323/voip traffic!

So far it works with that config above, but the CPU usages are high, i am guessing maybe thats to do with the encryption done on the system but i dont beleive it can have such high usage! 280k 60%+!

Not sure what would be the best way to do it. I have sent an email to lrmoore asking him to have a look.

Last night with 30 calls on the system with 450K bandwidth the CPU usage on the cisco 3640 was 99%.

If the configuration i have is correct and should not be changed, can anyone recommend what hardware i must have inplace of 3640 to handle up to 300 calls? (potential 4.5mb bandwidth) with ipsec/encryption?

anything on this? I am sure you guys have tried something similar to this before! Its simply a Network-to-network (or subnet-to-subnet) VPN with IPsec/encryption....

You could email lrmoore and ask him to have a look at your question. He might have missed my email.

Some general comments...
It's working the way you have it using GRE tunnels, but CPU utilization on the 3640 is too high, maxing out around 24 calls leaving even less room to add any QoS configuration..

This document might help you troubleshoot the high cpu utilization.
http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a00800a70f2.shtml

GRE tunnel has an advantage of providing some QoS methods over  the tunnel interface that you can't get with a standard IPSEC only tunnel (dynamic).

The 3640 is end-of-life product. You could get more life out of it with a VPN accelerator daughter card to reduce the CPU utilization.

The 3800 series is the current replacement with better support for VoIP and VPN acceleration, but if you want to support up to 10 times that amount of calls, you might have to go even bigger with something like a 7206VXR

i have been calling quiet a few of our partners they all think the following would do about 6mb of encrypted bandwith over public net. (around the same number of calls we want to handle)

CISCO2821-HSEC/K9      2821 Security Bundle,AIM-VPN-EPII-PLUS,Adv. IP Serv,64F/256D      

are they correct?

Also i get the feeling you confirm our configuration is correct and does not need to be changed?

>you confirm our configuration is correct and does not need to be changed?
I didn't say that. I'm sure that there are some things that could be changed to improve the performance.
You don't need to encrypt traffic over the tunnel. You could drop the encryption altogether and just tunnel using GRE
You don't necessarily need to encrypt the GRE packets, just the IP packets
single Pre-shared keys are easier to process than manual separate inbound/outbound session keys
You could enable some QoS over the GRE tunnels
http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a008017405e.shtml

See this document that puts it all together - GRE, IPSEC and QoS (notice that they don't encrypt the GRE traffic in the match acl)
http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns109/networking_solutions_white_paper09186a0080189153.shtml

I would consider the 2821 a very slight improvement over what you already have. It is the next generation 2600 series, but is slightly more powerful than your 3640, but not 10x. The key is in the VPN accelerator included with that bundle . I still think that the 3845 security bundle would be a better choice if you want performance+ security for the long term.

When you mentioned "The key is in the VPN accelerator" does that mean because of the VPN accelerator it can pull of the job for about 4-5Mb encrypted bandwidth?

We would not go over that 4-5mb over long term anyway i have budgetary concerns over the 3845 too we need to invest on two of them for this tunnel, if they the investment is going to be above 5,000 pounts (for both) then i might as well go for satellite bandwidht for this application and ignore the whole tunnel complexities. Thats why we were looking at the 2821 security bundle which was quiet reasonably priced for this application,... althought we dont want to findout it cant pull-off what we are trying to do hence we are now having this conversation...