9608 R11 Fortigate VPN Multiple VPN Phones 4

[ringvoltage]

I have a R11 system with 9608 phones connecting over VPN to a fortigate firewall. Something interesting is happening and I am not sure how to troubleshoot.
The VPN tunnels get build, the phone connects and can make calls etc.
What is interesting is when you add a second VPN phone to the mix connected to the same LAN as the first VPN phone.
The second phone's button display gets garbled and when it reboots it assumes the identity of the first connected VPN phone so both phones have the extension/user setup.

-There are separate VPN logins for each phone user.
-There are separate user logins to the phone system for each phone.
-The phones work normally when connected one at a time.
-The fortinet shows each dial connection separately in its monitor view - so I believe the tunnels to be separate.

Anyone have ideas? Could it be that VPN is assigning the same IP addresses to the remote phone and that is confusing IPO? If so, does anyone know how to assign a static IP address to the VPN Connection on a 9608?

Also can anyone tell me how to view the vpn details from the phone - avaya key. It asks for a password. Craft and the user login don't work.

 

[kwing112000]

I have seen tis a lot with 2 VPN phones at 1 site. I always put in another Firewall at that site and create a site to site VPN

Kevin Wing
ACSS Small and Medium Enterprise (SME) Communications
ACS- Implement IP Office
ACA- Implement IP Office
Vive Communications

 

[ringvoltage]

Hmm. That's interesting. Thanks.
I checked the VPN and it is handing out different IP addresses to the VPN phones so it is not a function of redundant IPs.

 

[kyle555]

Oh boy... I can write a small novel on this.

Short answer - even Avaya on hosted IPO doesn't support >1 VPN phone behind 1 public IP.

Long answer: the phones are IPSEC VPN, not SSL. IPSEC is made for point-to-point. There are RFCs to allow you to have many private IPs 192.168.0.1,192.168.0.2, etc behind 1 public IP and all IPSEC to 1 public IP at another end, but there needs to be a mechanism for keepalives to come from the IPSEC server to be sent to the many IPSEC clients behind 1 dumb router, and the absence of standardization on that front makes it hit or miss.

Some sites might be able to have 3 VPN phones work great. Others, not so much.
In your case, its clear that when a phone reboots and sets up a tunnel, something in between the two public routers is mungling things up and making your newly rebooted phone receive the traffic associated to the other tunnel.

Avaya’s phones support RFC3947 for NAT traversal in the VPN guide -

https://downloads.avaya.com/css/P8/documents/101008050

JunOS supports RFC3948

http://www.juniper.net/documentatio...rence-hierarchy/junos-supported-standards.pdf

ScreenOS does not support RFC3947 – page 4 -

https://kb.juniper.net/kb/documents/public/VPN/ScreenOS_Windows_L2TP_IPSec.pdf

In the absence of IPSEC NAT traversal RFCs being supported, Avaya phones can drop down to an older standard, like RF1631 -

https://support.avaya.com/public/index?page=content&id=SOLN240726&group=UG_PUBLIC

See NVVPNENCAPS in the VPN guide (link above).

I can see this being a problem supporting many IPSEC clients behind the same NAT to the public internet. That’s why RFCs 3947 and 3948 were developed. Here’s an interesting read as to why that is:

https://www.cisco.com/c/en/us/about...ts-7/ipj-archive/article09186a00800c83ec.html

“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.”

 

[ringvoltage]

Great info. Thanks!

 

[yaturp]

Interesting post Kyle. I hope it wasn't as painful as it appears. Have a star for the effort.

 

[kyle555]

Actually, it wasn't so bad. Just a long afternoon in front of my Google machine and reading RFCs. I was curious, but also had to come up with a solid answer for a customer as to why some sites can have many VPN phones work fine and other sites can't.

I learned a lot actually. And I'm glad buddy ringvoltage mentioned his specific issue of a phone rebooting and coming up and somehow inheriting the tunnel of another phone behind the same router. Kinda proves the point that the routers in the middle, if they don't dance IPSEC the same way, can make bad things happen.