Hi,
sorry for riviving this old thread, but I had almost the same problem.
Now (today, 4 1/2 years later) it is working. I just want to share my config to everyone who will find this thread.
My phone is "Enterprise IP Phone SIP-T42G", I know: another model! Firmware version "29.82.0.20"
The Routerboard/MikroTik I use is "hex" "Model: RB750Gr3" with Firmware version "RouterOS v6.47.7 (stable)"
The content of vpn.cfg is:
Code:
client
nobind
remote FQDN-of-Server 1200 tcp
dev tun
dev-type tun
verb 3
resolv-retry infinite
persist-key
ca /config/openvpn/keys/ca.crt
cert /config/openvpn/keys/client.crt
key /config/openvpn/keys/client.key
auth-user-pass /config/openvpn/keys/auth-user-pass.txt
# here is the pbx I want to register/use; setting up the route
route 192.168.0.0 255.255.255.0
cipher AES-256-CBC
Do not use
which is not supported on MikroTik (and remember: encryption of compressed data is a "good base for a plain text attack")
Sure, improvements are needed. No Checking wether the server is the right is not a good way ... hint:
Code:
tls-remote / verify-x509-name
...
The MikroTik OpenVPN-Server settings are:
Code:
[admin@VPN-Router] > /interface ovpn-server server print
enabled: yes
port: 1200
mode: ip
netmask: 24
mac-address: FE:26:01:xx:xx:xx
max-mtu: 1500
keepalive-timeout: 60
default-profile: default-encryption
certificate: Name-of-certificate
require-client-certificate: no
auth: sha1,md5
cipher: blowfish128,aes128,aes192,aes256
Code:
[admin@VPN-Router] > /ppp profile print
Flags: * - default
0 * name="default" use-mpls=default use-compression=default use-encryption=default only-one=default change-tcp-mss=yes
use-upnp=default address-list="" on-up="" on-down=""
1 * name="default-encryption" local-address=192.168.210.1 remote-address=pool-OpenVPN use-mpls=default
use-compression=default use-encryption=yes only-one=default change-tcp-mss=yes use-upnp=default address-list=""
on-up="" on-down=""
Code:
[admin@VPN-Router] > /ip pool print
# NAME RANGES
0 default-dhcp 192.168.88.10-192.168.88.254
1 pool-OpenVPN 192.168.210.10-192.168.210.99
Sure, improvements are possible ... like removing auth:md5; cipher:blowfish ... feel free. I tested many configurations and "here and there is some dirt ..."
Some hints about debugging (at least my way)
- Instead of installing a syslog-server in my (windows)machine, I used "Wireshark". The phone (WebUI: Settings / Configuration / Syslog Server) was pointed to my machine and the Wireshark-capture-filter was set to "host IP-of-yealink" the display-filter was set to "syslog". So I got as less packets as possible . "syslog Level" has been set to "6" (instead of 3, default); "Enable" syslog ...
- So I was able to read the "syslog-data" easily. In Syslog I get all what the openvpn process writes out. So I was able to tweak the config-file step-by-step / error-by-error / warning-by-warning
- I "learned" to reboot the phone after uploading a new "openvpn.tar"-file
Problems on my way ...
- The docs (pdf and support-site) of Yealink I read did not offer which version of OpenVPN is installed in which Firmware-version of the phone
- I did not knew which certificate-signature-mechanism is "allowed/understood" in the implementation of Yealink. I have sha512. I know this is a problem in OpenVPN 2.3.6 (very old version)
- There are different informations about "auth-user-pass"-compatiblity in Yealink. Some users write: impossible. I found: Yealink had an example. So it should work ... MikroTik needs user/pass!
- Up to now I do not know wether it is possible to use <cert>...</cert>, <ca>...</ca> and <key>...</key> in the vpn.cfg instead of referencing the files in the /keys - folder . this is another test in the future.
- I did not found a list of compatible ciphers (like
Code:
openvpn --show-ciphers
on the command line). So I went backward to the default of OpenVPN (BF-CBC; which is "blowfish 128 cbc" and "insecure") and tested one cipher after the other ...
I spend many hours on this issue ...
... Now I have many different Yealink-phones to configure, cordless (dect), corded, ... Most of them are on a remote site ... Hopefully I will not loose the connection to the phones ...
Enjoy your own issue-digging ....
