HOW TO: Implement Secure, Plug and Play, Remote VoIP Extensions w/ 3CX IP PBX, SNOM 370 IP Phones and an OpenVPN Infrastructure By: Mike Harris, Worksighted Inc. http://www.worksighted.com Summary: One critical aspect of a SIP based VoIP phone implementation is the need for remote extensions. By remote, I am referring to any phone (physical or soft) that resides off of the main network where the IP PBX resides. The typical challenges I was looking to address were: 1. SIP/RTP do not offer any inherent security over the internet 2. SIP/RTP are UDP based (hence connectionless) protocols and typically require firewall modifications both on the local and remote ends (not easily done at the CEO s house or perhaps a customer s network or maybe the hotel). 3. SIP s simple password based authentication is terribly weak, easy to intercept and not the most desirable thing to allow through your firewall 4. NAT creates a lot of difficulties with SIP Registrations and RTP 5. Remote endpoints typically use DHCP on the WAN side (cable and DSL) and hence change IP addresses often which breaks or SIP registrations. 6. We need to be fairly firewall tolerant. In other words, we don t want our phone to be having it s outbound traffic blocked because we use an obscure port. This needs to be flexible. So, any real solution should address these issues. But, there is one more critical aspect of this that I was seeking to address. I wanted the solution to be self contained. What do I mean by this? Often times the vendor of the IP PBX system does not have control over the core data network. We do not have control of existing VPN appliances, core routing and switching or firewalls. We typically have to request these items from existing IT personnel or another firm who manages the network. So, I wanted this solution to require as few requests (and any requests must be simple ones) as possible of an outside entity. At install time, I wanted to be able to make a few simple port forward requests and that is all. Most companies today have some type of VPN infrastructure in place. This makes the soft phone problem fairly easy to solve over existing infrastructure. Just connect to the VPN at the office, launch my soft phone and I m off and running. All of my traffic is routed over the VPN securely, we are using all private addresses and we have just solved all of our problems. But what about physical phones? How do we solve this issue with a hardware phone? And what if a customer does not have an existing VPN? How do they use a soft phone? Some thinking led me to the question.what about an IP phone that has a VPN client of some type in firmware? Perhaps this could work? If we could do bridged Ethernet then I wouldn t have to worry about routing as the phone would appear on the same subnet and LAN segment as the rest of the corporate phones. Well, after some digging I found that there were products out there to do this job! OpenVPN provides a free, opensource, SSL based VPN solution where the server can run on Windows and is capable of running in a bridged mode. Additionally, the SNOM 370 IP phone offers a specialized firmware revision with the OpenVPN client software embedded.
So, this formed the basis of the solution: 1. The core PBX is 3CX running on Windows XP SP3 2. We will use OpenVPN to provide a secure, SSL based, bridged VPN as well as offer soft VPN connections as needed 3. SNOM 370 IP phone as our remote hardware phone running appropriate firmware Implementation: Implementation has four major pieces: 1. Install and configure OpenVPN server and configure Public Key Infrastructure 2. Configure OpenVPN client, test and package tarball for SNOM 370 3. Flash firmware on SNOM 370 4. Enable VPN on SNOM 370 / Upload tarball with configs and certificates While this may seem like a lot of work, once it s working, most of it doesn t ever need to be repeated. Setting up additional phones involves flashing their firmware and uploading some config files but even that only needs to happen once per phone. don t blame us ************************************************************************* This information is provided AS IS without any warranties express or implied. You use this information at your own risk. It is recommended that you practice this on NON- PRODUCTION equipment. If you break your network or PBX or your phone or your server. IT IS YOUR FAULT. You hold Worksighted, Inc. completely harmless. *************************************************************************
OK, that s out of the way.let s begin! Phase 1: Installing OpenVPN server on the 3CX PBX and Creating PKI (assumes Windows XP and Admin rights) **Special thanks to the folks at OpenVPN for making this possible with their excellent software released under the GPL. You can visit their website at http://www.openvpn.net. Step 1: Initial Install of OpenVPN Server 1. Download OpenVPN Windows installer package here (server and client are the same install) a. http://openvpn.net/release/ Note: I am using the Release Candidate rather than production candidate. The RC has some nice new features and I have found it to be stable. Just be aware that they are releasing updates to the RC regularly as of this writing. 2. Run the installer. 3. Sure we ll install everything you tell us to!
4. We love the defaults 5. You will get this warning about the TAP adapter, select Continue Anyway. Note: I ve noticed the TAP driver install will sometimes pause a minute or so be patient.
6. We re done! 7. Click Finish.
Step 2: Bridging your LAN and OpenVPN virtual TAP Adapter on PBX WARNING: If you are working on this remotely this will your connection (as well as interrupt all network connectivity) to the PBX. Beware!!!! 1. Open Network Connections Window 2. Rename the TAP-Win32 Adapter to tap-bridge 3. You will note one adapter is your tap-bridge and another is your actual Local Area Connection adapter. The tap-bridge is the virtual adapter that OpenVPN binds to. We are going to Bridge these two adapters when you do this your LAN connection will break!!! 4. Hold the Control key ctrl and select both adapters by left-clicking once on each. 5. Now Right-Click on one of the highlighted adapters and select Bridge Connections
6. You will see this message for a few minutes (maybe 5 minutes).be patient, have coffee. NOTE: I have had this actually hang on me here and have had to reboot so be aware that it is not totally abnormal. In other words crashing is normal 7. When completed you will have a Network Bridge that is set to receive a DHCP address by default. Your other two adapters that are used to construct the bridge will lose any TCP/IP Properties as well as their ability to have independent properties. You will need to set your static IP that your 3CX server normally has on the Network Bridge. 8. Now, we need to set our static IP back onto our Network Bridge. This should be the IP that you want your OpenVPN/3CX server to have.
9. That s it for our Bridged interface! At this point your 3CX server should function normally again. You may need to reboot once and let some phone s re-register but from here on out we shouldn t need to break our network connectivity again (maybe). Step 3: Creating our PKI (Public Key Infrastructure) with OpenVPN OpenVPN uses certificates based, mutual authentication to provide security. The first ciritcal piece to this is to create the Certificate Authority, in other words, the thing that makes the certs that all the devices trust to make the certs. 1. First we must generate our CA (Certificate Authority). So, open a command prompt and cd to C:\program files\openvpn\easy-rsa\ 2. Type init-config and hit enter. 3. Your output should look as follows. 4. Now we need to edit the vars.bat file with the appropriate information for KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL and the ARE ALL REQUIRED. Just navigate to c:\program files\openvpn\easy rsa\vars.bat and right click and open with notepad. The info you need to edit is at the bottom.
5. Now type the command vars and hit enter 6. Your output should be. 7. Now type the command clean-all 8. Your output should look as follows (the cannot find file specified remark is normal in this case).
9. Now, we need to run the command build-ca. This will generate your CA certificate. When your run this command it should import some default values from the edits your made to vars.bat. If you hit enter, the program will accept the default (whatever is in the []). If you want to send a blank use the. (period) key. YOU MUST ENTER A COMMON NAME 10. OK, now we have created a CA and have generate the CA s certificate. The CA is the host which is our trusted signer for all our certificates OpenVPN will use on the server and on the phones. Our CA could be a different box than our VPN server. In this example, they are same. So, now we need to generate a certificate for our server. So, type the command build-key-server server and hit enter. You will need to supply the Common Name as server. You also need to respond Y to the two questions. Sign the Certificate? and "1 out of 1 certificate requests certified, commit?
11. Now we need to generate certificates for our phones. The procedure is the same as above but you use the command build-key client1 and enter your Common Name as client1. Go ahead and generate a few certs here for your different clients.client1, client2,client3 etc etc. 12. Last Step is to generate our Diffie-Hellman parameters. We do this by running the command build-dh. See the output below. 13. That s it! You know have a Public Key Infrastructure suitable for OpenVPN!! All of the goodies you created above are located in C:\Program Files\OpenVPN\easy-rsa\keys Phase 2: Creating OpenVPN Server and Client configs and Packaging Tarball for upload to SNOM 370 Step 1: Creating OpenVPN Configuration files for Server and Clients Note: Our configuration will reflect the fact that we are using a Bridged Ethernet setup. As well, I am going to stick with default port UDP 1194 for the server to receive connections on. You can switch this to whatever you want. TCP port 80 would be the most firewall friendly for the remote phone. Just edit the config files as appropriate and make sure IIS isn t bound to port 80 on your server.
1. Edit the default Server Configuration file located at C:\Program Files\OpenVPN\sampleconfig\server.ovpn to match the one I have posted below (edited appropriately for you scenario of course). The ; and # indicates items that are treated as remarks. Save this file as a new file at C:\Program Files\OpenVPN\config\server.ovpn # Which local IP address should OpenVPN # listen on? (optional) ;local a.b.c.d # Which TCP/UDP port should OpenVPN listen on? # If you want to run multiple OpenVPN instances # on the same machine, use a different port # number for each one. You will need to # open up this port on your firewall. #I am using the default here you could use something else to be as firewall friendly as needed. port 1194 # TCP or UDP server? #Here we are telling the server whether it should use UDP or tcp ;proto tcp proto udp # "dev tun" will create a routed IP tunnel, # "dev tap" will create an ethernet tunnel. # Use "dev tap0" if you are ethernet bridging # and have precreated a tap0 virtual interface # and bridged it with your ethernet interface. # If you want to control access policies # over the VPN, you must create firewall # rules for the the TUN/TAP interface. # On non Windows systems, you can give # an explicit unit number, such as tun0. # On Windows, use "dev node" for this. # On most systems, the VPN will not function # unless you partially or fully disable # the firewall for the TUN/TAP interface. #This part is important. Since we are using a bridged Ethernet setup we need to use Dev Tap dev tap ;dev tun # Windows needs the TAP Win32 adapter name # from the Network Connections panel if you # have more than one. On XP SP2 or higher, # you may need to selectively disable the # Windows firewall for the TAP adapter. # Non Windows systems usually don't need this. #Here we need to specify the name of the virtual adapter that OpenVPN #installed earlier and we rename to tap bridge. dev node tap bridge # SSL/TLS root certificate (ca), certificate # (cert), and private key (key). Each client # and the server must have their own cert and # key file. The server and all clients will # use the same ca file. # # See the "easy rsa" directory for a series # of scripts for generating RSA certificates # and private keys. Remember to use # a unique Common Name for the server # and each of the client certificates. # # Any X509 key management system can be used. # OpenVPN can also use a PKCS #12 formatted key file
# (see "pkcs12" directive in man page). #Here we specify full paths to our key files we created. Note that \ is written as \\ #and use quotes around the whole string ca "C:\\Program Files\\OpenVPN\\easy rsa\\keys\\ca.crt" cert "C:\\Program Files\\OpenVPN\\easy rsa\\keys\\server.crt" key "C:\\Program Files\\OpenVPN\\easy rsa\\keys\\server.key" # This file should be kept secret # Diffie hellman parameters. # Generate your own with: # openssl dhparam out dh1024.pem 1024 # Substitute 2048 for 1024 if you are using # 2048 bit keys. #This needs to be specified as well and should be in the same place for you. dh "C:\\Program Files\\OpenVPN\\easy rsa\\keys\\dh1024.pem" # Configure server mode and supply a VPN subnet # for OpenVPN to draw client addresses from. # The server will take 10.8.0.1 for itself, # the rest will be made available to clients. # Each client will be able to reach the server # on 10.8.0.1. Comment this line out if you are # ethernet bridging. See the man page for more info. ;server 10.8.0.0 255.255.255.0 # Maintain a record of client < > virtual IP address # associations in this file. If OpenVPN goes down or # is restarted, reconnecting clients can be assigned # the same virtual IP address from the pool that was # previously assigned. ifconfig pool persist ipp.txt # Configure server mode for ethernet bridging. # You must first use your OS's bridging capability # to bridge the TAP interface with the ethernet # NIC interface. Then you must manually set the # IP/netmask on the bridge interface, here we # assume 10.8.0.4/255.255.255.0. Finally we # must set aside an IP range in this subnet # (start=10.8.0.50 end=10.8.0.100) to allocate # to connecting clients. Leave this line commented # out unless you are ethernet bridging. #This directive is important as it tells the server it is operating in bridging mode. #Also, I having the OpenVPN / 3CX server hand out IPs. Since we are brdging these IPs #are ON THE SAME SUBNET as the server. #You must make sure to exclude these from your production DHCP Pool. #Could you have your existing DHCP hand out addresses? Yes, but, there are other complexities because #if you hand a default gateway out to the phone it will break the connection. #Here my OpenVPN server is 192.168.1.25 and the range I am using for dhcp is.90 to.100 server bridge 192.168.1.25 255.255.255.0 192.168.1.90 192.168.1.100 # Configure server mode for ethernet bridging # using a DHCP proxy, where clients talk # to the OpenVPN server side DHCP server # to receive their IP address allocation # and DNS server addresses. You must first use # your OS's bridging capability to bridge the TAP # interface with the ethernet NIC interface. # Note: this mode only works on clients (such as # Windows), where the client side TAP adapter is # bound to a DHCP client. ;server bridge # Push routes to the client to allow it # to reach other private subnets behind # the server. Remember that these # private subnets will also need
# to know to route the OpenVPN client # address pool (10.8.0.0/255.255.255.0) # back to the OpenVPN server. ;push "route 10.130.254.0 255.255.255.0" ;push "route 192.168.20.0 255.255.255.0" # To assign specific IP addresses to specific # clients or if a connecting client has a private # subnet behind it that should also have VPN access, # use the subdirectory "ccd" for client specific # configuration files (see man page for more info). # EXAMPLE: Suppose the client # having the certificate common name "Thelonious" # also has a small subnet behind his connecting # machine, such as 192.168.40.128/255.255.255.248. # First, uncomment out these lines: ;client config dir ccd ;route 192.168.40.128 255.255.255.248 # Then create a file ccd/thelonious with this line: # iroute 192.168.40.128 255.255.255.248 # This will allow Thelonious' private subnet to # access the VPN. This example will only work # if you are routing, not bridging, i.e. you are # using "dev tun" and "server" directives. # EXAMPLE: Suppose you want to give # Thelonious a fixed VPN IP address of 10.9.0.1. # First uncomment out these lines: ;client config dir ccd ;route 10.9.0.0 255.255.255.252 # Then add this line to ccd/thelonious: # ifconfig push 10.9.0.1 10.9.0.2 # Suppose that you want to enable different # firewall access policies for different groups # of clients. There are two methods: # (1) Run multiple OpenVPN daemons, one for each # group, and firewall the TUN/TAP interface # for each group/daemon appropriately. # (2) (Advanced) Create a script to dynamically # modify the firewall in response to access # from different clients. See man # page for more info on learn address script. ;learn address./script # If enabled, this directive will configure # all clients to redirect their default # network gateway through the VPN, causing # all IP traffic such as web browsing and # and DNS lookups to go through the VPN # (The OpenVPN server machine may need to NAT # or bridge the TUN/TAP interface to the internet # in order for this to work properly). ;push "redirect gateway def1 bypass dhcp" # Certain Windows specific network settings # can be pushed to clients, such as DNS # or WINS server addresses. CAVEAT: # http://openvpn.net/faq.html#dhcpcaveats # The addresses below refer to the public # DNS servers provided by opendns.com. #Here I am pushing my internal DNS server to the phone push "dhcp option DNS 192.168.1.10" ;push "dhcp option DNS 208.67.220.220"
# Uncomment this directive to allow different # clients to be able to "see" each other. # By default, clients will only see the server. # To force clients to only see the server, you # will also need to appropriately firewall the # server's TUN/TAP interface. #This is important as it allows to VPN client phones to talk to each other. #You will need this for VPN phone to VPN phone calls client to client # Uncomment this directive if multiple clients # might connect with the same certificate/key # files or common names. This is recommended # only for testing purposes. For production use, # each client should have its own certificate/key # pair. # # IF YOU HAVE NOT GENERATED INDIVIDUAL # CERTIFICATE/KEY PAIRS FOR EACH CLIENT, # EACH HAVING ITS OWN UNIQUE "COMMON NAME", # UNCOMMENT THIS LINE OUT. #duplicate cn # The keepalive directive causes ping like # messages to be sent back and forth over # the link so that each side knows when # the other side has gone down. # Ping every 10 seconds, assume that remote # peer is down if no ping received during # a 120 second time period. #Turn on keep alive so if one side goes down the tunnel will attempt to reconnect or drop keepalive 10 120 # For extra security beyond that provided # by SSL/TLS, create an "HMAC firewall" # to help block DoS attacks and UDP port flooding. # # Generate with: # openvpn genkey secret ta.key # # The server and each client must have # a copy of this key. # The second parameter should be '0' # on the server and '1' on the clients. ;tls auth ta.key 0 # This file is secret # Select a cryptographic cipher. # This config item must be copied to # the client config file as well. ;cipher BF CBC # Blowfish (default) ;cipher AES 128 CBC # AES ;cipher DES EDE3 CBC # Triple DES # Enable compression on the VPN link. # If you enable it here, you must also # enable it in the client config file. comp lzo # The maximum number of concurrently connected # clients we want to allow. ;max clients 100 # It's a good idea to reduce the OpenVPN # daemon's privileges after initialization. # # You can uncomment this out on
# non Windows systems. ;user nobody ;group nobody # The persist options will try to avoid # accessing certain resources on restart # that may no longer be accessible because # of the privilege downgrade. persist key persist tun # Output a short status file showing # current connections, truncated # and rewritten every minute. status openvpn status.log # By default, log messages will go to the syslog (or # on Windows, if running as a service, they will go to # the "\Program Files\OpenVPN\log" directory). # Use log or log append to override this default. # "log" will truncate the log file on OpenVPN startup, # while "log append" will append to it. Use one # or the other (but not both). ;log openvpn.log ;log append openvpn.log # Set the appropriate level of log # file verbosity. # # 0 is silent, except for fatal errors # 4 is reasonable for general usage # 5 and 6 can help to debug connection problems # 9 is extremely verbose verb 3 # Silence repeating messages. At most 20 # sequential messages of the same message # category will be output to the log. ;mute 20 2. Now, lets set OpenVPN server to start and run as a service automatically. So, Go to Start- >Control Panel->Administrative Tools->Services. Find OpenVPN. Right Click and select properties.
3. Set the startup type to automatic. 4. Then click the start button to start the server now. The server will now start automatically as a system service. It will start 1 OpenVPN instance for each file it finds in the config directory. But you should only need the 1. At this point your OpenVPN server should be running and listening for connections. 5. Edit the default Client Configuration file located at C:\Program Files\OpenVPN\sampleconfig\client.ovpn to match the one I have posted below (edited appropriately for your scenario of course). The ; and # indicates items that are treated as remarks. Save this file as a new file called vpn.cnf in a folder on your desktop. The phone wants this file specifically called vpn.cnf # Specify that we are a client and that we # will be pulling certain config file directives # from the server. client # Use the same setting as you are using on # the server. # On most systems, the VPN will not function # unless you partially or fully disable # the firewall for the TUN/TAP interface. #Make sure to specify dev tap dev tap ;dev tun
# Windows needs the TAP Win32 adapter name # from the Network Connections panel # if you have more than one. On XP SP2, # you may need to disable the firewall # for the TAP adapter. ;dev node MyTap # Are we connecting to a TCP or # UDP server? Use the same setting as # on the server. #We are using UDP. Just match what you made the server either UDP or TCP. ;proto tcp proto udp # The hostname/ip and port of the server. # You can have multiple remote entries # to load balance between the servers. #Put in the EXTERNAL IP of your OpenVPN server and the port you defined in the server config file. remote xx.xx.xx.xx 1194 ;remote my server 2 1194 # Choose a random host from the remote # list for load balancing. Otherwise # try hosts in the order specified. ;remote random # Keep trying indefinitely to resolve the # host name of the OpenVPN server. Very useful # on machines which are not permanently connected # to the internet such as laptops. resolv retry infinite # Most clients don't need to bind to # a specific local port number. nobind # Downgrade privileges after initialization (non Windows only) ;user nobody ;group nobody # Try to preserve some state across restarts. persist key persist tun # If you are connecting through an # HTTP proxy to reach the actual OpenVPN # server, put the proxy server/ip and # port number here. See the man page # if your proxy server requires # authentication. ;http proxy retry # retry on connection failures ;http proxy [proxy server] [proxy port #] # Wireless networks often produce a lot # of duplicate packets. Set this flag # to silence duplicate packet warnings. ;mute replay warnings # SSL/TLS parms. # See the server config file for more # description. It's best to use # a separate.crt/.key file pair # for each client. A single ca # file can be used for all clients. #Specify your key file locations exactly like this. These are the directories that the SNOM 370 will use. #Just make sure to specify the correct client name (I used client3) that you used for making the client cert.
ca /openvpn/ca.crt cert /openvpn/client3.crt key /openvpn/client3.key # Verify server certificate by checking # that the certicate has the nscerttype # field set to "server". This is an # important precaution to protect against # a potential attack discussed here: # http://openvpn.net/howto.html#mitm # # To use this feature, you will need to generate # your server certificates with the nscerttype # field set to "server". The build key server # script in the easy rsa folder will do this. ns cert type server # If a tls auth key is used on the server # then every client must also have the key. ;tls auth ta.key 1 # Select a cryptographic cipher. # If the cipher option is used on the server # then you must also specify it here. ;cipher x # Enable compression on the VPN link. # Don't enable this unless it is also # enabled in the server config file. comp lzo # Set log file verbosity. verb 3 # Silence repeating messages ;mute 20 # The keepalive directive causes ping like # messages to be sent back and forth over # the link so that each side knows when # the other side has gone down. # Ping every 10 seconds, assume that remote # peer is down if no ping received during # a 120 second time period. #Turn on your keep alive like the server keepalive 10 120 Step 2: Generating a PC Client config and Testing Connections to the Server At this step we think we have everything working. So, this is a good time to do some testing. What we are going to do here is modify our vpn.cnf config file into client.ovpn (similar to the one we modified to create it in the first place) and use it to make a connection from a PC to our OpenVPN server. 1. Install OpenVPN on your laptop just as you did in Phase 1. BUT STOP AT THE END OF STEP 1. You do not need to create the bridged adapter on the client side and you aren t making a PKI infrastructure. You are just connecting to the server. 2. Copy the following files from your server to the corresponding location on the laptop. As you can see I am setting up my laptop as client2 a. C:\program files\openvpn\easy-rsa\keys\client2.crt copy to laptop b. C:\program files\openvpn\easy-rsa\keys\client2.key copy to laptop c. C:\program files\openvpn\easy-rsa\keys\ca.crt copy to laptop
3. Modify vpn.cnf by editing the paths to the locations of the certs and keys. a. C:\\program files\\openvpn\\easy-rsa\\keys\\client2.crt b. C:\\program files\\openvpn\\easy-rsa\\keys\\client2.key c. C:\\program files\\openvpn\\easy-rsa\\keys\\ca.crt So, to clarify, the major change is in this section of our vpn.cnf file. Is Now. # SSL/TLS parms. # See the server config file for more # description. It's best to use # a separate.crt/.key file pair # for each client. A single ca # file can be used for all clients. #Specify your key file locations exactly like this. These are the directories that the SNOM 370 will use. #Just make sure to specify the correct client name (I used client3) that you used for making the client cert. ca /openvpn/ca.crt cert /openvpn/client3.crt key /openvpn/client3.key # SSL/TLS parms. # See the server config file for more # description. It's best to use # a separate.crt/.key file pair # for each client. A single ca # file can be used for all clients. #Specify your key file locations exactly like this. These are the directories that the SNOM 370 will use. #Just make sure to specify the correct client name (I used client3) that you used for making the client cert. ca C:\\program files\\openvpn\\easy rsa\\keys\\ca.crt cert C:\\program files\\openvpn\\easy rsa\\keys\\client2.crt key C:\\program files\\openvpn\\easy rsa\\keys\\client2.key 4. Now save this as a NEW FILE. Save it as C:\Program Files\OpenVPN\config\client.ovpn 5. Now. Don t forget to make sure you have the appropriate incoming firewall rule. The only rule I need is UDP 1194 inbound to my OpenVPN/3CX server. 6. Take your laptop offsite somewhere with an Internet connection. 7. Make sure you have Internet access. On your desktop you should have an icon called OpenVPN GUI (assuming you installed the Release Candidate software). 8. Double Click this icon and it will put a little icon in your system tray
9. Right Click the icon and select connect and it will process the file you placed in the config directory. 10. The OpenVPN Client should now process your connect script and it should connect you to the OpenVPN server. Once it connects, you can click Hide to hide the connection window. Since we are using bridged Ethernet, you should now be able to ping anything on the same subnet as the OpenVPN/3CX server. If this part worked successfully you can be confident that your phones vpn.cnf file should be fine. If this didn t work we need to do some troubleshooting and get this working first. Step 3: Creating Tarball for Upload to SNOM 370 1. Now we need to create a tarball file (like a zip file) that has all the phones certificates and config bundled together. To do this we will use a program called J-Zip. Go to http://www.jzip.com and download and install Jzip (I ll assume no explanation is needed for that). 2. Now, earlier you created a directory on your desktop that contained the vpn.cnf file for the phone. Now, you also need to copy the phones certificate, private key and the Certifcate Authority s certificate to the same directory. These files are located as follows: a. C:\Program Files\OpenVPN\easy-rsa\ca.crt b. C:\Program Files\OpenVPN\easy-rsa\client3.crt (or whatever you named the cert) c. C:\Program Files\OpenVPN\easy-rsa\client3.key You should copy these three additional files into the same directory as vpn.cnf so we have all 4 files together.
3. Now, open Jzip. Create a new Archive and call it vpnclient.tar (set type to.tar in the drop down menu) 4. Once you click OK you will be prompted to add files to your archive. Now we need to select the 4 files we put into our folder. 5. Go ahead and close out of Jzip (there is no save it creates the archive while you are working). Set aside the vpnclient.tar file as it will be needed later to upload to the phone.
Phase 3: Flashing the Firmware on the SNOM 370 to get OpenVPN Client Support 1. Download the SNOM VPN firmware here http://provisioning.snom.com/download/fw/snom370-7.3.7-vpn-sip-f.bin. 2. Rather than using tftp like most phones, the SNOM wants to use an http server to up[date its firmware. So, I just used the 3CX php implementation to accomplish this. I placed this firmware file inside the following directory C:\Program Files\3CX PhoneSystem\Data\Http\myphone where I now it is reachable. 3. Now, we need to log on to the SNOM 370 and tell it to update its firmware. Go to http://xx.xx.xx.xx where xx.xx.xx.xx is the IP of the SNOM 370 phone 4. Log into the phone with your administrative credentials. 5. From the left hand navigation menu click on Settings - > Software Update
6. Now enter the URL where the firmware is accessible. In my case.http://192.168.1.25:5481/myphone/snom370-7.3.7-vpn-sip-f.bin Remember the 3CX apache install listens on 5481 by default so we need to specify that if that s the port it s listening on. 7. Now click Load. When you do this the phone will automatically reboot. When the phone reboots it will ask you if you want to load a new software. You will need to hit the OK button on the phone for it to proceed with the update. You will see the phone get the firmware and erase its flash and update with the new version. 8. When the update is done the phone should just boot normally into whatever config you have loaded on it. Phase 4: Enabling VPN on the SNOM 370 and Uploading tarball Step 1: Enabling VPN on the SNOM 370 1. Go ahead and log back into the web interface on the phone as you did previously. On the left hand menu click Advanced and then click the tab on the top that says QoS/Security. 2. In the Security subsection on this page turn the VPN option on. 3. You will now see a field where you can specify the location of your vpn config tarball. Let s use the same trick as before. Go and get the vpnclient.tar archive you created earlier and place it in the same directory on the 3CX server just as we did with the firmware file earlier. My URL for example is http://192.168.1.25:5481/myphone/vpnclient.tar Now enter the URL into the text field as follows.
4. Now click the save button and the click the reboot button on the top of the screen.then click the yes button when it asks if you are really sure 5. When the phone reboots you should see a message on the phone that says Fetching VPN Tarball config. Note: I ve noticed sometimes the first attempts fails and then if you wait a second it grabs it the second time. 6. OK, last step. We need to have a valid NTP server so that the phones time is in sync with the server. This needs to be a publicly accessible server, in other words, the phone needs this before the VPN is active. So, log back into the phones web interface, and click on advanced and put a time server in the NTP fields. This is actually important otherwise the certificates might get rejected.