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
    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
Reply
  • 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
Children
  • 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.