Yealink phones



  • We're looking at PBX's and may be going the 3CX route.  They list two following Yealink phones as supported: T42G and T46G.

    OpenVPN client export utlity mentions being able to export configs for T28, T38G (1), and T38G (2)

    Anyone know if the exported OpenVPN configs can be used with the T42G and T46G's?



  • I've used T38G (2) for T46 and it works fine. The only thing that changes between the different VPN configurations is the path were the configs are saved to on the phones. I'm not sure if the others could work on the T4x because the first one I tried was the T38G (2) and it worked  ;D



  • Hi,
    The OpenVPN Server configuration for T-38G Phones drives me Nuts!
    I can´t get the tunnel to Work an I cant find a usable documentation…. the one from Yealink ist outdated and the others Mentioned in other Threads inaccessible!

    Would you Please be so nice an tell me your Options for the VPN Server an Client - i´d really really appreciate that  :D



  • Yeah, Yealink phones don't have any form of status or logs to see whats going on with the VPN…

    Here are the relevant Server settings I'm using:

    • Server Mode: Remote Access (SSL/TLS)

    • Protocol: UDP

    • Device Mode: tun

    • Port: 1194

    • TLS Authentication: Enable (using 2048bit static key)

    • CA and server certificate used are generated at the Certificates menu

    • DH: 1024

    • Encryption: AES-128-CBC

    • Other settings: Using compression LZO, ToS IP header, Allow communication between clients

    • Client Settings: Provide a virtual adapter IP address to clients (checked). I also provide DNS domain, NetBIOS over TCP and WINS server

    • Advanced configuration: I push several routes from my network, but you might not need that

    Then using Client Export, like I mentioned, I use the T38G (2) file, upload it to the phone, and reboot.

    I guess it might help if you look at the openvpn logs while testing, to see what might be going on.



  • pfSense 2.1
    OpenVPN Client Export Utility 1.1.3

    I am in the process of updating my Yealink OpenVPN document and have hit a snag. In my original document I was creating a user account with an associated certificate for each phone. The user account is really unnecessary as there is no User Auth with the Yealink OpenVPN client, so I would like to only generate the certificate. This is fine if you are manually creating the Yealink config tarball. However, when I go to export the config via the OpenVPN Client Export Utility there are no users to select from. I only get an option there if I create a user account.

    So for those of you using the Client Export Utility, are you creating a user account for each phone? If you are only generating the certificate and not a user account, how are you exporting it using the Client Export Utility?



  • It looks like you don't have any user certificates, so the client export has nothing to export.



  • The user cert is there and as you can see issued by the correct CA:



  • Hmm., is the CA for your phone accounts defined in CAs and the OpenVPN Server? I do have one certificate for each phone and works fine.



  • Ok, I completely removed everything and started from scratch and the certs are now showing up in the Client Export Utility. Here is my updated doc for anyone who is interested.

    http://www.sunstatetechnology.com/docs/YealinkOpenVPNGuide.pdf



  • Hi Guys,
    I have the same Problem with a Yealink-T38G, Firmware 38.70.150.2.
    I Created the Psense Side according to the Yealink Documentation, with the Wizard and with sscardefield´s really,really Great Documentation - but nothing works.
    I have even reinstalled Pfsense from Scratch….

    I have found three things which doesnt´t work if you use the Export Utility
    1. You have to unpack and repack the generated client.tar with 7zip on Windows - if you don´t your Phone wouldn´t import the File.
    2. If you leave the Line "verify-x509-name PhoneServer name" in the generated vpn.cnf the Phone can´t import the file either.
    3. There seems to be a problem with the generated Certificates, the Phone (If you set Phone >Configuration > Log Level to 6 you get a usable Logfile which you can export)
    It shows the following Error:
    Nov  7 21:20:48 openvpn[289]: IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
    Nov  7 21:20:48 openvpn[289]: NOTE: OpenVPN 2.1 requires '–script-security 2' or higher to call user-defined scripts or executables
    Nov  7 21:20:48 openvpn[289]: Re-using SSL/TLS context
    Nov  7 21:20:48 openvpn[289]: LZO compression initialized
    Nov  7 21:20:48 openvpn[289]: UDPv4 link local (bound): [undef]:1194
    Nov  7 21:20:48 openvpn[289]: UDPv4 link remote: 213.221.100.187:1194
    Nov  7 21:20:48 openvpn[289]: VERIFY ERROR: depth=1, error=certificate signature failure: /C=DE/ST=Hessen/L=Floersheim/O=Lorenzgroup/emailAddress=support@lorenzgroup.com/CN=PhoneCA
    Nov  7 21:20:48 openvpn[289]: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
    Nov  7 21:20:48 openvpn[289]: TLS Error: TLS object -> incoming plaintext read error
    Nov  7 21:20:48 openvpn[289]: TLS Error: TLS handshake failed

    IOS, Android and PC Clients connect without Problems,i am now really out of Ideas - Anybody else please?!



  • Maybe the CA certificate is not correct or missing? I didn't need to re-zip anything, and it pretty much worked the first time… Also, I am not seeing the verify-x509-name line in my vpn.cnf file the Client Export Utility is creating for me. This is what my vpn.cnf looks like:

    dev tun
    persist-tun
    persist-key
    cipher AES-128-CBC
    tls-client
    client
    resolv-retry infinite
    remote [my server name] 1194 udp
    tls-remote openvpn-pfsense
    ca /config/openvpn/keys/ca.crt
    cert /config/openvpn/keys/client1.crt
    key /config/openvpn/keys/client1.key
    tls-auth /config/openvpn/keys/ta.key 1
    comp-lzo
    passtos
    
    


  • Hi Gus,
    Thanks for the Info! Maybe you could be so nice an give me some more Information?!
    Which Versions are you using?
    Mine are the following!

    pfSense:
    2.1-RELEASE (i386)
    built on Wed Sep 11 18:16:22 EDT 2013
    FreeBSD 8.3-RELEASE-p11

    Export Package:
    1.1.3.

    And did your Create the Certs and the Server via the Wizard or manually?!

    I really appreciate your Help, so thanks in Advance!


  • Rebel Alliance Developer Netgate

    On pfSense 2.1 we increased the security of the certificates to use SHA256 as the default Digest Algorithm. From what I've heard, those Yealink phones may only support SHA1.

    There was a small bug in 2.1 that prevented the GUI drop-down for Digest Algorithm from being respected so it always used SHA256. You can use the System Patches package to apply commit fd750cd064a46f364a7e06c9fe27d46ce11cd09a which will fix the selection of the Digest in the GUI.

    If you apply that fix and then generate a new CA/certificate using SHA1, it should work



  • Just to confirm, my certificates are signed SHA1 so this might be your solution for Yealink phones.



  • Thanks to both of You!- You are a Great Help!
    According to yout suggestions I reinstalled PFsense from Scratch (again), installed Patch http://github.com/pfsense/pfsense/commit/fd750cd064a46f364a7e06c9fe27d46ce11cd09a.patch and Created new Ca,Certs,openVPN Server etc. then the Export Utility. (Because I like Clean installs to start…)

    The Export Utility won´t show me the Created User Certificate if I choose "SHA1" in Ca,ServerCert and User Cert and I don´t know why?!
    (Choosing SHA256 does work - but not with the Phones)

    I saw on tre Github Changelog that they changed it to " tls-remote is deprecated, use verify-x509-name, which also works on the iOS client so no need to exclude it from getting the line either." - but that doesn´t work with the Yealink Phones. Maybe it is possible that they Change this for the Yealink Export??

    But even if I export the Certificates manually and create the vpn.cnf by hand the Phones don´t accept the Certificates - i am not Sure if the Patch mentioned above does really cover all options to choose "SHA1".

    It would be really really Great if you Guys from PFsense could fix this - I thinc PFsense is a really really Great Choice for the many many People who use SIP Communication Systems an need /want Secure Communication....

    I can´t find a older Version of PFsense or the Export Utility -  i Think anybody who upgraded from 2.0.3 wit already created Certs and Export does not have this Problems?!



  • Well, it looks like you are making a hobby of reinstalling pfSense from scratch  :D,  so with the current situation, how about installing from scratch on version 2.0, test out your Yealink phones, then upgrade to the latest 2.1? If you still want to to continue testing regarding SHA2, you can create new CA certificates on 2.1 until its resolved, but at least you now have a working setup for Yealinks in the meantime.

    I've been upgrading since version 1 so at least its working for me. I can understand your position on clean installs, but I don't think pfSense carries much trash from version to version, so I wouldn't worry about it too much.



  • I played with this a bit today and here are my findings.

    pfSense 2.1
    Export Utility 1.1.3

    Before testing I applied the patch jimp mentioned via the Patches utility. From what I can tell it took:

    Afterwards, I recreated my server cert and user cert telling it to use SHA1 for both, then applied the new cert to my OpenVPN instance and exported the new config files via the Export Utility. Here is how it played out:

    T38

    38.70.0.105 - The phone won't accept the Export Utility config file T38 (1) or (2)
    38.70.0.180 - The phone won't accept the Export Utility config file T38 (1) or (2)

    T26

    6.71.0.140 - The phone accepts the Export Utility config file but makes no attempt to establish VPN connection during bootup (verified via packet capture)
    6.71.0.149 - The phone accepts the Export Utility config file but makes no attempt to establish VPN connection during bootup (verified via packet capture)

    If I get some time tomorrow I will manually create the config files and see if they take.



  • Hi Guys,
    Yes I am a true Reinstall Enthusiast…. well more a "Revert to Snapshot" Enthusiast  ;)

    I get the same results as Seth, If I Use PFsense 2.0.3 everything works well - except the Export Utility which they updated to 2.1 I think.
    But You can Create all Certs and the Server without Problems. You have to export the Certs and make your own vpn.cf  - and If you use the latest Version of 7zip - you can get all of that together in a client.tar which Yealink Phones Accept! Works like a Charm!

    Soooo, If the Guys from the PFsense Team examines this Problem with Version 2.1 - I belive it´s something else than a plain GUI Issue -
    and Change the Export Utility back to a for Yealink Phones working Version, I would be more than Happy... and not just me I guess  ;D

    Does anyone know if there is an option to get an older Version of the Export Utility - or how to Contact the developers and inform them about this Issue?!



  • Hi Again,
    I have a Update for the Export Issue:
    You have to install it AFTER you Create your CA etc. I removed and reinstalled the Export utility Package an Voila: It shows the Certs an generates the client.tar.
    But the contents of the File are still incompatible with the Yealink Phones:

    The Export Utility generates this file:
    dev tun
    persist-tun
    persist-key
    cipher BF-CBC
    auth SHA1
    tls-client
    client
    resolv-retry infinite
    remote xxx.xxx.xxx.xxx 1194 udp
    verify-x509-name LGPhoneServerCert name
    ca /phone/config/openvpn/keys/ca.crt
    cert /phone/config/openvpn/keys/client1.crt
    key /phone/config/openvpn/keys/client1.key
    comp-lzo

    The Working one is:
    client
    dev tun
    persist-tun
    persist-key
    proto udp
    nobind
    remote xxx.xxx.xxx.xxx 1194
    resolv-retry infinite
    ns-cert-type server
    comp-lzo
    ca /phone/config/openvpn/keys/ca.crt
    cert /phone/config/openvpn/keys/client1.crt
    key /phone/config/openvpn/keys/client1.key

    So, if the revert their Update from "verify-x509-name LGPhoneServerCert name" back to "ns-cert-type server" it seems that everything will work with 2.0.3….


  • Rebel Alliance Developer Netgate

    Reinstalling pfSense or the package in another order before/after creating certificates wouldn't matter. The export package reads the certificates directly from the config, and doesn't change them. Reinstalling may have pulled in a newer version of the export package than you had before, but otherwise wouldn't have changed anything substantial.

    I updated the export package to skip the verify-x509-name line if the export is happening for a Yealink or snom phone, or if the config is auth only.  I found last week that an auth-only setup would not even attempt to connect if that line was in the config, even on the latest client. And the Yealink/snom OpenVPN clients are so old/crippled they don't support it.

    Version 1.1.4 should show up in a few minutes.



  • Alright, I think we are good now. I removed everything and started from scratch (I'm weird like that too). So now using Client Export Utility 1.1.4 and SHA1, both the T26 and T38 successfully connect. And just to verify, I reset everything and used SHA256 and neither phone would connect. So the OpenVPN client on the Yealinks definitely only works with SHA1.

    Thanks for all the help jimp.



  • @sscardefield:

    Alright, I think we are good now. I removed everything and started from scratch (I'm weird like that too). So now using Client Export Utility 1.1.4 and SHA1, both the T26 and T38 successfully connect. And just to verify, I reset everything and used SHA256 and neither phone would connect. So the OpenVPN client on the Yealinks definitely only works with SHA1.

    Thanks for all the help jimp.

    Really? it didn't work for my T20P phones this way….
    Even when you create your certificates selecting SHA1 encryption (1024 or 2048 key) the signature algorithm is still sha256RSA instead of sha1RSA and that didn't work for my Phones.
    What i did was make the certificates for CA, Server and User (the phones) in PfSense 2.0.3 and export them and after that import them on PfSense 2.1.
    Then create the OpenVPN server with these certificates and export the T28 client, with 1.1.5 that works again.


  • Rebel Alliance Developer Netgate

    @Makje:

    @sscardefield:

    Alright, I think we are good now. I removed everything and started from scratch (I'm weird like that too). So now using Client Export Utility 1.1.4 and SHA1, both the T26 and T38 successfully connect. And just to verify, I reset everything and used SHA256 and neither phone would connect. So the OpenVPN client on the Yealinks definitely only works with SHA1.

    Thanks for all the help jimp.

    Really? it didn't work for my T20P phones this way….
    Even when you create your certificates selecting SHA1 encryption (1024 or 2048 key) the signature algorithm is still sha256RSA instead of sha1RSA and that didn't work for my Phones.
    What i did was make the certificates for CA, Server and User (the phones) in PfSense 2.0.3 and export them and after that import them on PfSense 2.1.
    Then create the OpenVPN server with these certificates and export the T28 client, with 1.1.5 that works again.

    You must not have applied the patch I posted earlier in the thread. Without that patch the GUI doesn't properly let you select SHA1.



  • @jimp:

    You must not have applied the patch I posted earlier in the thread. Without that patch the GUI doesn't properly let you select SHA1.

    You are correct, somehow i thought that wasn't necessary anymore… My mistake :-[



  • Hi Guys,
    Now that I tested everything back an forth, ist seems that with the Exporter Update 1.3.4 and the GUI Patch Pfsense 2.1 works totally great!
    (And it doesn´t matter if you did an Update from 2.0.3 or a Clean install with 2.1)

    I Tried T-38G,T-26P and T-22 Yealinks and everything works like a charm.

    Thank you all so much for your help! - I am definitly getting a "Gold Membership" just to value your efforts! -  There are many commercial company´s out there with lesser ability to help with problems.

    (And maybe if you put another membership in between the Gold Membership for 99$ and the Support subscription for 600$ some more people like me are willing to pay you some more for yout really really great support)

    Thanks!
    Christian



  • Hi All,

    This may be my second post here.  This forum is a fantastic resource for being spot on for resolution.  I am having an issue with this set up as well.  I am using Yealink T20P phones, pfSense 2.1, Export Client 1.2.4 and the applied GUI Patch all successfully installed according to pfSense.  I removed everything, the CA, Server/Client Cert and Server and used different export methods, x509, tls-auth, with CN, without CN…I have tried everything and I keep getting UNDEF in my connection for the Phones.  The log states "TLS Handshake failed" and "TLS key negotiation failed to occur within 60 seconds".  I used the TLS authentication checked and unchecked, the VPN connects but states the same error and a virtual address is not assigned from my block.

    I am using the T.28 export. 
    I removed the old cert on the T20 by disabling the VPN, reboot, upload new config and reboot.  I have a static public IP on the Server and the IP phone is in the DMZ of a Linksys WRT54G2 on my ADSL router.  My Windows and Android clients connect perfectly via another session on the same physical server.  Can anyone assist/guide me as to what I am doing wrong?  Could this be a NAT issue?


  • Rebel Alliance Developer Netgate

    there should be a client log you can get from the phone that has more detail.

    If it times out like that, the client usually is rejecting something from the server, or something in its config.

    Top suspects are usually either the clock, or the phone not liking something else about the certs.



  • Hi Jimp,

    Thank you very much for the reply and your guidance, I was able to figure out the issue from the phone logs as you said.  The issue that came up was:

    "TLS Error: Unroutable control packet received from "x.x.x.x:1194" (si=3 op=P_CONTROL_V1)" …....(I hid my IP)

    I was able to get a clue to the issue using this site:

    http://glycogen.net/2012/12/01/pfsense-openvpn-server-with-dd-wrt-clients/

    It eluded to an issue with the Common Name used in the CA Server Certificate, which must be a FQDN.  This baffles me, maybe because I am new to this, however can you or someone else on this forum explain why this is necessary for these phones while a non FQDN Common Name works with my PC and Android phone?  Does it have to do with the version of the OpenVPN/Client and the method used?  Any information to help me understand this better would be greatly appreciated.


  • Rebel Alliance Developer Netgate

    The clock/time is the most common cause of that particular error that I have seen. I am not aware nor have I seen anything require an FQDN for the cert CN.



  • Thanks.  I implemented the solution today.  During the Holidays it is near impossible to gain access to/leave our building due to the City area being extremely busy for shopping.  As a rule we work remotely for this week, however I moved the PBX to another more manageable and secure network.  The work we do is similar to a NOC, but Tier 2 which is on call.  When persons try to contact the office it was difficult to get to my Staff members or the member needed to fix a problem.  My staff can now work remotely using their Cell, Yealink or PC Soft Phone to remedy issues when someone calls the office PBX.

    Thanks to you Jimp for guidance and showing me/us how to patch the GUI  issue and also to sscardefield….a fantastic job of putting the step by step guide together showing the creation of Certificates for OpenVPN both with and without User Authentication.  This actually got me to understand the process better than using the wizard.  Thanks to everyone else who participated in this thread as well.


Log in to reply