Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 2 subscribers
  • Views 9341 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Avaya IP Phones accross IPSEC Tunnel

skydiver
I am trying to deploy a new phone provider on our network and am having some issues.  Currently I have a SIP VOIP telephone provider and we have our phones on a separated VLAN that allows the phones to register and place calls directly to the internet.  My new phone prover will be hosting an Avaya IP office system at their hosting center and I am connecting our telephone VLAN to their network via an IPSEC tunnel.  I currently use SIP VOIP security for this vlan network segment for my current SIP/VOIP provider.

I have the IPSEC tunnel up and we can ping and telnet across the tunnel between network segments.  The phones find the Avaya switch and can register with thw IP office system.  When placing an outbound call, the Avaya phones do not echo a dial tone when off hook or dialing.  The call is initiated but the avaya handset have no sound or indication of a call going outbound.  The called number rings but when you pick up the call there is silence on both ends.  The same goes for inbound, the phone rings but when picked up, silence on both ends.  What is curious is that I do not see any traffic inbound or outbound in the ASG packet filter logs or IPS between the two private network segments.  I have disabled IPS completely, still no luck.

The provider thinks the ASG is trapping h.323 traffic.  I have setup the gateway/client settings in the ASG VOIP security h.323 section but still nothing.   I think the IPSEC tunnel may be part of the issue.  My provider is hosting his end of the VPN on an adtran and we have created a custom IPSEC policy to connect our networks:
IPSEC Policy Definition 

3DES-MD5 (ACC)	[Use for TelConnect VPN]

Compression off, not using strict policy.

IKE Settings: 3DES / MD5 / Group 2: MODP 1024   Lifetime: 28800 seconds

IPSec Settings: 3DES / MD5 / Group 2: MODP 1024   Lifetime: 28800 seconds

The networks appear to connect and we can ping both ways but I am seeing a lot of errors in the VPN log (see below, it has been sanitized)
IPSEC Tunnel Connection Log 

2010:10:20-15:19:30 asg-01 pluto[3681]: added connection description "S_REF_kjhkjhkjhkjhkj_0"

2010:10:20-15:19:30 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: initiating Main Mode

2010:10:20-15:19:30 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]

2010:10:20-15:19:30 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: received Vendor ID payload [Dead Peer Detection]

2010:10:20-15:19:30 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: Can't authenticate: no preshared key found for `99.99.99.998' and `99.99.99.999'.  Attribute OAKLEY_AUTHENTICATION_METHOD

2010:10:20-15:19:30 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: no acceptable Oakley Transform

2010:10:20-15:19:30 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: sending notification NO_PROPOSAL_CHOSEN to 99.99.99.999:500

2010:10:20-15:19:31 asg-01 pluto[3681]: forgetting secrets

2010:10:20-15:19:31 asg-01 pluto[3681]: loading secrets from "/etc/ipsec.secrets"

2010:10:20-15:19:31 asg-01 pluto[3681]:   loaded shared key for 99.99.99.999 99.99.99.998 

2010:10:20-15:19:31 asg-01 pluto[3681]:   loaded shared key for 0.0.0.0 99.99.99.998 

2010:10:20-15:19:31 asg-01 pluto[3681]:   loaded shared key for 0.0.0.0 99.99.99.998 

2010:10:20-15:19:31 asg-01 pluto[3681]: Changing to directory '/etc/ipsec.d/cacerts'

2010:10:20-15:19:31 asg-01 pluto[3681]:   loaded CA cert file 'REF_kjhjkhkjhkj.pem' (3178 bytes)

2010:10:20-15:19:31 asg-01 pluto[3681]: Changing to directory '/etc/ipsec.d/aacerts'

2010:10:20-15:19:31 asg-01 pluto[3681]: Changing to directory '/etc/ipsec.d/ocspcerts'

2010:10:20-15:19:31 asg-01 pluto[3681]: Changing to directory '/etc/ipsec.d/crls'

2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]

2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: received Vendor ID payload [Dead Peer Detection]

2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: enabling possible NAT-traversal with method RFC 3947

2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected

2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: Peer ID is ID_IPV4_ADDR: '99.99.99.999'

2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: ISAKMP SA established

2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3340: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#3339}

2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: ignoring informational payload, type IPSEC_INITIAL_CONTACT

2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3340: IKE message has the Commit Flag set but Pluto doesn't implement this feature; ignoring flag

2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3340: ignoring informational payload, type IPSEC_REPLAY_STATUS

2010:10:20-15:19:36 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3340: Dead Peer Detection (RFC 3706) enabled

2010:10:20-15:19:36 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3340: sent QI2, IPsec SA established {ESP=>0xe65962e3 


Anyone have ideas as to where to look to see where this is failing?  The provider is throwing this back in my lap since he is unfamiliar with ASG's and Astaro support is taking hours to get back to me.


This thread was automatically locked due to age.
  • 0
    This what is logged in the VPN logs when  initiating a call: 

    

    2010:10:20-15:19:30 asg-01 pluto[3681]: added connection description "S_REF_kjhkjhkjhkjhkj_0"

    2010:10:20-15:19:30 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: initiating Main Mode

    2010:10:20-15:19:30 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]

    2010:10:20-15:19:30 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: received Vendor ID payload [Dead Peer Detection]

    2010:10:20-15:19:30 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: Can't authenticate: no preshared key found for `99.99.99.998' and `99.99.99.999'.  Attribute OAKLEY_AUTHENTICATION_METHOD

    2010:10:20-15:19:30 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: no acceptable Oakley Transform

    2010:10:20-15:19:30 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: sending notification NO_PROPOSAL_CHOSEN to 99.99.99.999:500

    2010:10:20-15:19:31 asg-01 pluto[3681]: forgetting secrets

    2010:10:20-15:19:31 asg-01 pluto[3681]: loading secrets from "/etc/ipsec.secrets"

    2010:10:20-15:19:31 asg-01 pluto[3681]:   loaded shared key for 99.99.99.999 99.99.99.998 

    2010:10:20-15:19:31 asg-01 pluto[3681]:   loaded shared key for 0.0.0.0 99.99.99.998 

    2010:10:20-15:19:31 asg-01 pluto[3681]:   loaded shared key for 0.0.0.0 99.99.99.998 

    2010:10:20-15:19:31 asg-01 pluto[3681]: Changing to directory '/etc/ipsec.d/cacerts'

    2010:10:20-15:19:31 asg-01 pluto[3681]:   loaded CA cert file 'REF_yOHEfwwLSP.pem' (3178 bytes)

    2010:10:20-15:19:31 asg-01 pluto[3681]: Changing to directory '/etc/ipsec.d/aacerts'

    2010:10:20-15:19:31 asg-01 pluto[3681]: Changing to directory '/etc/ipsec.d/ocspcerts'

    2010:10:20-15:19:31 asg-01 pluto[3681]: Changing to directory '/etc/ipsec.d/crls'

    2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]

    2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: received Vendor ID payload [Dead Peer Detection]

    2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: enabling possible NAT-traversal with method RFC 3947

    2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected

    2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: Peer ID is ID_IPV4_ADDR: '99.99.99.999'

    2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: ISAKMP SA established

    2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3340: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP {using isakmp#3339}

    2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3339: ignoring informational payload, type IPSEC_INITIAL_CONTACT

    2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3340: IKE message has the Commit Flag set but Pluto doesn't implement this feature; ignoring flag

    2010:10:20-15:19:35 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3340: ignoring informational payload, type IPSEC_REPLAY_STATUS

    2010:10:20-15:19:36 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3340: Dead Peer Detection (RFC 3706) enabled

    2010:10:20-15:19:36 asg-01 pluto[3681]: "S_REF_kjhkjhkjhkjhkj_0" #3340: sent QI2, IPsec SA established {ESP=>0xe65962e3 0x63f18770 0x63f18778 0x63f18779 0x63f18788 
  • 0 in reply to skydiver
    So I got disconnected from Astaro support, now I can't get through to anyone asking to leave a message for call back and still waiting....  The support has really been sub-par lately.

    Anyone on the forum have any ideas here?   I need to get this up, I have been on-site for the entire day with no resolution.
  • 0
    The best way to contact Astaro Support is not via phone, even if you have Premium/Platinum Support.  You should ask your reseller to submit a support request via the web.  I've emailed you about that.

    I know Adtran can do AES-128.  That certainly would be faster and use less resources on your ASG220.

    Your first post doesn't show anything that looks like an error, just normal negotiation.  In the second post, it looks like you and the Adtran aren't agreeing about something though.  I'm confused that the SA gets established, and then dies when you try to connect your VoIP phone through it.

    I think you'll need to wait for Astaro Support to look at what you have.  In the meantime, how about pics of the IPsec Connection and Remote Gateway as well as the corresponding logs from the Adtran.

    Cheers - Bob
  • 0 in reply to BAlfson
    Hi all,

    What did you configure un The Firewall, NAT, routing and VoIP Security settings?

    Does The avaya system use H323 or SIP?

    How steift do you Wang your firewall settings between the phones and the service?

    The error seems like that the packets sent from the remote site do not reach the phones.
    The question is why.

    Do you see any dropped packets in the packet filter log?

    Do you use NAT somewhere between the phones and the gatekeeper?

    Is IPS enabled? If yes, any dropped packets there?

    Which version of ASG are you using?

    If you want to dig deeper, you can login via SSH and make a tcpdump othe spec interface, during the time you initiate a call.
    Than you have to see if packets coming out of the spec interface on a contious basis.

    If not, check if on the external interface you see incoming esp packets (protocol 50) on the WAN interface.

    Hope that helps.
    Gert
  • 0 in reply to Gert Hansen
    Gert answers to your questions:
    What did you configure un The Firewall, NAT, routing and VoIP Security settings?

    Firewall setup is as follows:
    VOIP Network  packet filyter swetup VOIP-LAN ->ANY->ANY near top of chain.
    VOIP network segment NAT's to external interfaces (Uplink).
    VOIP Security is setup with SIP - ANY/VOIP-LAN (for current SIP VOIP phones)
    VOIP Security is setup with h.323 Gatekeeper-Vendors IP Office Device/Testing phone internal IP (10.15.x.110)

    The IPSEC tunnel is established between the VOIP network segment on the ASG (10.15.x.0/24 and the provider network (10.100.21.0/24).
    Does The avaya system use H323 or SIP?

    h.323

    How steift do you Wang your firewall settings between the phones and the service?

    I am not sure what you are asking here.  I first want to get the service up then I need to tighten everything down to allow rules between devices only if you are asking how tight to configure security.
    The error seems like that the packets sent from the remote site do not reach the phones.
    The question is why.

    Do you see any dropped packets in the packet filter log?

    I am not seeing any traffic during calls when  I filter in packet filter live log for 10.15.12.110 (my test phone) or 10.100.21 (providers network segment)  I have deactivated IPS to see if that was the issue, but it wasn't.  


    Do you use NAT somewhere between the phones and the gatekeeper?

    The VOIP LAN is NAT'd to the two external UPLINK interfaces for the currently existing SIP phones hosted on a public internet host, but the h.323 traffic is running over internal segments via local and the remote network hosts.
    Is IPS enabled? If yes, any dropped packets there?

    No events in the IPS whether on or off.
    Which version of ASG are you using?

    7.507

    If you want to dig deeper, you can login via SSH and make a tcpdump othe spec interface, during the time you initiate a call.
    Than you have to see if packets coming out of the spec interface on a contious basis.
    If not, check if on the external interface you see incoming esp packets (protocol 50) on the WAN interface.
     
    I will pull some dumps and post the results here.
    Thanks for the help.
  • 0
    If not, check if on the external interface you see incoming esp packets (protocol 50) on the WAN interface.

    I think Gert also suspects that the problem might well be on the other side...

    Cheers - Bob
  • 0 in reply to BAlfson
    So, I ended up punting last night at the location and instead brought the phones back to our office to work in this this morning.  Curiously, I am not experiencing the same problems on our office network, which is similarly configured on an ASG220 but not 100% the same, the ASG220 has the VOIP vlan segment on a dedicated NIC while our location setup has the VOIP lan segment setup as a VLAN along with three others running on eth0 on the ASG.  I am set up our lab ASG120 in our office which is similarly configured as the restaurant ASG and I am able to duplicate the problem.  I have our telephone vendor coming over so we can do packet capturing from our office here.

    On our lab i did setup AES128 instead of the custom IPSEC policy and it seems to stop the dropped messages on the IPSEC connection log. 

    2010:10:21-08:49:34 marg-lab pluto[3619]: added connection description "S_REF_ECyAVhBMXO_0"

    2010:10:21-08:49:34 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #10: initiating Main Mode

    2010:10:21-08:49:34 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #10: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]

    2010:10:21-08:49:34 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #10: received Vendor ID payload [Dead Peer Detection]

    2010:10:21-08:49:34 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #10: Can't authenticate: no preshared key found for `(ASG ip redacted)' and `tunnel ip redacted)'.  Attribute OAKLEY_AUTHENTICATION_METHOD

    2010:10:21-08:49:34 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #10: no acceptable Oakley Transform

    2010:10:21-08:49:34 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #10: sending notification NO_PROPOSAL_CHOSEN to tunnel ip redacted):500

    2010:10:21-08:49:35 marg-lab pluto[3619]: forgetting secrets

    2010:10:21-08:49:35 marg-lab pluto[3619]: loading secrets from "/etc/ipsec.secrets"

    2010:10:21-08:49:35 marg-lab pluto[3619]:   loaded shared key for (tunnel ip redacted) (ASG ip redacted)

    2010:10:21-08:49:35 marg-lab pluto[3619]:   loaded shared key for 0.0.0.0 (ASG ip redacted) 

    2010:10:21-08:49:35 marg-lab pluto[3619]:   loaded shared key for 0.0.0.0 (ASG ip redacted) 

    2010:10:21-08:49:35 marg-lab pluto[3619]: Changing to directory '/etc/ipsec.d/cacerts'

    2010:10:21-08:49:35 marg-lab pluto[3619]:   loaded CA cert file 'REF_yrIOlRduHW.pem' (3176 bytes)

    2010:10:21-08:49:35 marg-lab pluto[3619]: Changing to directory '/etc/ipsec.d/aacerts'

    2010:10:21-08:49:35 marg-lab pluto[3619]: Changing to directory '/etc/ipsec.d/ocspcerts'

    2010:10:21-08:49:35 marg-lab pluto[3619]: Changing to directory '/etc/ipsec.d/crls'

    2010:10:21-08:49:39 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #10: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]

    2010:10:21-08:49:39 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #10: received Vendor ID payload [Dead Peer Detection]

    2010:10:21-08:49:39 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #10: enabling possible NAT-traversal with method RFC 3947

    2010:10:21-08:49:39 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #10: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected

    2010:10:21-08:49:39 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #10: Peer ID is ID_IPV4_ADDR: 'tunnel ip redacted)'

    2010:10:21-08:49:39 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #10: ISAKMP SA established

    2010:10:21-08:49:39 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #11: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#10}

    2010:10:21-08:49:39 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #10: ignoring informational payload, type IPSEC_INITIAL_CONTACT

    2010:10:21-08:49:39 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #11: IKE message has the Commit Flag set but Pluto doesn't implement this feature; ignoring flag

    2010:10:21-08:49:39 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #11: ignoring informational payload, type IPSEC_REPLAY_STATUS

    2010:10:21-08:49:39 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #11: Dead Peer Detection (RFC 3706) enabled

    2010:10:21-08:49:39 marg-lab pluto[3619]: "S_REF_ECyAVhBMXO_0" #11: sent QI2, IPsec SA established {ESP=>0xc2f388a9 
  • 0 in reply to skydiver

    If you want to dig deeper, you can login via SSH and make a tcpdump othe spec interface, during the time you initiate a call.
    Than you have to see if packets coming out of the spec interface on a contious basis.
    If not, check if on the external interface you see incoming esp packets (protocol 50) on the WAN interface. 


    Gert:
    What would be a good targeted tcpdump command for this?

    eth0.102 is the voip vlan
    eth1 is the primary WAN connection that IPSEC tunnel is running over
    1.2.3.4 is IPSEC tunnel endpoint at the host
  • 0 in reply to skydiver
    So after a bit of convincing, we were able to determine the issue.  It went back to the Adtran.  Th IPSEC tunnels were defined with /16 network destinations.  Since we have 4 tunnels defined, the adtran was routing out the first tunnel in it's routing table instead of the location's tunnel.  This is why our home office worked but our locations didn't.

    I am out to test at my location to go into pilot testing this afternoon.  My next question is there a compelling reason to activate the h.323 functionality on our end?  This system seems to be functionally working without it in our lab, but I know I will need to do some voip traffic prioritization on my devices and as I understand it, this may help to tag the traffic that will need to be prioritized.

    Thanks for the help everyone, it made me look to the right areas for checking what was going on, and only after I knew in my heart that the issue was on the provider's end was I able to convince them to make the changes that I needed to verify my suspicions.
  • 0
    Hello Skydiver,

    as I am new @ Astaro, just going through your issue and it reminded me on an issue I had with Avaya and Sonicwall. I had to turn off H323.Transformations on Sonicwall and it immediatelly started working. I was advised to do this by Avaya, as this most of the time fixes VoIP issues through Site to Site VPN, unless it is network issue.

    Since you've asked whether you should turn on H.323, I'd say try keeping it off and see what happens. 

    Hope this helps,

    Zoro