ipsec tunnel across Avaya 4620 phone terminating to cisco vpn concentrator

Unanswered Question
Aug 22nd, 2008

I have been asked to test out an avaya 4620 phone with the vpn remote client installed on it for our home users.

Here is my problem. The phone connects fine to my concentrator and I have a successful ipsec tunnel built, however, the phone cannot route back to the corportate network. When I look at the tunnel stats, I see bytes received and none transferred. Also, for the ip address of the remote end, I see the ip address that was assigned to it from my local dsl router. My concentrator is supposed to forward dhcp requests on to my internal dhcp server, but this is not occurring. Has anyone seen this before or know where I should start here? any input will be greatly appreciated, thank you all for your time.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.

Garth,

I have 20+ VPN phones (in test) running the VPN client connecting to a Cisco ASA5540 - have had no issues.

However - you do need to pre-configure the phone with the below, before sending out:-

1) Remote Call Server IP address

2) Remote HTTP/TFTP Server IP address

The above are KEY and the phone will not work without being able to d/l the 46xxsettings file, and the VPN scr file.

HTH>

stogyman_ Tue, 08/26/2008 - 05:31

Andrew,

Thank you for your reply.

I have those items in place, but my phone never connects to the call server. My phone picks up a local ip address from my local router. When it connects to my vpn concentrator, the tunnel comes up, but the phone never receives an ip address from my dhcp server on the internal corportate network. when I look at the session in my vpn concentrator, I see an active ipsec tunnel up, I see bytes received from the concentrator side, but zero bytes transmitted from the phone side. Also the remote ip address of the session shows the ip address that was obtained by my router and not from the intended dhcp scope. On the 4620 phone I see an entry for virtual ip address....do I need to incorporate that?

Also, is your asa handing out dhcp or do you use a dedicated dhcp server?

So the DHCP is not sending an IP address, are you blocking at the VPN concentrator?

The remote session would show the IP of your remote network - if it cannot receviea DHCP address the head end.

In my setup - I assign the addresses in my ASA. I personally prefer to do this, as there could be issues with connectivity to a DHCP server in the core or a central site. I assign addresses at the connecting point - makes trouble shooting easier for me.

If you have not already - read the link below from the Avaya site:-

http://www.avaya.com/master-usa/en-us/resource/assets/applicationnotes/vpnphn_csco3020.pdf

HTH>

stogyman_ Tue, 08/26/2008 - 08:35

Andrew,

thanks for the document. I had one similar but the one you supplied has more detail.

concentrator is not blocking dhcp because all my cisco vpn clients that our users have works fine.

My question to you Andrew is this:

if you are running this phone at home behind a cable/dsl modem then first the phone needs to pick up dhcp from your cable/dsl modem so it can route outbound and make a connection to your ASA. So when when you ASA supplies the ip address back to your phone, does it override the ip you had picked up from your dsl/cable modem?

thanks.

No it does not override, if it did it would not work locally, as the IP is not on your local subnet. The phone still has the local IP address of your subnet, but the remote VPN IP is passed on to the phones VPN virtual network adapter, just like the VPN client on a PC.

I suggest for testing, that you test the VPN Phone profile on the cisco client, this will either prove or disprove any issues with the DHCP address assignment.

For testing - I would have your VPN conc assign the addresses to see if this could be the issue.

If that works and you can send and recevie traffic using the same settings from the PC VPN client - then the issue could be with the phone settings themselves.

Some questions:-

1) ON the VPN profile, are you encrypting ALL traffic or have you enabled split-tunneling?

2) Have you enabled NAT-T ?

3) Have you configured in the VPN Phone the NAT-T ports of 4500?

4) If you have a firewall in front of the VPN concentrator, are you allowing UDP 4500 thru?

5) Does your cable/dsl modem support IPSEC pass-thru?

HTH>

stogyman_ Wed, 08/27/2008 - 06:54

Andrew,

answers to the following questions:

1.) My vpn profile is split-tunneling

2.) NAT-T is enalbed

3.) YES

4.) no firewall in front of my concentrator

5.) YES

My profile works fine when I use it from a pc with the cisco vpn client.

I will try having my concentrator dish out dhcp and let you know. thanks again for all your assistance, it is greatly appreciated.

paulgillis Tue, 02/23/2010 - 08:34

Hello Andrew, I know this thread is a bit old, but I am in the process of trying to setup some 9630's to VPN into my Corp. HQ.  which is behind a 5510.  the problem I am having is with IKE Phase 2, I keep getting an IKE Phase 2 no Response on the phone and this is what Im getting in the ASA log.

4|Feb 18 2010|09:05:04|113019|||||Group = test, Username = user, IP = 71.161.x.x, Session disconnected. Session Type: IKE, Duration: 0h:00m:01s, Bytes xmt: 0, Bytes rcv: 0, Reason: Phase 2 Mismatch
3|Feb 18 2010|09:05:04|713902|||||Group = test, Username = user, IP = 71.161.x.x, Removing peer from correlator table failed, no match!
3|Feb 18 2010|09:05:04|713902|||||Group = test, Username = user, IP = 71.161.x.x, QM FSM error (P2 struct &0xcc259568, mess id 0x8b0aed6d)!
5|Feb 18 2010|09:05:04|713904|||||Group = test, Username = user, IP = 71.161.x.x, All IPSec SA proposals found unacceptable!
5|Feb 18 2010|09:05:04|713119|||||Group = test, Username = user, IP = 71.161.x.x, PHASE 1 COMPLETED
6|Feb 18 2010|09:05:03|713228|||||Group = test, Username = user, IP = 71.161.x.x, Assigned private IP address 5.5.5.1 to remote user
6|Feb 18 2010|09:05:03|713184|||||Group = test, Username = user, IP = 71.161.x.x, Client Type:   Client Application Version:
5|Feb 18 2010|09:05:03|713130|||||Group = test, Username = user, IP = 71.161.x.x, Received unsupported transaction mode attribute: 6
5|Feb 18 2010|09:05:03|713130|||||Group = test, Username = user, IP = 71.161x.x, Received unsupported transaction mode attribute: 5
6|Feb 18 2010|09:05:03|734001|||||DAP: User user, Addr 71.161.x.x, Connection IPSec: The following DAP records were selected for this connection: DfltAccessPolicy

and this is what I get when I debug cyrpto isakmp

RESERVED != 0, PACKET MAY BE CORRUPTFeb 18 11:51:10 [IKEv1]: Group = test, Username = user, IP = 71.161.x.x, QM FSM error (P2 struct &0xcc4d4748, mess id 0x519ff252)!
Feb 18 11:51:10 [IKEv1 DEBUG]: Group = test, Username = user, IP = 71.161.212.49, IKE QM Responder FSM error history (struct &0xcc4d4748)  , :  QM_DONE, EV_ERROR-->QM_BLD_MSG2, EV_NEGO_SA-->QM_BLD_MSG2, EV_IS_REKEY-->QM_BLD_MSG2, EV_CONFIRM_SA-->QM_BLD_MSG2, EV_PROC_MSG-->QM_BLD_MSG2, EV_HASH_OK-->QM_BLD_MSG2, NullEvent-->QM_BLD_MSG2, EV_COMP_HASH
Feb 18 11:51:10 [IKEv1 DEBUG]: Group = test, Username = user, IP = 71.161.x.x, sending delete/delete with reason message
Feb 18 11:51:10 [IKEv1]: Group = test, Username = user, IP = 71.161.x.x, Removing peer from correlator table failed, no match!
Feb 18 11:51:10 [IKEv1 DEBUG]: Group = test, Username = user, IP = 71.161.x.x, IKE SA AM:18543029 rcv'd Terminate: state AM_ACTIVE  flags 0x00418041, refcnt 1, tuncnt 0
Feb 18 11:51:10 [IKEv1 DEBUG]: Group = test, Username = user, IP = 71.161.x.x, IKE SA AM:18543029 terminating:  flags 0x01418001, refcnt 0, tuncnt 0
Feb 18 11:51:10 [IKEv1 DEBUG]: Group = test, Username = user, IP = 71.161.x.x, sending delete/delete with reason message
Feb 18 11:51:10 [IKEv1 DEBUG]: Group = test, Username = user, IP = 71.161.x.x, constructing blank hash payload
Feb 18 11:51:10 [IKEv1 DEBUG]: Group = test, Username = user, IP = 71.161.x.x, constructing IKE delete payload
Feb 18 11:51:10 [IKEv1 DEBUG]: Group = test, Username = user, IP = 71.161.x.x, constructing qm hash payload
Feb 18 11:51:10 [IKEv1]: IP = 71.161.x.x, IKE_DECODE SENDING Message (msgid=2b900ae) with payloads : HDR + HASH (8) + DELETE (12) + NONE (0) total length : 80

BEFORE ENCRYPTION
ISAKMP Header
  Initiator COOKIE: 68 fb e0 7a 90 5c d7 10
  Responder COOKIE: 29 30 54 18 84 da aa d2
  Next Payload: Hash
  Version: 1.0
  Exchange Type: Informational
  Flags: (none)
  MessageID: AE00B902
  Length: 469762048
  Payload Hash
    Next Payload: Delete
    Reserved: 00
    Payload Length: 24
    Data:
      08 4b dc 3d 7c 2b 1b 99 c9 6d 6d 36 14 b9 d1 27
      47 e1 0d d6
  Payload Delete
    Next Payload: None
    Reserved: 00
    Payload Length: 28
    DOI: IPsec
    Protocol-ID: PROTO_ISAKMP
    Spi Size: 16
    # of SPIs: 1
    SPI (Hex dump):
      68 fb e0 7a 90 5c d7 10 29 30 54 18 84 da aa d2

ISAKMP Header
  Initiator COOKIE: 68 fb e0 7a 90 5c d7 10
  Responder COOKIE: 29 30 54 18 84 da aa d2
  Next Payload: Hash
  Version: 1.0
  Exchange Type: Informational
  Flags: (Encryption)
  MessageID: 02B900AE
  Length: 84
RESERVED != 0, PACKET MAY BE CORRUPTFeb 18 11:51:10 [IKEv1]: Ignoring msg to mark SA with dsID 1380352 dead because SA deleted

if you could provide any help it would be greatly appreciated as I have been battling this for a few days now.

thanks,

Paul

A good place to look is in the logs

4|Feb 18 2010|09:05:04|113019|||||Group = test, Username = user, IP = 71.161.x.x, Session disconnected. Session Type: IKE, Duration: 0h:00m:01s, Bytes xmt: 0, Bytes rcv: 0, Reason: Phase 2 Mismatch

~

5|Feb 18 2010|09:05:04|713904|||||Group = test, Username = user, IP = 71.161.x.x, All IPSec SA proposals found unacceptable!

What is configured on the VPN Conc for encryption? what have you configured the phone to use they must match.  If memory servers the Avaya software only supports a few transform sets.

paulgillis Tue, 02/23/2010 - 08:49

Thanks for the quick reply, as for what I can see in the VPN config on the ASA I do not see anything that specifically calls out the phaze 2 negotiations, as for on the phone I have it set to cisco and for the encryption it set to any.

paulgillis Tue, 02/23/2010 - 12:38

awesome, your post helped me look in the right spot as I already had a crypto group defined, once I configured  the phone to use that group number authentication was a success.

the phone is registered and logged on, and can make and receive calls, just one strange thing is happening which happens to some of my softphone users is the voice from the VPN side gets cut out, hearing the voice going to the vpn side works great, just when speaking back...

thinking it has something to do with h323 inspection...

thanks,

Paul

Actions

This Discussion