Cisco Network Security

VPN Troubleshooting: Cisco ASA IKEv2

A scenario existed where the Phase 1 of a VPN would result in a proposal mismatch (or no proposal selected)

One the local side of the Phase 1 VPN, the settings where selected as group 14 for Diffie-Hellman, encryption as AES 256 bit and SHA 256 for the hashing algorithm.

On the remote side of the VPN, operating a Cisco ASA, the below configuration was present:

crypto ikev2 policy 1
 encryption aes-256
 integrity sha256
 group 14
 prf sha
 lifetime seconds 86400

If I enabled SHA1 locally as well as SHA256, the VPN came online OK. This was due to the prf line in the Cisco configuration containing sha (SHA1)

Changing the Cisco ASA configuration from prf sha to prf sha256 allowed the VPN to come online with only SHA256 as the hashing algorithm.

Linux Network Security Ubuntu

WireGuard – Minor Bumps in the Road

A couple of issues I’ve ran into whilst using WireGuard:

IPv6 preferred over IPv4

I use DDNS at home on my Mikrotik with the /ip cloud feature, it is a really simple way to map a dynamic IP address to a static host name.

I used this static host name for the Wireguard server, unfortuantly the IPv6 address is for the router rather than the server.

WireGuard no matter how long I leave it for does not try use the IPv4 address if an IPv6 address is also present on the hostname

For now I have had to disable my IPv6 tunnel and stick with IPv4.

Pings and traffic suddenly stop working

After a period of time, I was unable to ping the clients at the other end of the WireGuard tunnel. I assume it was due to something, like Network Address Translation, timing out.

This was a fairly trival fix by adding by adding the PersistentKeepalive to the configuration

PersistentKeepalive = 10

This sends a packet across the tunnel every 10 seconds to show any other network appliances that the traffic stream is ‘active’.

Network Security Ubuntu

Checking out Wireguard – Server Installation

Wireguard is the new kid on the block to open source VPN servers, let’s check it out.

The code base is described as slim, quick, and easy to set up.

I’m starting off with a new and ready to go Ubuntu 20.04 installation, let’s check out Wireguard

I start things off with installing the WireGuard package

sudo apt install wireguard

I switch to the root user and navigate to the /etc/wireguard folder, we can’t access the /etc/wireguard folder being just a normal user. That’s for a good reason too.

sudo -i
cd /etc/wireguard

Now that we are in the folder, we want to create our private key and public key.

The private and public keys make up the main security border to getting access to the Wireguard server so we will want to be careful with these.

We restrict access with our certificates by creating them with special file permissions to allow the ‘root’ user to only have access.

By setting the command umask 077; only the owner and group ‘root’ will have access to these certificates

umask 077

We can now safely generate our private and public keys, we accomplish this by running the command below:

wg genkey | tee privatekey | wg pubkey > publickey

This command generates a private key, sends that output to a file ‘privatekey’ and also sends it to another Wireguard command to generate a public key.

A key part to remember here is that that the private key is to be kept private!

Let’s create a configuration file for Wireguard within /etc/wireguard with nano

nano wg0.conf

Populate the file with the information below

# A seperate IP range for your VPN clients
Address = 10.X.X.254/24
# VPN Server Port
ListenPort = 51820
# The Servers Private Key
PrivateKey = Enter the value from the privatekey file here

We’ll likely want the server to run at boot time which can be enabled with this command

sudo systemctl enable wg-quick@wg0

And we can switch Wireguard on now with this command:

sudo systemctl start wg-quick@wg0

To verify the server has started OK, check that it’s IP address shows with network status:

# ip a show wg0

3: wg0: mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
inet 10.X.X.254/24 scope global wg0
valid_lft forever preferred_lft forever

Great! The server is running. Port forwarding to the server is outside of the scope of this post, but I have forwarded UDP 51820 on my router to the private IP address of the Ubuntu system.

Let’s set up a client to test with, I’ll use my Android Phone with the WireGuard app below:

After setting up the WireGuard app on the phone, creating a new profile will require copying the public key from the server to the phone.

The settings I went for on the phone app are as follows:

Name – Whatever

Private Key – Tapped a few times to generate

Public Key – Copy this and keep it safe for your server configuration

Addresses: Enter the clients IP address here

DNS Servers: Enter the DNS server you want to use whilst connected to the VPN

There is an option to add a peer, this is where the server details go:

Public Key – Public key from the server

Pre-shared key – Blank

Persistent keepalive – Blank

Endpoint – Enter the VPN server address, if you have port forwarded this will be the WAN IP

Allowed IP/s – Traffic that should be routed to the VPN server, if you want to route all traffic enter

The phone will generate it’s own public key which will need to be copied back to the server.

Add the section of the client to the wg0.conf file with nano:

# The Public Key Provided By The Client
PublicKey = ThePublicKeyCopiedFromTheClient
# The Clients IP Address
AllowedIPs = 10.X.X.1/32

Once that is done we can restart the client:

sudo systemctl stop wg-quick@wg0
sudo systemctl start wg-quick@wg0

At this stage if you connect the client to the server, both sides should be able to ping each other.

As I’ll be using this to access the rest of my LAN, it will be good to allow the Ubuntu OS to forward packets onwards. This is quite easy to do by running this command:

sysctl -w net.ipv4.ip_forward=1

This concludes the set-up of WireGuard server, a lot easier than OpenVPN for sure!

DNS Network Security

Fighting DNS hijacking with DNS over HTTPs/TLS

DNS-over-HTTPs/TLS is an up and coming technology that is slowly being adopted by different types of software, Firefox for example is beginning to enable it by default in their browsers with the DNS-over-HTTPs variant.

Whilst it has been met with some critism the advantages of finally being able to encrypt DNS queries is a good step towards internet privacy.

DNS hijacking used to be common with UK ISPs for returning targetted advertisements if a user typed in an non-existant domain. Later I found that an ISP was redirecting my search queries to their own hosted servers even though I had set my DNS servers to custom ones.

dnscrypt-proxy has been my goto fix for ensuring my DNS communications were untampered with for many years, but now I want to explore DOH (DNS over HTTPs) and DOT (DNS over TLS) to see if it fares any better.

I’m beginning by installing an application called stubby

sudo apt install stubby

On the manpage, Stubby is described as:

       ...a local DNS Privacy stub resolver, using DNS-over-TLS. Stubby encrypts DNS
       queries sent from the local machine  to  a  DNS  Privacy  resolver,  increasing  end  user

My goal is to install Stubby on my local DNS recursor server (running Ubuntu 18.04), and use it as a forwarded to securely resolve DNS queries.

It’s easy to tell that it’s my DNS server, as checking the service post-install shows it failed to start due to a port conflict:

stubby[5130]: error: Could not bind on given addresses: Address already in use

The configuration file looks to be in /etc/stubby/stubby.yml

First I want to fix the address bind error, so I find the section listen_addresses and add a custom port number at the end:

- 0::1@5353

Save those changes, and restart the service with:

systemctl stubby restart

If I now check to see if the service is running, it appears that it is:

sudo systemctl status stubby
‚óŹ stubby.service - DNS Privacy Stub Resolver
Loaded: loaded (/lib/systemd/system/stubby.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-09-16 19:49:22 BST; 4s ago

Great, so we’ve got the Stubby application now running for DNS resolution on the DNS box only. It’s not yet serving pushing the requests from the rest of the network yet but thats still to come. For now I want to change away from the default servers that are included so I’ll look at changing that.

There is a good sized list of secured DNS Public Resolvers here:

I commented out the list of existing servers, and added these three in to give them:

tls_port: 853
tls_auth_name: ""
tls_port: 853
tls_auth_name: ""
tls_port: 853
tls_auth_name: ""

Let’s now change my DNS Recursor (pdns-recursor) to use and give it a try!


Changes to:


Looking good!

Non-authoritative answer:
And cloudflare seems happy too!