Yealink T22P + OpenVPN: Can't hear the remote phone user
-
Hi all,
I followed the excellent documentation at http://www.sunstatetechnology.com/docs/YealinkOpenVPNGuide.pdf
Everything looks ok, but I can't hear the user of the remote phone (but he can hear us). In System logs > Firewall, I see that the remote phone packets are being blocked by no specific rules (as far as I can see).
What I see is the Source as the public IP address of that user (the phone is behind a firewall) and the public address of our firewall (WAN) as destination. Ports are in the 10000-20000 range and different on both side. This is blocked.
What surprises me is that I would assume that the source IP address would be the SIP-T22P OpenVPN address. But it is not. This is the public IP address of the remote router.
I can't understand or identify the reason for this problem. I followed the above guide, with the only exception that I added a qVoip. The problem is really the blocked packets with that weird IP address.
Thank you for your help,
Alexandre Leclerc -
Given the wrong source IP on the traffic, your OpenVPN server config is wrong, missing pushing a route to the PBX subnet.
-
Hi cmb,
I followed the "guide" but probable there is something I'm missing. How can I check the traffic is pushed properly to the subnet where the PBX is located?
Thank you for your help,
Alexandre Leclerc -
If you follow that guide to the letter, you'll end up with something Yealink phones can't use, as they don't support 2048 bit certs. Maybe it's not connected at all, check Status>OpenVPN. If it is connected there fine, then your "Local Network" on the sever is wrong.
-
Thank you cmb,
I re-maked all the certs in 1024 bits, using SHA1. I'll test that later today.
From my home I'm not able to make the remote test phone connect at all. It's like if my home router was blocking the VPN packets and I'm getting a TLS handshake failure (TLS key negotiation failed to occur within 60 seconds).
For the other remote phone, it was properly connected but the incoming packets were not routed on the network (because the external IP address of the phone was displayed instead of its VPN IP address, I guess). The local network was ok in the VPN settings (192.168.2.0/24). I can't explain. But I'll be able to test with that user later today. Maybe I'll check the option "Force all generated client traffic through the tunnel".
Thank you for all your help.
Best regards,
Alexandre Leclerc -
"TLS key negotiation failed to occur" with those phones is what happens when you're trying to use a cert that's incompatible with the phone. Your "local network" setting sounds ok, fix the certs and I suspect you'll be fine.
-
Hi cmb,
For the "TLS key negotiation failed to occur" it was fixed when date and time on the phone were correct. So both phones are properly connected to OpenVPN.
Now I still have the same problem with packets. Here is what I see in the syslog:
block May 16 10:18:00 WAN <external ip="" home="">:10000 <external ip="" office="">:10728 UDP
All the traffic is blocked. Here is what I see in the OpenVPN status page:
TestPhone <external ip="" home="">:1194 10.0.2.6 Fri May 16 10:17:15 2014 253361 14792
Routing Table:
TestPhone <external ip="" home="">:1194 10.0.2.6 Fri May 16 10:22:17 2014
I receive all packets, but everything the phone sends is not correct. I also added in the advanced config of OpenVPN a push "route 192.168.2.0 255.255.255.0" just in case. But it changed nothing.
Maybe I should try to reboot pfSense? Because all the configuration looks correct. It's just that the incoming packets from the VPN tunnel are handled with the "WAN / external IP home" instead of the "OpenVPN / 10.0.2.x" address as I would assume it should be.
Thank you very much for all the help you willingly gave me up to now.
Best regards,
Alexandre Leclerc</external></external></external></external> -
Hi all,
OpenVPN tunnel is working.
After 20 sec. the communication is cut by the PBX because it has no answer to some of its packets. I suspect that pakets sent to 10.0.2.10 (the phone at the other end of the tunnel) are not handled properly (either when sent or received).
Is there a firewall rule I'm missing for any kind of packets sent from our local network to the remote phone in the VPN tunnel?
As for the packets that looks like they are coming from the external WAN/public IP of the remote phone instead of its tunnel IP address, I simply by-passed by adding rules to accept all WAN traffic. But this is not the solution I expected.
Thank you for any help.
Best regards,
Alexandre Leclerc