OpenVPN LAN2LAN VPNs break Cisco and Linksys SPA phones - not exactly - part 2

FreePBX Networking
1

I wanted to post an update to a post I made earlier this year that has been closed due to inactivity, that post is here:

After more testing I’ve found the following info out:

  1. I haven’t shifted over to Wireguard - yet. Not sure if I will since now, the setup I’m using is working.

  2. I shifted my trunks from chan_sip to chan_pjsip. I don’t know if that matters. Still am using the same VoIP gateway hardware/firmware, though.

  3. There definitely is some nonsense going on inside of OpenVPN. But, it may not be what I thought it was originally. It may simply be that - like any VPN - OpenVPN sets aside some packet space for overhead - and in order for that to work, OpenVPN routers must respond with Packet To Big ICMP responses. Over the years OpenVPN implementations on hardware HAVE in fact failed to do this - sometimes due to code issues in OpenVPN itself - sometimes due to poor defaults in implementations of OpenVPN in router distributions like DD-WRT - but current implementations can be badgered to work properly.

  4. Of course, along with proper MTU Path Discovery support in VPNs you must also have support for it in the TCP/IP implementation in both the server (Debian & Asterisk) and the client (the phone) and this is where it may be that the different Cisco phone implementations have fallen on their face. I don’t know. I just know the last time we tried looking at protocols with packet captures the results were inconclusive - which is not uncommon when the TCP/IP implementation is broken with MTU - packets will just not arrive at the sniffer or arrive incomplete.

  5. It is a total crapshoot with the Cisco phones running Enterprise firmware if they will work or not.

Anyway, here are my current testing results for the phones I’ve tested:

Phones that WORK properly over the VPN - calls have 2-way audio both directions:

Cisco CP-8845 running Enterprise firmware version 12-8-1-0101-482

Cisco CP-6941 running 9.4.1.3.SR3

Cisco CP-7841 running 3PCC firmware 12-0-4MPP0001-195 (I’d assume all 3PCC Cisco phones would work but I don’t have all models to test with)

Cisco CP-7961G running 9-4-2ES26

Snom 360 running version 8 firmware

Polycom VVX 201 running UC Software version 6.4.7.4477

Phones that DO NOT work properly over VPN:

Polycom SoundPoint IP 550 running UC Software version 4.0.15.1009 - registration failures in moderately busy periods of time on the Internet.

Cisco CP-7940, CP-7906

Cisco 7841 running version 12 of Enterprise firmware

Cisco CP-8941 running 9.3.x firmware. There is newer 9.4 firmware for this phone model but it crashes on video calls with Asterisk - not with the Cisco PBX, however.

Note that only newer Cisco phone models can run 3PCC firmware.

Note that the 7841 running 3PCC works, the same hardware 7841 running Enterprise does not work. Based on this, it’s clear that this is a bug in the Cisco Enterprise firmware. There IS version 14 of Enterprise firmware available for those phones but it’s not compatible with older Cisco PBXes.

Note also that the phones that DON’T work over a LAN2LAN OpenVPN, -do- work over a routed network from remote subnets. So it isn’t the fact that phones are on different IP subnets that’s the problem - it’s definitely the VPN that is interacting here with a bug in the phone firmware.

Note that if this bug is an MTU bug or in the RTP it would likely affect Cisco Enterprise phones being used with a Cisco UCM PBX, on a WAN made up of VPNs.

I may try some other phones in the future on this setup and if so I will update this post. But clearly, the takeaway is if you have sound not working in one direction but working in the other, over a VPN, and you are positive that it’s not a NAT issue, you would be well advised to attempt to test your VPN setup with different models and firmware versions of phones.

2

A common reason for breaking path MTU discovery is paranoia about ICMP, which means many managers completely block ICMP. Using the don’t fragment flag for UDP will completely break long datagrams.Path MTU discovery only works for TCP, not UDP.

The common problem with UDP is that firewall rules are set to only recognize the the first fragment of a fragmented datagram, so the second part of long requests gets thrown away, so the datagram never fully arrives.

(Path MTU discovery, for TCP. uses don’t fragment and the resulting ICMP fragmentation required responses, to deduce the MTU value, so it requires don’t fragment to be set, and ICMP fragmentation required to be propagated.)

1 Like
3

All correct. The other thing to remember is that unlike TCP, applications that use UDP are responsible for doing their own MTU path discovery, black hole discovery, and the like. And, SIP is often configured to use UDP, and RTP voice is carried via UDP. So, phones and the Asterisk application, need to pay attention to fragmentation and all that messy stuff - because with UDP, the TCP/IP stack in the operating system won’t do it for them.

This is why sometimes you need to set some phones to use TCP instead of UDP for registrations through a VPN. I have found for example with Polycoms that I have to set the Soundpoint IP 550 to force TCP for registrations to keep the phone from going to a registered-but-unavailable state through the VPN, while the VVX 201 is fine with UDP registrations though the OpenSSL VPN. This is probably because the firmware in the 201 is newer and able to cope with MTU changes better.

1 Like