Bitcoin Experiment

After reading an excellent article about Bitcoin in the London Review of Books, I have become interested in cryptocurrencies.  In order to learn more I decided I needed to get some practical experience, so I bought some Bitcoin.  Here are my experiences and observations, which I hope will save you some time and energy if you are looking to buy a small amount of Bitcoin from the UK.


If you want to get your feet wet with Bitcoin from the UK, use Circle to buy up to £200 a week worth of Bitcoin.

Registration woes

Buying Bitcoin proved to be quite complicated, partially due to banking requirements known as AML/KYC (Anti Money Laundering/Know Your Customer) which means setting up an account with a bitcoin exchange can be quite arduous.  They all require proving your identity, and different exchanges take this to different levels. This can mean you will have to wait up to a week before you can buy any bitcoin.  Even more frustrating is other costs and delays aren’t always apparent until after you have completed the registration process.  You can waste an awful lot of time going through a registration process only to find the exchange isn’t worth using in your circumstances.

Transfer fee woes

When buying a small amount of Bitcoin, you don’t want to lose much in fees when you buy them.  This can occur in a couple of places.  The exchanges may charge transaction fees – usually a small percentage of the transaction value.  In many cases this may not be a problem, since those Exchanges may offer a better exchange rate – depending on your volume this difference may more than make up for a fee.  Do your maths!

A bigger obstacle is that a number of exchanges no longer operate UK based bank accounts and don’t accept debit cards in GBP.  This means using international bank transfers.  Even within Europe this is going to mean your bank charges you for SWIFT or SEPA transfers – Nationwide charge £20 for this.  So buying £100 of Bitcoin this way is going to cost you £120.

If you are buying a small amount of bitcoin avoid exhanges that don’t accept credit cards.

Bitcoin exchange rates

The website gives relatively up to date rates for most exchanges and marketplaces, as well as other information including which places accept UK bank transfers or credit cards.


The following table summarises my experience with different exchanges.

Exchange Registration difficulty Transfer fees Transaction fees
Kraken Straightforward – upload scan of ID and proof of address  SEPA or SWIFT transfer only  Yes
ANX Lengthy.  Registration isn’t too bad, but they send a code by mail to confirm address which means up to a week before you can buy. SEPA or SWIFT transfer only, and conversion to CAD or HKD  Yes
Uphold  Relatively straightforward – accept upload of scans or photos of ID documents. SEPA or SWIFT transfer, or credit/debit card with 2.75% fee
Solidi Currently in Beta, so you have to get accepted into the Beta before you can register.  On acceptance simple upload of scanned ID and address docs gets you verified.  No fee  No fee
Circle Very simple upload of scans/photos of ID docs gets you verified in a single session.  UK credit/debit card accepted with no fee  No fee
Coinbase Horrible – they use a video system based in Germany where you video chat with someone who may not speak English who tries to take a clear photo of your passport via a webcam – this failed every time for me, till I gave up.  Their Android app can be used to take a photo of your drivers license, which is better, but you need to disable any screen dimming apps like Twilight for the app to work. However, after going through this it turned out they don’t allow bitcoin purchase from the UK – frustrating!  3% fee for credit or debit card, but unclear if you can use UK debit or credit cards.  Their app says you can’t.

I ended up using Circle for buying my bitcoin.  The registration process was simple and quick, they accept account top-up via UK debit card with no fees from them or my bank up to a limit of £200 per week.

I’m sure there are reasons to use any of the other exchanges listed above – but for experimenting with small amounts of Bitcoin Circle is the one I would recommend.  At some point I may do the maths and figure out what is the most cost effective way to buy Bitcoin for different spending levels.

Ditching Static IP for DHCP assigned addresses

We took the decisions to make all devices in our country offices other than the internet gateway automatically get their IP settings via DHCP, including servers, printers and wireless access points.  This goes against the grain for a lot of people, where static IP addresses are the rule for anything other than client PCs, but I think we managed to get a few benefits from doing this, which I shall outline in this post.

What was the main driver for going for this change?  Deploying printers – we’d often find that local contractors would just assign a local IP address to new printers that they connected to the network, sometimes conflicting with other devices on our network, and often failing to leave any record of the address they had used, meaning we could deploy equipment with addresses that conflicted.  Those basic problems created more work than we wanted to be spending troubleshooting such things, so I wanted to find a way to bring it under control.

The key – a feature rich DHCP server

What really enabled this for us was updating our core network infrastructure in all offices with Meraki Security appliances. These had more DHCP features than the previous Cisco ASA 5505.  The main thing that was missing from DHCP on the ASA 5505 was being able to assign fixed IP addresses by MAC address.

This has made it easy to take control of IP address assignment in our remote offices.

Designing the subnet

Some people don’t really care about which IP addresses are used for what, but since we occasionally want to share printers with other organisations, but don’t want their devices accessing everything on our subnet (or VPN) having a well thought out subnet helps write access rules.  If you put all your printers in a part of your subnet that can be defined by CIDR notation, then you can write a routing rule that allows access to and from this portion of your subnet very easily.

All our country office subnets are /24.  We subdivide those into a bunch of smaller /27 groups that can be addresses using CIDR. These aren’t strictly speaking subnets – you can use the first and last address – but they can be used in routing tables the same way.

  • – Unused (a buffer for future use) – addresses – (the first address in this case isn’t usable since it is the start of the subnet)
  • – Servers – addresses –
  • – Printers – addresses – 223
  • – Network devices – addresses – (the last address can’t be used as it is the broadcast address for the subnet.

So by assigning printers with addresses between and 223 it is possible to write an access rule allowing traffic only to and from printers to devices in a connected subnet using

Enforcing the subnet organisations

By creating reserved ranges in the DHCP page, it is possible to both record the organistation of your subnet, and ensure that the DHCP server doesn’t allocate any PC clients an address in the ranges you’ve specified:

Meraki DHCP Reserved Range

Anything addresses haven’t specified ( – here) is available for allocation to any client added to the network.

Collecting the MAC addresses

Some devices have the MAC address printed on a label on the device, which makes it easy to pre-assign the address.  That isn’t always the case.  However, if you can identify a newly connected device in the Meraki dashboard client list, you can get its MAC address – or even faster, assign it an address from the client page:

Meraki Address Assignment

Super easy.

Config is the documentation

Now if we want to find out what address was assigned, we can just look in the DHCP config page to get a list of Fixed IP assignments:

Meraki DHCP Fixed Assignments

That is always up to date, compared to the spreadsheets we maintained before (or didn’t – they were often out of date).

Assigning and Changing IP addresses

Most devices are shipped configured to get their IP settings via DHCP, so it is easy to deploy new devices in remote locations – local staff don’t need to do much more than plug the device into the network.

If we want to change an IP address (or assign the same IP address to replacement hardware) we can just connect the device to the network, change the DHCP settings, then power cycle the device to pick up the settings.  That is very easy to communicate to local staff than walking them through configuring IP settings on a printer.

Everything is configured to use DHCP (apart from the DHCP server itself of course) and life is a little bit simpler.

Bonus tip – Option 15

If you need to enable “naked” internal hostname resolution for clients, don’t forget to set DHCP option 15 to add your domain suffix – e.g. example.local.  If you have multiple internal domains that need to be resolved you can also use option 119 to list a comma delimited list for clients to search through.

Christian Aid Meraki Roll Out Complete

Managua Meraki Today our Regional ICT Service Manager for Latin America and Caribbean, Jose Carlos Valdivia completed the roll out of Christian Aid’s Meraki managed network to our country offices outside of Europe, by installing the final pieces of equipment in our office in Managua, Nicaragua.

Finally we are able to manage our networks in all overseas offices without as much need to travel, and effectively manage our bandwidth use across all offices.

My colleagues in the UK are also approaching their roll out to UK offices, with only a small number to go.

This means that Christian Aid will have a consistent network implementation across all its offices, including VPN, WiFi and traffic management.

We aren’t going to rest there however.  We have plans to implement 802.11x secured WiFi access to Christian Aid owned devices across all offices – we are hoping to achieve this with cloud based RADIUS servers.  We will also probably have to start looking at implementing different devices in some offices that have grown in size both in headcount and area covered, since the roll out began – replacing MX60W (which has limitations) with MX64 and MR access points.  I’ll write more on that in a future post.  We’ve other plans too, which I’ll share as we develop them.

I’ll leave you with our Overview map – something I am increasingly proud of!

Christian Aid International Meraki Network Oct 2015

Cloud managed VPN at Christian Aid using Meraki Security Appliances

When we decided to replace of our aging Cisco ASA firewalls, one thing we knew for sure was that we needed a VPN to give staff working in our remote offices access to the internal resources located at our HQ in London.

On the ASAs we used the Easy VPN feature to do this.  This is different from traditional IPSEC VPNs in that you don’t need to know the IP address for each node.  Since several ISPs we use for our global offices only give us dynamic IP addresses, this style of VPN isn’t possible.  Easy VPN gets around this by treating each ASA as a VPN client – the remote ASA 5505s initiate the VPN connection to a known hostname or IP address at the HQ.

This worked really well with the Cisco ASAs, so we wanted VPN that was as easy to roll out and maintain.  The Meraki security appliances proved to be even easier.

Basic Configuration

The interface for a site to site VPN is very simple with only three options to select for our purpose:


Meraki VPN Mode

Three settings:

  1. Disabled (i.e. no VPN)
  2. Split tunnel (only traffic to and from VPN connected networks goes over the VPN tunnel)
  3. Full tunnel (all internet traffic from the device is sent over the VPN tunnel.

At Christian Aid we use the Split tunnel option.  We know that the majority of traffic from each site is to and from the Internet (increasingly more so as we move our own resources to the cloud) and having that traffic first travel via HQ is not the very efficient, and will hammer our HQ internet connection.


Meraki VPN Topology

Even simpler – only two options.  The first option to Connect Cirectly creates a mesh VPN – each node connects to every other node.  Traditional IPSEC VPNs can do this but have to configure the fixed public IP address of each node on all the other nodes.  The Meraki cloud handles this automatically.  Easy VPN did not allow us this option at all, so we never had to face the challenge of keeping IP addresses updated across over 40 locations.

A benefit of a mesh VPN is if clients at remote sites need to communicate directly without passing through HQ.  This lends itself to distributed Active Directory networks – with a mesh VPN domain controllers at different locations can replicate with each other.  Previously replication had to come via our headquarters.  A mesh VPN promised better replication and redundancy – if our headquarters went down for any reason, or DCs could still replicate.

We also wondered whether peer to peer communication solutions such as Skype would work better, although we haven’t really answered that yet.

There is a hidden third option that appears if you select Connect directly to only one peer that allows a hybrid of the two – if you select hub and spoke mode you can select multiple hubs – a spoke can create VPN tunnels to multiple locations.

You can also configure different topology settings for each node.

This allows you a great level of flexibility.  In our case, sites that have a DC are set to connect directly to all VPN peers.  Sites without a DC are set to only connect to our HQ.  This results in the DC sites being meshed so they can replicate, but non-DC sites aren’t part of the mesh.

More of this later when I discuss Non-Meraki VPN Peers.

NAT Traversal

Meraki VPN NAT Traversal

This sets up port forwarding through the Meraki device (not through the ISP equipment which may be doing NAT – more on that later).  In our case Automatic has always worked fine.

Advanced configuration options

As mentioned above you can use the Topology option if you have more complex needs.  It is also possible to add non-Meraki VPN peers that can be joined to the mesh.  A future plan we are hoping to implement involves creating Domain Controllers on the Azure cloud, to make our Active Directory infrastructure site redundant.  The thinking is that we can then add these DCs as non-Meraki VPN peers, and they will then be linked to   As things currently stand, it looks like these may be one way only like Easy VPN clients.  At some point in the future we hope it is possible to create virtual Meraki VPN peers on the Azure cloud that can be configured to work exactly the same as a hardware MX device.  That would allow us to use Azure hosted servers to provide cloud based authentication, Active Directory, print driver deployment, RADIUS – my colleagues and I see a lot of potential in this. I guess I should make a wish

Outcome and monitoring

With three basic settings in place across our MX devices, we had a working VPN network up and running so quickly we actually spent some time looking for additional settings before we realised we’d completed the job!  Meraki MX devices easily met or exceeded our requirements in this area.

Here is a map of our 45 sites connected by VPN at the time of writing this article.

Christian Aid Meraki Network Sept 2015

Note that sites physically close together (at this scale) are grouped.

Custom Pie Charts in Meraki

Custom Pie charts is a feature in Meraki that helps you to answer some of the most common questions that are often asked about how internet connections are used – the most common of all being “how much of our bandwidth is being used for non work activities?”

After you have defined what constitutes work traffic, you get a pie chart that breaks down all the usage into categories you specify.  This is displayed on the Clients page in the dashboard – click the right arrow from the default Applications chart to get to it most quickly.

Meraki Custom Pie ChartHovering over a slice of the pie will give you the specific details about the category represented.

Clicking the More link under the chart displays a table showing the details about all the categories.

The chart is also shown on individual client pages, showing the breakdown for that particular client.

How to create your custom pie charts

The first thing to note is that charts are created per network.  If you are using a network as a template. its chart will get copied as part of the setup process, but if you adjust the chart later, you’ll need to apply the change to other networks as well.  I haven’t explored the Configuration Templates feature of Meraki yet, but one might suppose this resolves this issue. Please comment if you know whether this is the case or not.

The first thing you need to do is decide what constitutes work traffic somehow.  If everything is hosted within your LAN or at fixed data centres, then that is pretty straightforward.  If you are using hosted services such as Office 365, then things are slightly more complicated.

A simple example

Meraki’s documentation about how to configure this is a bit hidden in this knowledgebase article.  I hope I can build on that by working through an example.

At the start of this example we’ll assume that work traffic is just on the LAN, and everything else isn’t work.  Obviously that isn’t very realistic but we’ll build on it.

In this example, the LAN uses addresses on a class A network, represented by

Everything else is represented by

The interface for creating slices is on the General page of a network, under the Traffic Analysis section.

Meraki Define Slices

Above I have selected to use Detailed Traffic Analysis – this keeps a record of all the hostnames and IP addresses requested, and is also useful to leave enabled for your out of the box application analysis.

I also added a slice in order to show the boxes.  In the name column, you provide the Name for the slice.  The signature is based on HTTP hostname (not just HTTP traffic is measured though), the IP subnet or address, ports or a combination of IP addresses and ports.

Let’s apply our work and non work rules to start creating the pie chart.

Meraki Pie Chart Example 1

Note that the rules are applied starting with the first. Anything that matches is a rule will not be matched further down, so put your catch all rule ( at the bottom.  You can drag your rules up and down using the Meraki Drag Icon icon.

Once the traffic has been analysed, you’d get a simple custom pie chart showing Work (or internal) and Not Work (or external) traffic.

In the real world. there are probably some externally hosted services that constitute work.  Let’s say that staff access email hosted on Office 365 via the web interface, and files are stored in a Office 365 SharePoint instance.

Meraki Custom Pie Chart Example 2

Perhaps you want to monitor the use of a specific system hosted on your LAN. As long as you can identify traffic to and from it via a hostname or IP address then you can graph it.  In this case, its a CRM system accessed vie the hostname companycrm.

Meraki Custom Pie Chart Example 3

By placing it above the Work rule, this will be matched first which is necessary to graph it separately.

As you can see you can build up your rules to get quite complex reports on bandwidth use.  It’s very flexible so you can use it to slice and dice your bandwidth reports in the way most useful to you.

After you save the changes, it will take a while for Meraki’s servers to crunch the data and produce a graph (and it seems to show partial graphs during the process) so leave it a couple of hours or overnight before marvelling at your charts.

If you find this useful, please share your experience in the comments, and please do share any tips that make this feature any more useful.