Posts Tagged ‘VPN’

IPsec between Meraki and OpenBSD

Tuesday, August 6th, 2013

I recently acquired some (Cisco) Meraki networking kit including an MX60 security appliance (read: router, firewall, NAT, etc.).

Once it’s set up and running, I was browsing the dashboard and the site-to-site VPN configuration options. Normally with multiple Meraki devices in use, a fully-meshed VPN can be created automatically with very little configuration.

I also noticed the ability to add non-Meraki VPN peers so I added details for my OpenBSD-based gateway. You can see from the screenshot the details are basic:

meraki dashboard

On the OpenBSD side, I started with a basic configuration in /etc/ipsec.conf:

ike esp from 192.0.2.0/24 to 192.168.128.0/24 \
        peer example-xyzzy.dynamic-m.com \
        psk mekmitasdigoat

The Meraki dashboard allows you to register a dynamic DNS record for the MX60 which will be in the .dynamic-m.com domain so you can use this to refer to the remote peer in the configuration, (especially if you have a dynamic IP address).

This configuration didn’t work, but using isakmpd(8)‘s handy -L option to write to /var/run/isakmpd.pcap all of the unencrypted IKE traffic it then becomes apparent the OpenBSD and the Meraki disagree on the phase 1 negotiation; mainly that the Meraki end wants to use Triple DES and OpenBSD prefers AES by default. As there’s no way to tweak the cryptography options on the Meraki side, we change the OpenBED side like so:

ike esp from 192.0.2.0/24 to 192.168.128.0/24 \
        peer example-xyzzy.dynamic-m.com \
        main auth hmac-sha1 enc 3des group modp1024 lifetime 28800 \
        quick auth hmac-sha1 enc aes-256 group none lifetime 28800 \
        psk mekmitasdigoat

The main option sets the phase 1 parameters and the quick option sets the phase 2 parameters that match the highest settings out of the handful proposed by the Meraki side.

With that done, all that remains is to ensure isakmpd(8) starts at boot and the rules in /etc/ipsec.conf are automatically loaded by adding the following to /etc/rc.conf.local:

isakmpd_flags=-K
ipsec=YES

Nokia Series 60 and a Cisco VPN

Friday, October 15th, 2010

One redeeming feature of Series 60 Nokia phones is there’s a reasonable IPsec VPN client available. It might be pre-installed on your phone already or you can check if your phone is compatible and download it here.

It can however be a bit of a pig to configure as you do very little of it on the phone and instead you have to supply a VPN policy file with all of the various settings contained within. Nokia ship a tool that allows you to create these, however it’s only available for Windows, so if you’re on a Mac or a Linux machine you’re out of luck. However, when you realise that a VPN policy file is just a renamed ZIP archive there’s no need to give up.

Nokia have documentation available specifically the VPN Client Policy Specification that explains what the various files in the ZIP archive are for. Unless you authenticate via certificates, chances are you only need the minimum two required files in the archive.

The first of these is a .pin file. It’s a really simple file that just supplies the policy details and is formatted like so:

1
2
3
4
5
6
7
8
9
10
[POLICYNAME]
Company VPN
[POLICYVERSION]
1.0
[POLICYDESCRIPTION]
Secure access to internal systems
[ISSUERNAME]
My Company
[CONTACTINFO]
vpn@domain.com

For the most part, you only really need to specify the policy name and version, the other fields can be empty as they aren’t generally visible.

The other required file is the .pol file. This one is a lot more complicated as it specifies all of the various IKE and IPsec parameters. A sample one looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
SECURITY_FILE_VERSION: 1
[INFO]
Company VPN
[POLICY]
sa CISCO_ASA_PSK = {
esp
encrypt_alg 3
auth_alg 2
identity_remote 0.0.0.0/0
src_specific
hard_lifetime_bytes 0
hard_lifetime_addtime 3600
hard_lifetime_usetime 3600
soft_lifetime_bytes 0
soft_lifetime_addtime 3600
soft_lifetime_usetime 3600
replay_win_len 0
}
 
remote 0.0.0.0 0.0.0.0 = { CISCO_ASA_PSK(vpn.domain.com) }
inbound = { } 
outbound = { }
 
[IKE]
ADDR: vpn.domain.com 255.255.255.255
IKE_VERSION: 1
MODE: Aggressive
REPLAY_STATUS: FALSE
USE_MODE_CFG: TRUE
IPSEC_EXPIRE: TRUE
USE_XAUTH: TRUE
USE_COMMIT: FALSE
ESP_UDP_PORT: 0
SEND_NOTIFICATION: TRUE
INITIAL_CONTACT: TRUE
USE_INTERNAL_ADDR: FALSE
DPD_HEARTBEAT: 90
NAT_KEEPALIVE: 60
REKEYING_THRESHOLD: 90
ID_TYPE: 11
FQDN: group
PRESHARED_KEYS:
FORMAT: STRING_FORMAT
KEY: 8 password
USE_NAT_PROBE: FALSE
PROPOSALS: 1
ENC_ALG: 3DES-CBC
AUTH_METHOD: PRE-SHARED
HASH_ALG: MD5
GROUP_DESCRIPTION: MODP_1024
GROUP_TYPE: DEFAULT
LIFETIME_KBYTES: 0
LIFETIME_SECONDS: 86400
PRF: NONE

When creating this file it’s handy to know what the other side is expecting otherwise a lot of trial and error is involved.

The above file works for me to connect to a Cisco ASA firewall, some key points:

  • Lines 7 & 8 specify the IPsec crypto algorithms, in this case 3DES-MD5. To use for example AES-SHA1 instead you would change the values on those lines to 12 and 3 respectively.
  • Line 20 specifies the address of your VPN server, this can be either a fully-qualified domain name or an IP address.
  • Line 25 repeats the address of your VPN server, except this time you also need to specify the netmask, which in most cases is 255.255.255.255.
  • Line 31 enables XAUTH which is required in common Cisco setups where you authenticate with your own personal username and password which is quite often linked to Active Directory, etc.
  • Lines 40 & 41 specify the first authentication step which in my setup is a shared group and password, so ID type 11 is used to specify that FQDN is just bytes rather than an IP address or fully-qualified domain, etc. then the group name itself is specified on the following line.
  • Line 44 specifies the password, note that you first specify the length of the password followed by the actual password string itself.
  • Lines 47 & 49 specify the IKE crypto algorithms. In contrast to the IPsec values these are actually spelled out instead of using cryptic values.

It’s important that both of these files are saved in DOS format with the correct newlines. You can use for example unix2dos(1) to convert them:

# unix2dos policy.p*

Then all that is left is to create the zip archive:

# zip policy.vpn policy.p*

It’s important that all three files share a common basename, in this example we used “policy” but it can be anything.

Now you need to upload the .vpn file to the phone. This can be done in any number of ways, such as USB or Bluetooth. You then need to run the file on the phone which forces it to be installed as a VPN policy.

Once that’s done you need to create a VPN access point which is accessed on my Nokia E71 under Tools > Settings > Connection > VPN > VPN access points. There you create a new access point, you need to give it a name, pick the policy that you just installed and an existing access point for it to piggyback on top of such as your 3G/GPRS connection or WiFi.

With the VPN access point defined you now use it like a regular access point. One thing I haven’t managed to get working yet is split tunnelling so that while I’m using the VPN I can access regular websites, instead I have to reconnect with a non-VPN access point but this is a minor niggle.

Back to My Mac and an OpenBSD firewall

Friday, August 27th, 2010

As I recently wrote, I’ve been playing with the Back to My Mac feature of MobileMe on my Macs. Put simply it’s a VPN for your Macs, you can access one remotely from another as if they were on the same LAN either at home or work.

Assuming you’ve entered all of your MobileMe account details, it should just be a case of going to the Back to My Mac tab in the MobileMe preferences and starting it up on each Mac you own.

However, with the first Mac I tried this on I hit this problem:

Back to My Mac Warning Screenshot

The router that OS X is complaining about in this case is a Soekris net4501 running OpenBSD, (well to be pedantic, there’s actually two of them in a failover configuration). OpenBSD doesn’t support NAT-PMP or UPnP out of the box, so I had a look for some additional software I could run that might support either protocol.

I came across MiniUPnPd which claimed to support both protocols and run on OpenBSD so I grabbed the source and compiled it up to try it. At the time I was still running OpenBSD 4.6 but was planning to do the upgrade to 4.7 soon, I noted that there was reports of MiniUPnPd not working properly on 4.7.

After configuring it and starting it up, it didn’t seem to work properly. After eliminating any obvious reasons, the Macs still didn’t think that the router supported either NAT-PMP or UPnP, and my Sony Playstation 3 which supports UPnP only, claimed UPnP was unavailable when I ran a network diagnostic but this seems to be a known issue with the Playstation 3. So MiniUPnPd wasn’t looking too useful to me.

Out of curiosity I investigated how complicated the NAT-PMP and UPnP protocols are as the specifications for both should be publicly available. The first one I looked at was UPnP as at the time this seemed the more well known of the two. UPnP appears be a fairly bewildering set of standards, even though it seemed the bit I only need to care about is the Internet Gateway Device (IGD) protocol. It also depends heavily on XML which I loath the more I have to deal with it.

NAT-PMP on the other hand seemed a far simpler protocol, the IETF draft was straightforward by comparison and as it was authored by Apple themselves, it should be the better supported of the two, at least on my Apple hardware. After a day or two of coding, I have a fully standalone NAT-PMP daemon – natpmpd, which I’m making available under the BSD licence.

The dedicated page documents the gory details on how to get it set up, but suffice to say once installed and running, I now get the following on each Mac:

Back to My Mac Working Screenshot

To test, I simply disconnected my MacBook Pro from my home network and instead connected through my mobile phone via 3G. The remaining Macs on the home network are still visible in the Finder and Screen and File sharing remain accessible. On my OpenBSD router using tcpdump(8) I can see the encrypted VPN traffic flowing between the remote and local Macs.

Snow Leopard and (uninstalling) Cisco VPN

Saturday, August 14th, 2010

I mentioned reinstalling Shimo when I upgraded to Snow Leopard and that works really nicely for controlling my Cisco VPN connection but for that to work, you still need to install the official Cisco VPN client.

I also use VMware Fusion and find both this and the Cisco VPN client have a propensity to step on each others toes in the networking department, my hunch is it’s most likely because both create and monitor virtual network interfaces. The usual symptoms are that my virtual machines lose network connectivity or cannot access the VPN, or that I can’t bring the VPN connection up in the first place. Sometimes I can restore order to the VPN by restarting it with the following in the Terminal:

$ sudo /System/Library/StartupItems/CiscoVPN/CiscoVPN restart

Anyway, while I was tethering my Mac to my mobile phone I was fiddling with the Network preferences and noticed Snow Leopard gained native support for CIsco VPN connections:

Cisco VPN Interface Screenshot

This was probably in the release notes which I didn’t read, (well-known male trait), but anyway adding this new interface and configuring it with the right settings got it working first, second, third time once I remembered the correct password. It even feels quicker.

That left me with little need for Shimo or the Cisco VPN client. Uninstalling Shimo was easy, I removed it from my Login Items under Accounts preferences and then dragged it from the Applications folder to the trash.

Uninstalling the Cisco VPN client was harder as that came from an .mpkg file but then I remembered something about these leaving package receipts somewhere. Sure enough, under /Library/Receipts was a handful of vpnclient-*.pkg files. A bit of a google suggested each contains a .bom file that you can inspect with lsbom(8), I found the following worked in the Terminal:

$ lsbom /Library/Receipts/vpnclient-api.pkg/Contents/Resources/vpnclient-api.bom
.	40755	502/0
./Library	40755	502/0
./Library/Frameworks	40755	502/0
./Library/Frameworks/cisco-vpnclient.framework	40755	502/0
./Library/Frameworks/cisco-vpnclient.framework/Headers	40755	502/0
./Library/Frameworks/cisco-vpnclient.framework/Headers/vpnapi.h	100644	502/0	20265	1156317900
...

Delete any Cisco-specific files, (obviously don’t delete things like /Library/Frameworks) and then reboot to make sure there’s no stale daemons running or kernel extensions loaded.

Using the built-in VPN support doesn’t seem to cause any conflicts with VMware, I started the VPN while it was running and the virtual machines then had access to hosts on the remote network with no obvious problems. JFW, as they say.