×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

VPN and Voice over H.323

Unanswered Question
Aug 26th, 2003
User Badges:

Everyone,


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?


Has anyone seen this? Any ideas?


Pat


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
jsivulka Mon, 09/01/2003 - 13:43
User Badges:
  • Bronze, 100 points or more

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.

daniel.kline Mon, 10/06/2003 - 03:41
User Badges:

Pat,


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.


Regards,

Dan

pattbo Mon, 10/06/2003 - 05:56
User Badges:

Dan,


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.


HTH,


Pat


davewomer Tue, 10/07/2003 - 09:39
User Badges:

do no fixup proto h323 1720

i had the same problem and this solved it

daniel.kline Tue, 10/07/2003 - 15:11
User Badges:

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

names

access-list 101 permit ip 10.0.0.0 255.255.255.0 10.0.1.0 255.255.255.0

pager lines 24

mtu outside 1500

mtu inside 1500

ip address outside xx.xx.xx.xx 255.255.255.248

ip address inside 10.0.2.2 255.255.255.0

ip audit info action alarm

ip audit attack action alarm

ip local pool ippool 10.0.1.1-10.0.1.10

pdm location 10.0.0.0 255.255.255.0 inside

pdm logging informational 100

pdm history enable

arp timeout 14400

global (outside) 1 xx.xx.xx.xx

nat (inside) 0 access-list 101

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

no access-group 102 in interface outside

route outside 0.0.0.0 0.0.0.0 68.167.32.81 1

route inside 10.0.0.0 255.255.255.0 10.0.2.1 1

timeout xlate 0:05:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00

timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

aaa-server TACACS+ protocol tacacs+

aaa-server RADIUS protocol radius

aaa-server LOCAL protocol local

http server enable

http 10.0.0.0 255.255.255.0 inside

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

floodguard enable

sysopt connection permit-ipsec

crypto ipsec transform-set clientTransform esp-des esp-md5-hmac

crypto dynamic-map dynmap 10 set transform-set clientTransform

crypto map mymap 10 ipsec-isakmp dynamic dynmap

crypto map mymap interface outside

isakmp enable outside

isakmp identity address

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption des

isakmp policy 10 hash md5

isakmp policy 10 group 2

isakmp policy 10 lifetime 43200

vpngroup xxx address-pool ippool

vpngroup xxx dns-server xx.xx.xx.xx xx.xx.xx.xx

vpngroup xxx default-domain client.com

vpngroup xxx split-tunnel 101

vpngroup xxx idle-time 1800

vpngroup xxx password


Dan

pattbo Wed, 10/08/2003 - 05:52
User Badges:

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.


Either way it is working currently.

Actions

This Discussion