Development SSL for .NET Core and NGINX in Docker

Wed, 03 Aug 2022 21:00:00 +0100

We’ve all been there. You want to use SSL in development to mirror a production setup but it’s a pain to generate self-signed certificates, share them with the development team, and have them trusted locally.

Thankfully combining Docker and the dotnet dev-certs command makes this nice and easy for .NET Core Applications and NGINX - which I’m sharing here so I don’t forget :)

.NET Dev Certs Command

To make it easier for developers to generate and access development SSL certificates, the .NET Core provides the dotnet dev-certs command as part of the CLI experience.

This command allows you to generate, export, trust and clean up self-signed developer certificates for your applications.

The beauty of this command on Window is that it adds the certificate to the trusted store locally meaning that browsers will validate it as such.

By using this approach each developer can quickly generate their own certificates locally and mount them in Docker as part of a Docker Compose file.

.NET Core Application

.NET Core applications expect certificates in PFX format, so to generate a certificate in this format you can use the –format pfx option for the dotnet dev-certs command.

Below is an example of generating a certificate into a config folder:

dotnet dev-certs https -ep ./config/app-certificate.pfx -p BlahBlah --trust --format pfx

This command will then create a new certificate and trust it in the machines certificate store, before exporting it to the PFX file, with the private key protected by the password BlahBlah.

Having done this, we can then mount this certificate as a volume in Docker and set some environment variables to configure the .NET Core application to use this certificate:

app:
  build:
    context: app/.
    dockerfile: Dockerfile
  ports:
    - "50000:50000"
  environment:
    - ASPNETCORE_ENVIRONMENT=Development
    - ASPNETCORE_URLS=https://+:50000
    - ASPNETCORE_Kestrel__Certificates__Default__Password=BlahBlah
    - ASPNETCORE_Kestrel__Certificates__Default__Path=/certs/app-certificate.pfx
  volumes:
    - ./config/app-certificate.pfx:/certs/app-certificate.pfx

Voila! We have our .NET Core application listening on Port 50000 secured using SSL.

NGINX Docker Image

In many cases your application will be running on HTTP with a reverse proxy in front of it, such as NGINX.

To use a similar approach with the NGINX docker image, you can use the –format pem option for the dotnet dev-certs command to generate a key pair (i.e. crt and key files) in the PEM format.

Below is an example of generating a certificate pair into a config folder:

dotnet dev-certs https -ep ./config/certificate.crt -np --trust --format pem

In this example, the -np flag has been used to export the private key in the PEM file without the need for a password to be provided to read it.

In this approach, the NGINX config file can be updated to used these keys in it’s appropriate server block:

listen              443 ssl;
server_name localhost;
ssl_certificate     /etc/nginx/proxy-certificate.crt;
ssl_certificate_key /etc/nginx/proxy-certificate.key;

If a password is desired, it can be provided in the export command:

dotnet dev-certs https -ep ./config/certificate.crt -p BlahBlah --trust --format pem

Doing this then requires you to pass a ssl_password_file to NGINX using the ssl_password_file directive. For example:

listen              443 ssl;
server_name localhost;
ssl_certificate     /etc/nginx/proxy-certificate.crt;
ssl_certificate_key /etc/nginx/proxy-certificate.key;
ssl_password_file /etc/nginx/proxy-certificate.pass;

This file is just a simple text file with the password for the key inside it, or a list of passphrases to be tried, if you wish to have one single password file for multiple certificates.

Just like in the .NET Core Application example, these key files can be mounted as volumes:

proxy:
    image: nginx
    ports:
     - "80:80"
     - "443:443"
    volumes:
      - ./config/nginx.conf:/etc/nginx/nginx.conf:ro
      - ./config/proxy-certificate.crt:/etc/nginx/proxy-certificate.crt
      - ./config/proxy-certificate.key:/etc/nginx/proxy-certificate.key
    depends_on:
      - web-app
    links:
      - web-app

Refreshing Certificates

If you want to start from scratch with a set of certificates, you can run the following command:

dotnet dev-certs https --clean

This clears down the https certificates.

Okapi Maven Plugin

Sat, 16 Jul 2022 08:00:00 +0100

Photo by Safar Safarov on Unsplash

In the work we did at Lingo24 when I was there, we made use of the Okapi Framework - well a customised fork - as a key component in our content processing.

For those who don’t know the framework, it an excellent swiss-army like toolkit for localisation (l18n)/translation (t8n), which can be used either as a set of libraries or standalone tools.

Whilst the tools available are great, often I wanted to bundle part of the process within an existing CI/CD pipeline or build. As a heavy Maven user, and with winter nights setting in, the idea came to build a Maven plugin to do just that.

The result? The Okapi Maven Plugin.

The Okapi Maven Plugin

The Okapi Maven Plugin is a Maven plugin that allows execution of common actions using the Okapi Framework within a Maven Project.

It was inspired by the excellent okapi-ant project, written by Chase Tingley, one of the core Okapi Framework team. (Hey Chase 👋🏻)

Very much designed to scratch what was an immediate itch, it currently supports performing the following actions:

Execute a Pipeline
Export a Batch Configuration (BCONF)
Install a Batch Configuration (BCONF)

Using the Okapi Maven Plugin

The plugin is being released on Maven Central, so to use the plug-in you can simply include it in your project’s POM file in the plugins section.

<build>
  <plugins>
    <plugin>
      <groupId>io.meikle.maven.okapi</groupId>
      <artifactId>okapi-maven-plugin</artifactId>
      <version>1.0</version>
      <configuration>
          <!-- Configuration required here -->
      </configuration>
    </plugin>
  </plugins>
</build>

Okapi Version

By default, the plugin uses the latest Okapi Framework version, which at the time of writing this post is 1.43.0, with 1.44.0 coming soon.

You can validate the version being used by running the okapi:version goal.

mvn okapi:version

This can be changed by overriding the Okapi Framework’s okapi-core and okapi-application-rainbow dependencies in the plugin configuration.

<build>
    <plugins>
        <plugin>
            <groupId>io.meikle.maven.okapi</groupId>
            <artifactId>okapi-maven-plugin</artifactId>
            <version>1.0</version>
            <configuration>
                ...
            </configuration>
            <dependencies>
                <dependency>
                    <groupId>net.sf.okapi</groupId>
                    <artifactId>okapi-core</artifactId>
                    <version>1.41.0</version>
                </dependency>
                <dependency>
                    <groupId>net.sf.okapi.applications</groupId>
                    <artifactId>okapi-application-rainbow</artifactId>
                    <version>1.41.0</version>
                    <!-- Exclude non-required UI dependencies -->
                    <exclusions>
                        <exclusion>
                            <artifactId>*</artifactId>
                            <groupId>org.eclipse.platform</groupId>
                        </exclusion>
                    </exclusions>
                </dependency>
            </dependencies>
        </plugin>
    </plugins>
</build>

Binary Configurations

One of the main use cases for the plugin is to support the building of Binary Configurations, also known as a BCONF.

A BCONF is a single file binary bundle of a number of configuration items:

File Filter Settings - the settings on how a file is processed
File Mappings - the mapping of file extensions to file filter settings
Pipelines - the configurations determing the steps to be performed on the content
Plugin JARs - optional JAR(s) with custom code, typically file filters or steps.

The ability to bundle them together in a single BCONF them useful for sharing settings amongst colleagues, or when using the Longhorn server application for executing Okapi Framework processing.

Building BCONF files can be done from the Rainbow application interface provided by the Okapi Framework. To do this you configure the settings you want in the application and can then export a configuration.

The inverse process is also supported, allowing you to import a configuration to a particular directory so it’s contents can be used within the application.

To help with these operations, the Okapi Maven Plugin allows you to build and install BCONF files as part of your build.

okapi:export

The export goal builds and export a Binary Configuration file and can be configured to package up configuration items in a number of scenarios.

By default, the goal only has one mandatory parameter, bconf. This is the name or path to where the Binary Configuration file should be exported to.

The rest of the parameters are optional, allowing you to either package a pipeline and the filter mappings and/or plugins required to successfully execute it within Longhorn, or simply bundle a set configuration assets for sharing.

<configuration>
    <!-- Mandatory Name or Path to Export the BCONF to -->
    <bconf>export.bconf</bconf>
    <!-- Optional Pipeline to be used in the BCONF -->
    <pipeline>test.pln</pipeline>
    <!-- Optional Custom Filter Mapping(s) to be embedded in the BCONF -->
    <filterMappings> 
        <filterMapping>
            <!-- File extension to be mapped -->
            <extension>.htm</extension>
            <!-- Configuration to be used -->
            <configuration>okf_html@test</configuration>
        </filterMapping>
    </filterMappings>
    <!-- Optional Plugins to be included in the BCONF using Maven FileSet format- -->
    <!-- See https://maven.apache.org/shared/file-management/fileset.html for more details -->
    <plugins>
        <!-- Optional directory - can be absolute (include Maven variables), or relative to project baseDir -->
        <!-- defaults to project baseDir -->
        <directory>input</directory>
        <!-- Optional - Includes or Excludes -->
        <includes>
            <include>**/*.jar</include>
        </includes>
    </plugins>
    <!-- Optional output directory for the Okapi pipeline -->
    <!-- Defaults to the Maven target directory -->
    <outputDirectory>/tmp</outputDirectory>
</configuration>

okapi:install

The install goal installs a Binary Configuration file (a bconf) to a folder on the local machine so it can be used.

The configuration for this goal has two mandatory items:

bconf - the location of the BCONF file to install
outputDirectory - the folder to install the BCONF to

<configuration>
  <bconf>export.bconf</bconf>
  <outputDirectory>/tmp/install-test</outputDirectory>
</configuration>

Both paths can be absolute or relative to the Maven Project’s baseDir, which can be useful when chaining with the pipeline goal.

Pipelines

At the core of the Okapi Framework is the concept of a pipeline - a list of actions in sequence that can be applied to or more input documents. Each action is a step in Okapi parlance, which when chained together can build very powerful and complex translation workflows.

Pipelines can be developed using the user interface in Okapi Rainbow or via an XML format, with the framework supplying a significant library of out-of-the-box steps and pipelines for common actions in translation workflow. Like everything in Okapi, you can build your own steps.

To help with executing pipelines, the Okapi Maven Plugin allows you to execute pre-defined pipelines as part of your build.

okapi:execute

The execute goal executes a pipeline contained in a pipeline configuration file (a pln file) against the supplied input file(s).

By default, the goal has four mandatory parameters:

pipeline - the path to the pipeline file
inputFiles - the input files to process, defined using a FileSet
sourceLang - the source language name or code of the content
targetLang - the target language name or code of the content

There are many other configuration options available to allow you to specify additional options for customised filter configurations, plugin locations, or override default locations. These can be useful if you are embedding your own custom assets into a build.

<configuration>
    <!-- Mandatory Path to pipeline to execute -->
    <pipeline>test.pln</pipeline>
    <!-- Mandatory inputFiles using Maven FileSet format-->
    <!-- See https://maven.apache.org/shared/file-management/fileset.html for more details -->
    <inputFiles>
        <!-- Optional directory - can be absolute (include Maven variables), or relative to project baseDir -->
        <!-- defaults to project baseDir -->
        <directory>input</directory>
        <!-- Optional - Includes or Excludes -->
        <includes>
            <include>**/*.txt</include>
            <include>**/*.md</include>
        </includes>
        <excludes>
            <exclude>**/*.xml</exclude>
        </excludes>
    </inputFiles>
    <!-- Mandatory Source Language Name or Code-->
    <sourceLang>English</sourceLang>
    <!-- Mandatory Target Language Name or Code-->
    <targetLang>fr-FR</targetLang>
    <!-- Optional directory containing custom plugins -->
    <!-- Defaults to the project directory -->
    <pluginsDirectory>pluginsDir</pluginsDirectory>
    <!-- Optional Explicit Plugins using Maven FileSet format- -->
    <!-- See https://maven.apache.org/shared/file-management/fileset.html for more details -->
    <plugins>
        <!-- Optional directory - can be absolute (include Maven variables), or relative to project baseDir -->
        <!-- defaults to project baseDir -->
        <directory>input</directory>
        <!-- Optional - Includes or Excludes -->
        <includes>
            <include>**/*.jar</include>
        </includes>
    </plugins>
    <!-- Optional directory containing custom filters -->
    <!-- Defaults to the project directory -->
    <filtersDirectory>filtersDir</filtersDirectory>
    <!-- Optional output directory for the Okapi pipeline -->
    <!-- Defaults to the Maven target directory -->
    <outputDirectory>/tmp</outputDirectory>
</configuration>

Next Steps

Whilst I moved on from Lingo24 before being able to use the plugin in anger, I have continued to use it for automating actions on some personal projects. I plan to keep evolving it as and when I get a chance, so would love feedback on what could be better or additional features that would be handy.

Happy translating!

Apache Tika Docker Examples

Mon, 28 Dec 2020 08:00:00 +0000

Photo by Priscilla Du Preez on Unsplash

For a number of years I’ve been involved in the Apache Tika project as both a committer and PMC member.

With the increase in container technology usage over the past few years we spun up a separate repository for Apache Tika Server in Docker, called tika-docker with convenience images hosted on Docker Hub

This has resulted in questions on how to customise configuration and host instances that link to other services. To help people get started, we’ve created some example scenarios.

So let’s dive in and check them out.

The tika-docker examples

To get the examples started, we’ve created examples using Docker Compose of the following scenarios:

Recognising and Captioning Video and Images with TensorFlow REST (see here)
Enriching Academic PDF Parsing with Grobid REST (see here)
OCR of PDF or Images with Tesseract including a Custom Configuration (see here)
Named Entity Recognition (see here)

Using the examples

Install Docker and Docker Compose

Follow the instructions for install docker from here.

Follow the instructions for installing docker-compose from here.

Clone the tika-docker

Now fetch the docker-compose files and sample configuation from the tika-docker project on GitHub:

git clone https://github.com/apache/tika-docker

Run Docker Compose for Example You Want

First change into the tika-docker directory

cd tika-docker

Then you can execute docker-compose for the example you wish to try. For example, to try the Named Entity Recognition (NER) example you can:

docker-compose -f docker-compose-tika-ner.yml up -d

You can drop the -d if you want to stay attached to the containers.

Then if you supplied a text file with some sample data to the /meta endpoint:

cat <<EOT >> test.txt
Hello world from the Apache Tika Team (dev@tika.apache.org).
EOT
curl -T test.txt http://localhost:9998/meta

The RegEx Entity Recogniser configured in the NER sample configuration files would extract the email in the returned metadata:

"X-Parsed-By","org.apache.tika.parser.CompositeParser","org.apache.tika.parser.ner.NamedEntityParser"
"language","en"
"NER_EMAIL","dev@tika.apache.org"
"Content-Type","text/plain"

You can then stop the running containers using

docker-compose -f docker-compose-tika-ner.yml down

Customising the examples

Each of the examples comes with associated set of configuration files in the sample-configs directory.

Each sample has an appropriately named subfolder, with the associated Tika Config XML file(s) and any other configuration resources, such as properties files specifying URLs or settings.

├── customocr
│   ├── org
│   │   └── apache
│   │       └── tika
│   │           └── parser
│   │               └── ocr
│   │                   └── TesseractOCRConfig.properties
│   ├── tika-config-inline.xml
│   └── tika-config-rendered.xml
├── grobid
│   ├── org
│   │   └── apache
│   │       └── tika
│   │           └── parser
│   │               └── journal
│   │                   └── GrobidExtractor.properties
│   └── tika-config.xml
├── ner
│   ├── run_tika_server.sh
│   └── tika-config.xml
└── vision
    ├── inception-rest-caption.xml
    ├── inception-rest-video.xml
    └── inception-rest.xml

Tika Config XML

All of the scenarios have Tika Config XML files. These files configure the parsers or recognisers for the example.

In some cases this file is named tika-config.xml and is then loaded in the docker-compose file directly. In other examples, such as the Vision and OCR ones, the docker-compose file loads only one of the XML configurations as the default tika-config.xml through a volume mount.

For example, in the the Vision configuration for the Parsing and Captioning Video or Images with TensorFlow REST, you have a choice of three configurations:

inception-rest-caption.xml - for image captioning
inception-rest-video.xml - for object recognition in videos
inception-rest.xml - for object recognition in images

You can chose which you want to use by leaving commented the appropriate configuration in the docker-compose-tika-vision.yml file within the volumes section:

#... snip ...

volumes:
  # Replace the below with the configuration you want to use, or with your own custom one 
  # -  ./sample-configs/vision/inception-rest.xml:/tika-config.xml
  # -  ./sample-configs/vision/inception-rest-video.xml:/tika-config.xml
  -  ./sample-configs/vision/inception-rest-caption.xml:/tika-config.xml

#... snip ...

You can find more on ObjectRecognition and the TensorFlow in Apache Tika Server from my previous blog post here.

Want more?

I plan to write most specific blog posts, similar to the Tensorflow REST one, on each of these example scenarios. So please subscribe to the RSS feed for this blog if you are interested.

If you would like to see other examples like this, either let me know directly on GitHub or Twitter, or message on the Apache Tika Users or Developer mailing lists.

Apache Tika and the ObjectRecognitionParser for Object Recognition and Captioning Using TensorFlow REST.

Tue, 01 Dec 2020 08:00:00 +0000

Photo by John Schnobrich on Unsplash

One of the coolest new features added to Apache Tika in the past few years has been the addition of Parsers that leverage Deep Learning to perform object recognition and captioning.

Contributed by Chris Mattmann and Thejan Wijesinghe, through their work with USC Data Science, you can configure Apache Tika to call of to predefined models and get deep learning equivalent of ‘Hello World’ - tagging dog or cat pictures!

So let’s try it out.

Apache Tika and the ObjectRecognitionParser

What is the ObjectRecognitionParser?

The ObjectRecognitionParser is a Parser that can be configured to recognise objects within content and annotate the metadata with information on the objects it has recognised.

Internally, the recognised objects are returned in a RecognisedObject for generic objects or it’s CaptionObject sub-class for captioning:

RecognisedObject instances contain an ID, Label, Label Language and Confidence Score.
CaptionObject instances contain an ID, Caption Sentence, Caption Language and Confidence Score.

Both types are placed in the metadata collection during parsing.

The type of recognition to be performed needs to be defined within Apache Tika’s tika-config.xml through the configuration of ObjectRecogniser instances to be used by the parser.

Available Object Recognisers

There are a number of ObjectRecogniser implementations in Apache Tika, including offline recognisers that need Deep Learning tools installed on the local machine (e.g. DL4J or Tensorflow) as well as online recognisers that make REST call to services.

For now we are going to focus on the online recognisers, specifically ones that use Tensorflow REST APIs runnable in Docker from the USC Data Science team.

These are:

TensorflowRESTRecogniser - which uses a custom REST API around Tensorflow to perform recognition on images
TensorflowRESTVideoRecogniser - which uses a custom REST API around Tensorflow to perform recognition on videos
TensorflowRESTCaptioner - which uses a custom REST API around Tensorflow to perform image captioning

These instances us an implementation based on the paper “Show and Tell: A Neural Image Caption Generator” for captioning images, and the Inception-V4 model from Tensorflow for recognition in video and images.

I’ll come back to the offline ones in another post.

Let’s try it out on Tika Server

Get the Docker Images

To make it easier to get up and running we’ll use Apache Tika Docker and the helper docker-compose file.

First, get the tika-docker project from GitHub:

git clone https://github.com/apache/tika-docker

In here is a file called docker-compose-tika-vision.yml which contains everything you need.

To make it easier we’ll create a symlink to allow us to execute docker-compose without specifying the file each time:

ln -s docker-compose-tika-vision.yml docker-compose.yml

Configure our instance

Like most things is Apache Tika, the ObjectRecogniser can be configured using the tika-config.xml file format.

To make things easier, there are three sample configuration to choose from to get your started:

sample-configs/inception-rest.xml - for image recognition
sample-configs/inception-rest-caption.xml - for image captioning
sample-configs/inception-rest-video.xml - for video recognition

You can do this by leaving only the configuration file entry you wish to use uncommented (or present) in the volumes section of the docker-compose file.

For example, to use image captioning you can leave the following set:

volumes:
 - ./sample-configs/inception-rest-caption.xml:/tika-config.xml

Run Tika Server + Inception Services

With the above configuration set in the docker-compose.yml file, you can now load up the containers:

docker-compose up

Apache Tika Server will keep trying to reload until it can detect the configured Inception Service instance. If so want to avoid this, you can start the Inception Service first and then Tika.

Once they are loaded, you can now send some files to it:

wget https://upload.wikimedia.org/wikipedia/commons/f/f6/Working_Dogs%2C_Handlers_Share_Special_Bond_DVIDS124942.jpg -O test.jpg
curl -T test.jpg htp://localhost:9998/meta

This should then give you suggested captions as part of the metadata collection parsed:

"org.apache.tika.parser.recognition.object.rec.impl","org.apache.tika.parser.captioning.tf.TensorflowRESTCaptioner"
"X-Parsed-By","org.apache.tika.parser.CompositeParser","org.apache.tika.parser.recognition.ObjectRecognitionParser"
"language","en"
"CAPTION","a man standing next to a dog on a leash . (0.00022)","a man standing next to a dog on a bench . (0.00017)","a man and a dog sitting on a bench . (0.00011)","a man standing next to a dog in a park . (0.00007)","a man and a dog sitting on a bench (0.00006)"
"Content-Type","image/jpeg"

How about the Tika App?

You can also re-use the Inception Services from the docker-compose.yml file for the Apache Tika app interactively.

To do the captioning, you can just start the inception service you want - in this case inception-caption:

docker-compose up inception-caption

You can then create a custom tika-config.xml and setting the appropriate apiBaseUri

EOT >> tika-config.xml
<?xml version="1.0" encoding="UTF-8"?>
<properties>
    <parsers>
        <parser class="org.apache.tika.parser.recognition.ObjectRecognitionParser">
            <mime>image/jpeg</mime>
            <mime>image/png</mime>
            <mime>image/gif</mime>
            <params>
                <param name="apiBaseUri" type="uri">http://localhost:8765/inception/v3</param>
                <param name="captions" type="int">5</param>
                <param name="maxCaptionLength" type="int">15</param>
                <param name="class" type="string">org.apache.tika.parser.captioning.tf.TensorflowRESTCaptioner</param>
            </params>
        </parser>
    </parsers>
</properties>
EOT

It’s worth noting in the sample configuration the apiBaseUri uses the Docker Compose service name and internal port. For running outside, you’ll need to use the external facing port mapping and IP/Hostname of the machine it is running on.

Then you can run the Apache Tika App JAR using your custom configuration. For example, to launch it in GUI mode you could use:

java -jar tika-app-1.25.jar --config=tika-config.xml -g

What’s next?

These REST based Tensorflow models are great examples of how Deep Learning can be used to augment the logic approach of Apache Tika for content parsing or detection.

If you want to try adding basic tagging or captioning to your search or asset pipelines, these models could provide a start, or the REST API implementation provide inspiration for hosting your own Tensorflow models.

It is an area that will continue to expand in the project and provides another API extension point where you can build your own ObjectRecogniser implementations. Happy Parsing!

HP Probook Touchpad Slow After Supend Ubuntu 19.04

Fri, 06 Dec 2019 06:00:00 +0000

Photo of a Laptop Touchpad

Having got used to my replacement laptop, I’ve decided to keep using it, but there was one thing annoying me - the trackpad!

The trackpad is definately not the same quality as the MacBook Pro I was used to, but I could cope as the main features are there. However, I often move around a lot going from meeting to meeting, making use of the sleep/suspend capability.

That was when the trouble started…

Sluggish Touch

Upon waking from suspend, the touchpad was sluggish and jumping all over the place, rendering the machine unusable without a mouse!

The best way it seemed to get the touchpad to behave was to add post suspend script using systemd to reload the driver. A little hacky but effective!

Systemd and Suspend/Hibernation Hooks

It is really easy to perform an action either before or after you suspend, with systemd providing a nice script based hook within its systemd-suspend.service system service.

To use this, all you need to do is put an executable script under /usr/lib/systemd/system-sleep/ that checks whether the first argument is ‘pre’ for before the system suspends, or ‘post’ for after the system wakes. The script can have any name.

You can see more information in it’s man page:

man systemd-suspend.service

The Script

To sort this once and for all on the HP ProBook I wrote the following into a file called /lib/systemd/system-sleep/touchpad-reload:

#!/bin/sh
case $1 in
  post)
    /sbin/rmmod i2c_hid && /sbin/modprobe i2c_hid
  ;;
esac

And now the touchpad is as happy post-suspend as it is on a fresh restart. Happy days!

Cisco Meraki Client VPN on Ubuntu 19.04/19.10/20.04

Fri, 02 Aug 2019 06:00:00 +0100

Photo of Meraki MX84 Meraki Firewall from Cisco Meraki website

With my beloved, and worn, day to day laptop having to go in for repair, I had to setup a temporary laptop to work on for a few weeks.

At work we use Cisco Meraki devices in many places, including the edge of network for our various offices. Whilst their main use is to form a mesh network around our offices and server infrastructure, we also use them to enable a lightweight Client VPN solution.

The Cisco Meraki Client VPN option provides a L2TP/IPsec based VPN using either its own internal user store, an LDAP Directory, Microsoft Active Directory, or a Radius server to authenticate users.

Cisco Meraki provide great instructions for Windows, Mac and mobile devices, but really old instructions for Linux. Therefore, I am posting this as much to remind me the next time I need to set it up as to help others.

Install L2TP Plugins for Network Manager

By default, support for L2TP VPNs is not installed for Network Manager, so we need to install them:

sudo apt-get install network-manager-l2tp
sudo apt-get install network-manager-l2tp-gnome

Disable System xl2tpd

Network Manager spawns and manages its own instance of xl2tpd so if there is a system instance still running it will not be able to use UDP port 1701, and will instead use an ephemeral port (i.e. random high port).

To stop this from happening, we need to stop the deamon and disabling it from starting again:

sudo systemctl stop xl2tpd
sudo systemctl disable xl2tpd

Setup Your VPN Connection

Now you are ready to add your VPN connection. Having taken the steps above, we’ve Gnome Network Manager settings panel now includes the option to add L2TP VPN connections:

The main settings we need to customise to work with Cisco Meraki Client VPN are on the Identity tab.

We can give our VPN a name, set the VPN gateway, and add our user credentials (with optional NT Domain depending whether Active Directory is used as the authentication scheme).

We now need to set our IPsec and PPP settings.

IPsec Settings

In the IPsec Settings we need to tick the Enable IPsec tunnel to L2TP host checkbox , expand the Advanced settings, and then add three things:

Pre-shared Key - adding the key provided by your network administrator
Phase1 Algorithm - use the following 3des-sha1-modp1024
Phase2 Algorithm - use the following 3des-sha1

Click OK to set this on the connection.

PPP Settings

In the PPP Settings we need to make sure PPP is the only Authentication mechanism selected.

The other defaults should be OK, however I’ve included a screenshot to confirm against above.

Click OK to set this on the connection.

Use Your VPN Connection

The VPN should now be available in the Gnome Settings panel:

and in the main Gnome Menu for quick connect/disconnect

Hello world

Sun, 06 Jan 2019 08:00:00 +0000

Hello world! Please bear with me, I am just getting setup.