Apple recently released Mac OS X 10.11.4, the latest update for OS X El Capitan. I’m generally an early adopter. If I’m not running a beta release (which I must admit, I’m not doing nearly as much of anymore), I am certainly the first in line to update OS X or iOS to the latest release as soon as it’s reached GA status.
If you’re like me, the latest OS X update, 10.11.4, broke some VPN profiles, specifically certain Cisco IPsec profiles. When I first discovered the VPN client wouldn’t connect to a Cisco IPsec profile that was working just fine before the update, I first thought it may be a problem on the remote end, or even perhaps with my ISP. I tried a secondary VPN profile that’s L2TP over IPsec and had no issues. I then tried a third profile using Cisco IPsec, with no luck. After successfully connecting to a fourth VPN profile (also L2TP over IPsec), I was beginning to think the issue had nothing at all to do with the original VPN endpoint I was attempting to connect to or my ISP. A quick test of the same VPN profiles on a second Mac that had been updated to 10.11.4 yielded the same results, even when connected to a second ISP, confirming my theory.
What next? Google to the rescue, of course!
A quick search for “OSX 10.11.4 IPsec” yielded a thread in Apple’s Support Communities that was opened just yesterday with multiple users having similar issues. Yes, I was on to something – my Google Foo was strong!
After reading through a handful of “me too’s”, I found a reply that suggested increasing the DH Group to 14 on the VPN appliance would fix the issue. Of course I was remote – the reason I was trying to connect to VPN in the first place, so I couldn’t test this theory until later when I actually made it onsite. I can confirm that in my case, changing the DH Group to 14 solved my problem. It appears that starting with OS X 10.11.4, Apple requires a minimum of a 2048 bit modulus (DH Group 14) to connect to IPSec VPNs. These two “broken” VPN profiles were using 1024 bit modulus.
How to modify an existing IPsec Tunnel on a FortiGate firewall using FortiOS 5.4
If you have an IPSec VPN Tunnel configured on a FortiGate firewall, and you used the default “Dialup – Cisco IPsec Client” template, it’s likely that your DH Group is set to 2. I couldn’t find a way to modify the DH Group for an existing IPSec tunnel in the FortiOS 5.4 GUI, but here are the CLI commands to make the change:
FW01 # config vpn ipsec phase1-interface
FW01 (phase1-interface) # edit YOUR_VPN_TUNNEL
FW01 (YOUR_VPN_TUNNEL) # set dhgrp 14
FW01 (YOUR_VPN_TUNNEL) # end
That’s it! One thing I love about the FortiOS CLI is that it’s incredibly powerful, yet very easy to navigate – much easier to navigate than Cisco IOS in my opinion. I was able to apply this to a handful of FortiGate firewalls that I manage for SquarePlanIT customers who were using Cisco IPsec VPN tunnels and weren’t already using a 2048 bit modulus. Speaking of managed firewalls – if you’re looking for a managed IT solutions provider, or even just have some project work to knock out, get in touch! I’d love to tell you about all that we have to offer.
Learn more about Diffie-Hellman groups
To learn more about the Diffie-Hellman key exchange, here’s an excellent Wikipedia article. For a brief overview of the different DH Groups that can be configured, check out here’s a Cisco Support Community article.
I decided to make the move to MySQL over SSL when I moved to dedicated MySQL database servers rather than all-in-one web/database servers for the production websites and databases that I host with Digital Ocean. I wanted an extra layer of security since MySQL traffic would no longer be contained within localhost.
Long story short, none of the tutorials I could find on this seemingly simple topic appeared to work. I mentioned the idea to my friend Josh Haber who also thought it was a good idea to strengthen security between web and database servers, but he too initially had problems getting everything to work. After a lot of digging through obscure posts online, he found that part of our problem was AppArmor, Ubuntu’s Mandatory Access Control system. To paraphrase Ubuntu’s wiki article, AppArmor’s purpose is “to confine programs to a limited set of resources”. You see, most tutorials suggested to store certificates in /etc/mysql/, however we were trying to store them in /etc/mysql/ssl/, a much cleaner solution in my opinion.
Without further delay, here are step-by-step instructions for configuring MySQL to use SSL on Ubuntu 14.04 LTS:
mkdir /etc/mysql/ssl && cd /etc/mysql/ssl
Generate a CA key and certificate with SHA1 digest
openssl genrsa 2048 > ca-key.pem
openssl req -sha1 -new -x509 -nodes -days 3650 -key ca-key.pem > ca-cert.pem
Create server key and certificate with SHA1 digest, sign it and convert
openssl req -sha1 -newkey rsa:2048 -days 3650 -nodes -keyout server-key.pem > server-req.pem
openssl x509 -sha1 -req -in server-req.pem -days 3650 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem
openssl rsa -in server-key.pem -out server-key.pem
Create client key and certificate with SHA1 digest, sign it and convert
openssl req -sha1 -newkey rsa:2048 -days 3650 -nodes -keyout client-key.pem > client-req.pem
openssl x509 -sha1 -req -in client-req.pem -days 3650 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
openssl rsa -in client-key.pem -out client-key.pem
chown mysql:mysql /etc/mysql/ssl/* && chmod ug=wrx /etc/mysql/ssl/*
Add the following lines under the [client] section
ssl-ca=/etc/mysql/ssl/ca-cert.pem ssl-cert=/etc/mysql/ssl/client-cert.pem ssl-key=/etc/mysql/ssl/client-key.pem
Add the following lines under the [mysqld] section
ssl-ca=/etc/mysql/ssl/ca-cert.pem ssl-cert=/etc/mysql/ssl/server-cert.pem ssl-key=/etc/mysql/ssl/server-key.pem
Change /etc/mysql/*.pem r to /etc/mysql/ssl/*.pem r
service mysql restart
Once you’ve completed these steps, you should be able to run show variables like “%ssl%”; from your MySQL instance and get the following:
mysql> show variables like "%ssl%"; +---------------+--------------------------------+ | Variable_name | Value | +---------------+--------------------------------+ | have_openssl | YES | | have_ssl | YES | | ssl_ca | /etc/mysql/ssl/ca-cert.pem | | ssl_capath | | | ssl_cert | /etc/mysql/ssl/server-cert.pem | | ssl_cipher | | | ssl_key | /etc/mysql/ssl/server-key.pem | +---------------+--------------------------------+
You can then configure your database users to require SSL.
If you’re configuring MySQL over SSL for WordPress, all you’ll need to do is add the following line in your wp-config.php file:
As I mentioned above, I’ve recently moved all production servers to Digital Ocean. Use this link to signup and get a $10 credit.
I’ve always been a fan of self-hosted solutions. It’s a bit ironic, since I’m working on ArrivalApp, a fully hosted SAAS app for tracking event attendance, but that’s another story. Until recently, I’ve never really considered the concept of “owning” my own data. Sure, I’ve always preferred a self-hosted product over a hosted product, but I attribute that to being a tinkerer.
I’m a web & software developer. I used to claim to be more of a designer, but over time I’ve realized that I truly prefer to work on features and functionality more than the design itself. I like making things work. I like building entire products from the ground up, which is what I’m doing with ArrivalApp. I’m a dreamer, a thinker, and a creator. I know and appreciate good design and usability when I see it. Still, I’ve acknowledged that when it comes down to what I have a passion for, development comes first, so that’s what I devote my time to.