some IP Phone not working over site-to-site OpenVPN, packets modified on other side of tunnel

[FrankSider12]

Hi,

I have five secondary sites connected to a main site using OpenVPN.
The main site is using digital phones and DECT wireless phones with a IP base.
I have 2 sites down at the moment, still trying to figure out the problems on the other sites.

Site A has around 10-12 desk phones plus two or three DECT and is working fine so far after two months. Had a few hiccups during the install (and the solutions was a bit weird, probably caused by a defect piece of equipment)
Site B, has 2 IP desk phones and two wireless DECT (with DECT Over IP base). Both wireless works but only one desk phone work.
Site C, has 1 IP desk phone and also two wireless. Both wireless works but the desk phone won't.

All desk phones are Avaya 1616, everywhere.

Phones not working communicate perfectly on bootup to get config/upgrade via several ports (mostly 80). Next step is the registration on port 1719 (UDP) and that's where the problem occurs.

On remote side of the VPN, I can see the packet entering the tunnel perfectly, looking at it with Wireshark, I see no problem.
But on the main site, the packet is changed and has an extra 4 bytes "81 00 C0 00", and the location where it is inserted in the packet is at the source IP. Since the four bytes are inserted, what was supposed to be the destination IP is now the source IP and the destination is lost.

So what should be:
IP 192.168.93.244.33396 > 192.168.90.201.2017
Is now:
IP 192.0.129.0.49320 > 192.168.93.244.23241 (Ports are also changed because everything is shifted 4 bytes)

SIP ALG and H323 transform are disabled.
I'm using simple routing tables, no need to use NAT, port forwarding, ...

All site have the same configuration except for the subnets.
Everything was working before when on Meraki, now on Ubiquiti EdgeRouter.
I use this kind of setup in many places with VoIP with no problem, first time with Avaya.

And I also want to add that I tried I lot of things on site B, like disconnecting the working phone and try make the bad one boot, replace the bad phone with one that was working on Site A, upgrade of the PBX (and phones at the same time), replaced patch cords, switch various phones, and so on. A lot of stupid things just in case.
On site C, only phones are connected to internet, so don't bring possible injections or some kind of viral infections.

Anyone has an idea? Questions?
Thank you for your time.
Francois

 

[FrankSider12]

Hi,

If it can help someone someday, here's the solution to my mystery!

By default, Avaya IP Phone has the 802.1Q option set to "AUTO" with a VLAN ID of 0. When set to AUTO, if there's no OPTION on DHCP, the phone will activate the VLAN.

After a factory reset, the default VLAN was back to 0, so the 4 bytes inserted where 81 00 00 00. So I expect at some point in the past, some put 192 in the default VLAN ID. That would explain the initial 81 00 c0 00. 81 00 being the EtherType for tagging and c0 00 the VLAN.

Site A has a high end switch and must have discarded the VLAN prior to sending the packet to the router then the VPN.
Other site only have entry level switches.

So, reconfigured non-working phone with the 802.1Q option to OFF.

Have a nice day
Francois