I'm having intermittent issues with VPN flashed phones successfully building the VPN tunnel, allowing me to get to the call server and enter the extension and password and then sitting there saying registering. Some work fine and others fail. When I do a list reg I see the failing extension registered, but with no TCP socket. What I've done so far is changed the ip-network=reg where it has the field 'near end establishes TCP socket'. The very first phone I was having the issue with suddenly worked when I did that, but subsequent phones failed. I've flipped the setting a few times and now it's not working. What can I check for this? This is a big issue for a set of folks that have these.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
TCP Socket Not Establishing on VPN phones
- Thread starter wpetilli
- Start date
avayaguy23
Systems Engineer
Check your firewall. I bet you don’t have the correct ports open.
- Thread starter
- #3
- Thread starter
- #5
- Thread starter
- #6
I spent an afternoon of my life erading up on VPN protocols and why multiple VPN phones behind 1 public IP might or might not work.
Short version: You probably unplugged the phones instead of gracefully tearing down the VPN tunnel, the far end thought it was up, and some renew request from the far end mungled up things.
There's different RFCs different routers support and the lowest common denominator would tend to have rekey requests get mixed up.
If you're testing from home on DSL, get a new IP between each try.
Here's part of a write up I did for a customer a few years back:
Juniper has a client that can be licensed that happens to support “remote access clients behind a NAT-T device”
That would work if the router in the office supports NAT-T (RFC3947) and if there were a few Windows PCs actually running that particular VPN client. I’m not familiar with Juniper products, but I understand your SSG140 to be somewhat older than the SRX series this particular client supports. RFC3947 + Juniper SSG140 doesn’t seem to be a good mix.
Avaya’s phones support RFC3947 for NAT traversal in the VPN guide - JunOS supports RFC3948 ScreenOS does not support RFC3947 – page 4 -
In the absence of IPSEC NAT traversal RFCs being supported, Avaya phones can drop down to an older standard, like RF1631 - See NVVPNENCAPS in the VPN guide (link above).
I can see this being a problem supporting many IPSEC clients behind the same NAT. That’s why RFCs 3947 and 3948 were developed. Here’s an interesting read as to why that is:
“A further problem may occur after a Security Association (SA) has been up for awhile. When the SA expires, one security gateway will send a rekey request to the other. If the SA was initiated from the well-known IKE port UDP/500, that port is used as the destination for the rekey request. If more than one security gateway lies behind a NAPT router, how can the incoming rekey be directed to the right private IP address? Rekeys can be made to work by "floating" the IKE port so that each gateway is addressable through a unique port number, allowing incoming requests to be demultiplexed by the NAPT router.”
Short version: You probably unplugged the phones instead of gracefully tearing down the VPN tunnel, the far end thought it was up, and some renew request from the far end mungled up things.
There's different RFCs different routers support and the lowest common denominator would tend to have rekey requests get mixed up.
If you're testing from home on DSL, get a new IP between each try.
Here's part of a write up I did for a customer a few years back:
Juniper has a client that can be licensed that happens to support “remote access clients behind a NAT-T device”
That would work if the router in the office supports NAT-T (RFC3947) and if there were a few Windows PCs actually running that particular VPN client. I’m not familiar with Juniper products, but I understand your SSG140 to be somewhat older than the SRX series this particular client supports. RFC3947 + Juniper SSG140 doesn’t seem to be a good mix.
Avaya’s phones support RFC3947 for NAT traversal in the VPN guide - JunOS supports RFC3948 ScreenOS does not support RFC3947 – page 4 -
In the absence of IPSEC NAT traversal RFCs being supported, Avaya phones can drop down to an older standard, like RF1631 - See NVVPNENCAPS in the VPN guide (link above).
I can see this being a problem supporting many IPSEC clients behind the same NAT. That’s why RFCs 3947 and 3948 were developed. Here’s an interesting read as to why that is:
“A further problem may occur after a Security Association (SA) has been up for awhile. When the SA expires, one security gateway will send a rekey request to the other. If the SA was initiated from the well-known IKE port UDP/500, that port is used as the destination for the rekey request. If more than one security gateway lies behind a NAPT router, how can the incoming rekey be directed to the right private IP address? Rekeys can be made to work by "floating" the IKE port so that each gateway is addressable through a unique port number, allowing incoming requests to be demultiplexed by the NAPT router.”
- Status
Similar threads
- Locked
- Question
