Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 2 subscribers
  • Views 9343 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.
Parents
  • 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
Reply
  • 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
Children
  • 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.