I am having a problem getting Avaya IP soft or hard phones working across Cisco VPN. The phones work great within the corporate network, but as soon as we add a VPN connection it fails. The Avaya solution is using H.323 for Voice and I think that is part of my problem. For info purposes we are using Avaya IP office and Avaya 4612 IP Hard Phones and the soft phone is the Phone Manager software.
I have a Cisco 3015 Concentrator running 3.6.1 at the corporate office. I have had users with laptops get the IP Soft phone working inside our network. Then when they go home, and use VPN Client 3.6 and 3.5.4 they are no longer able to use the soft phone client. Connectivity is there and was verified with pings between Phone System and client system. We have tried different VPN transports, we have tried split tunneling and have disabled all involved firewalls and it still does not work.
I have also just tried to use a VPN 3002 running 4.0.1 and an IP Hard Phone plugged into it. It has connectivity (config download via TFTP and pings are successful) but Voice does not work.
I can only get net meeting (also uses H.323) to work if we dial out from the VPN clients. Calls to the client fail. I am wondering if this also has something to do with it. Maybe some sort of "one-way" failure to establish H.323 correctly?
Please make sure that your setup (device/hardware/software) is ok as per the compatibility matrix at http://www.cisco.com/warp/public/707/cmatrix.shtml. If these conditions are satisfied but the problem still persists, that would probably be due to a configuration problem.
I am having a similar issue with the Avaya IP Softphone and Cisco's remote vpn (IPSEC) client. Avaya says their softphone does not work with Cisco's vpn client software and I am looking for a workaround. Please let me know if you come up with anything.
For the Softphones, using a Cisco VPN Client 4.0 or newer corrects the IP address mapping for H.323 I forget the bug number).... but it is working for me.
And for some odd reason, I have to use a Split tunneling group for these users. It would seem that it would be less likely to send traffic to my corporate network, but that is the setup that is working for me.
I still have a problem with H.323 and H.225 Fixup through the Pix (my VPN users come in to the network through a DMZ port on my PIX), but if your VPN users are on the inside network you should not see that problem.
If you are using split tunneling for these clients, are you sure tey are actually using the vpn tunnel? I had turned off H.223 and H.225 fixup. My users are coming in from a remote location through the Internet traversing the firewall's external interface. I have split tunneling set up for these users, but they use a private address to connect to the IP Office server. Hence, their voice traffic uses the vpn tunnel as does their other "LAN" traffic. Internet traffic from the remote location uses the local ISP connection. See the config below (portions omitted):
fixup protocol ftp 21
no fixup protocol h323 h225 1720
no fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol ils 389
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
access-list 101 permit ip 10.0.0.0 255.255.255.0 10.0.1.0 255.255.255.0
The IP Office systems are 10.x.x.x addresses and there is no way it would route across the Internet without using the Tunnel. I am also using the Cisco VPN 3015 Concentrator instead of the Pix for VPN.
I can't explain it, it would seem to be less likely to work when using Split tunneling.
I have 4 groups set up using different transports and tunneling methods.
Group 1 uses ESP/IP and No Split Tunnel
Group 2 uses UDP/IP and No Split Tunnel
Group 3 uses ESP/IP and Split Tunnel
Group 4 uses UDP/IP and Split Tunnel
Only group 4 works. Group 3 and 4 use the same Network Lists (for Internal Networks). I assume Group 3 does not work because of NAT and H.323 (fixup). I would guess group 2 would work, but it won't.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...