Google Keyboard accents and other special characters

I’m starting a new job. My new boss is from an East European country, and has accented characters in her name (ž to be exact). I would like to be able to use the correct diacritics when writing her name. Easy on my Mac (long key press to show all diacritics for a letter), but less so on my Android phone.

While the android language setting is set to English (UK) this character isn’t available via a long press (as it would be for è, â and ç). To make it available, I need to add a language that includes it (Croatian for example).

Here’s how:

  • Settings > Language and input
  • Virtual keyboard
  • Gboard
  • Languages
  • Turn off use system locale to allow selection of multiple languages
  • Enable your home language and the additional language that has the characters you need.

Now the accented options are available on a long press of the parent letter.

I also noticed that the gboard suggestions now includes the accented characters when before it didn’t.

Fixed.

Advertisements

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.

TL;DR

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 bittybot.co 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.

Summary

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.

  • 10.0.0.0/27 – Unused (a buffer for future use) – addresses 10.0.0.1 – 10.0.0.31 (the first address in this case isn’t usable since it is the start of the 10.0.0.0/24 subnet)
  • 10.0.0.160/27 – Servers – addresses 10.0.0.160 – 10.0.0.191
  • 10.0.0.192/27 – Printers – addresses 10.0.0.192 – 223
  • 10.0.0.224/27 – Network devices – addresses 10.0.0.224 – 10.0.0.254 (the last address can’t be used as it is the broadcast address for the 10.0.0.0/24 subnet.

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

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 (10.0.0.32 – 10.0.0.159 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:

Mode

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.

Topology

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.