Avaya IP Phones accross IPSEC Tunnel

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.