Remote Access IPSec VPN doesn't work for phones

Difan Zhao · ‎12-31-2012

Hi experts,

We got some Avaya VPN phones. After the ASA firmware upgrade from 8.0.2 to 8.4.5 the phone is not working anymore...The VPN still works for the PC vpn client software... I have verified the isakmp preshared key several times... Here is output of "debug crypto ikev1 11" and "debug crypto ipsec 11"

fw-vadc-01#

fw-vadc-01# Dec 31 09:05:27 [IKEv1]IP = 209.82.99.145, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + KE (4) + NONCE (10) + ID (5) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 372

Dec 31 09:05:27 [IKEv1 DEBUG]IP = 209.82.99.145, processing SA payload

Dec 31 09:05:27 [IKEv1 DEBUG]IP = 209.82.99.145, processing ke payload

Dec 31 09:05:27 [IKEv1 DEBUG]IP = 209.82.99.145, processing ISA_KE payload

Dec 31 09:05:27 [IKEv1 DEBUG]IP = 209.82.99.145, processing nonce payload

Dec 31 09:05:27 [IKEv1 DEBUG]IP = 209.82.99.145, processing ID payload

Dec 31 09:05:27 [IKEv1 DEBUG]IP = 209.82.99.145, processing VID payload

Dec 31 09:05:27 [IKEv1 DEBUG]IP = 209.82.99.145, Received NAT-Traversal RFC VID

Dec 31 09:05:27 [IKEv1 DEBUG]IP = 209.82.99.145, processing VID payload

Dec 31 09:05:27 [IKEv1 DEBUG]IP = 209.82.99.145, Received NAT-Traversal ver 02 VID

Dec 31 09:05:27 [IKEv1 DEBUG]IP = 209.82.99.145, processing VID payload

Dec 31 09:05:27 [IKEv1 DEBUG]IP = 209.82.99.145, Received xauth V6 VID

Dec 31 09:05:27 [IKEv1]IP = 209.82.99.145, Connection landed on tunnel_group gtphones

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, processing IKE SA payload

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, IKE SA Proposal # 1, Transform # 1 acceptable Matches global IKE entry # 1

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, constructing ISAKMP SA payload

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, constructing ke payload

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, constructing nonce payload

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, Generating keys for Responder...

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, constructing ID payload

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, constructing hash payload

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, Computing hash for ISAKMP

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, constructing Cisco Unity VID payload

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, constructing xauth V6 VID payload

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, constructing dpd vid payload

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, constructing NAT-Traversal VID ver RFC payload

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, constructing NAT-Discovery payload

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, computing NAT Discovery hash

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, constructing NAT-Discovery payload

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, computing NAT Discovery hash

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, constructing Fragmentation VID + extended capabilities payload

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, constructing VID payload

Dec 31 09:05:27 [IKEv1 DEBUG]Group = gtphones, IP = 209.82.99.145, Send Altiga/Cisco VPN3000/Cisco ASA GW VID

Dec 31 09:05:27 [IKEv1]IP = 209.82.99.145, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + KE (4) + NONCE (10) + ID (5) + HASH (8) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NAT-D (20) + NAT-D (20) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 444

Dec 31 2012 09:05:27: %ASA-4-713903: Group = gtphones, IP = 209.82.99.145, Information Exchange processing failed

Dec 31 09:05:27 [IKEv1]IP = 209.82.99.145, IKE_DECODE RECEIVED Message (msgid=9433fe3b) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 456

Dec 31 09:05:27 [IKEv1]Group = gtphones, IP = 209.82.99.145, Received an un-encrypted INVALID-PAYLOAD-TYPE notify message, dropping

Dec 31 09:05:27 [IKEv1]Group = gtphones, IP = 209.82.99.145, Information Exchange processing failed

Here is my config

group-policy gtphones internal

group-policy gtphones attributes

dns-server value 10.26.150.75

vpn-tunnel-protocol ikev1

ipsec-udp enable

ipsec-udp-port 10000

split-tunnel-policy tunnelspecified

split-tunnel-network-list value vpnsplit

default-domain value gtcorp.com

!

tunnel-group gtphones type remote-access

tunnel-group gtphones general-attributes

address-pool gtphones-vpnpool

authentication-server-group ias_auth LOCAL

default-group-policy gtphones

tunnel-group gtphones ipsec-attributes

ikev1 pre-shared-key *****

peer-id-validate nocheck

!

crypto dynamic-map gtphones 1 set ikev1 transform-set ESP-AES-128-SHA

crypto dynamic-map gtphones 1 set reverse-route

!

crypto map vpnmap 2 ipsec-isakmp dynamic gtphones

crypto map vpnmap interface outside

!

Any idea why??

Thanks and happy new year!

Hardik Vaidh · ‎01-01-2013

Hi difan,

can you share access list or check access list for VPN and NAT access list

Jitendra Siyag · ‎01-01-2013

This message usually appears due to mismatched ISAKMP policies or a missing NAT 0 statement.

try this link

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a00807e0aca.shtml

shamax_1983 · ‎01-01-2013

Hi Difan,

I ran in to the same issue, In my case the issue was a ASA firmware bug. It affects SIP inspection on UDP traffic.

If you only use UDP for SIP server connectivity from your phone, your traffic will come in to your SIP server through the ASA but the ASA will drop the return traffic from the SIP server.

The workaround:

1) if it allows, change the SIP settings on the phones to use TCP instead of UDP

2) "Disable SIP inspection" on the ASA ( But you need to be carefull, if you have other SIP retaled services that needs NATing through the ASA, you might brake them, If your SIP server is inside your LAN, it would be fine..

Please rate this if helpful

Difan Zhao · ‎01-01-2013

Thanks guys... I have called Cisco TAC. It turned out to be Avaya phone bug. It sends payload type 20 rather than 15... May have to downgrade the ASA now... Thanks for your help though