I've had pi-hole for quite a while but something that hassled me was the choice between either running it as my DHCP server or forwarding all upstream queries through my router (which is my DHCP server today) and losing DNSSEC, performance and so on.

Today I finally got around to testing and implementing conditional forwarding for my pi-hole!

Step 1 - Create a custom configuration file, in my case it's called 0.5-custom.conf

sudo vim /etc/dnsmasq.d/05-custom.conf

Step 2 - Into the file place the following

server=/local/192.168.1.1

Essentially this tells DNSMASQ (which is the current backend DNS forwarder for pi-hole) to forward all requests for domains under local (eg - myiphone.local) to your router (eg - 192.168.1.1). Change the values to suit your network.

Step 3 - In the pi-hole gui feel free to change your upstream away from your router, to GoogleDNS or something else

Step 4 - Restart DNS on the pi-hole using pihole restartdns or the web ui

You're done. You can verify the effect using query logs and also using the pie chart on the pi-hole admin page which will start to change to show your new upstream whilst still showing requests to your router for local names.

Also if you want to override some public DNS (for say, running your own Steam cache) just use address= instead of network=

address=/content1.steampowered.com/192.168.1.2
address=/.steamcontent.com/192.168.1.2

Note the above list is incomplete, it includes content1.steampowered.com and all *.steamcontent.com.

Just another quick note on something I stumbled across recently that hopefully someone finds it useful.

Assuming you use a HTTP/HTTPS web proxy and you want authentication so that you can log requests against specific users chances are you are using Kerberos authentication.

The alternative is basic (but then your users get prompted) or NTLM. The problem with NTLM is that it is comparitively heavy and if you require authentication for each connection is not feasable once you reach a certain size.

Kerberos uses a fraction of the resources of NTLM and allows for seamless high performance authentication. You can read more about how it actually works on technet here.

An important part of Kerberos is the server name. For a proxy server it's derived from the FQDN of the proxy. However something important to note is that Kerberos fully resolves the FQDN including CNAMES.

This means if you have proxy.redmond.com as a nice service DNS but you CNAME it to server50.redmond.com the Kerberos ticket will be issued against server50.redmond.com and NOT proxy.redmond.com.

So say you change the CNAME and suddenly SSO is no longer working and it's driving your users nuts. They get prompted and when you do a packet capture you can see that the users machine is waiting for credentials to ask for a Kerberos token. But why would it suddenly do this? It worked fine before?

Something I didn't know is that by default SSO only functions for sites in the "Intranet" IE security zone. Now the proxy isn't a site but it must still fall into the "Intranet" security zone for SSO to work. So how best to do that? We could use GPO to push a rule making server50.redmond.com sit in the "Intranet" zone.

Just a quick note to anyone deploying SAML (in my case ADFS) for Splunk. I'm running 6.5.0 and although it seemed to be working early on after not too long I started to see the following error on logon:

The 'NotBefore' condition could not be verified successfully. The saml response is not valid.

After a little investigation it seemed likely that Splunk was rejecting the assertion from ADFS as it didn't like the "NotBefore" attribute. A little searching showed up that this may be due to clock skew between Splunk (the SP) and ADFS (the iDP).

There is a particularly good article on medium which explains the issue.

However we checked clocks and noted that they appeared to be in Sync. As time went on it became clear that the issue was intermittent and was probably due to very subtle clock drift between the SP and the iDP.

A bit more searching showed up a good question on Splunk Answers which seemed to be on the same track. Finally a Microsoft question on technet provided the full solution.

It seems Splunk is very aggressive when applying the NotBefore condition and doesn't allow for very much drift at all. As Splunk doesn't seem to have a configurable allowable window for this attribute we need to make a change in ADFS. Unfortunately this change isn't in the GUI but can be done using powershell and applied to the Splunk federation:

Add-PSSnapin Microsoft.Adfs.PowerShell #Load up the ADFS PowerShell plug in
Get-ADFSRelyingPartyTrust –identifier “urn:party:sso” #Just to see what the values were
Set-ADFSRelyingPartyTrust –TargetIdentifier “urn:party:sso” –NotBeforeSkew 2 #Set the skew to 2 minutes

Credit goes to the Technet answer for the above PowerShell goodness.

Applying this change seemed to fix up the issue so if you have the same thing hopefully this helps you.

Not sure if this is specific to Ghost (possibly not) and I need to look into this more but I had an annoying issue recently while trying to do some memory restrictions on Docker for Ghost.

The blog would sometimes start but often fail during migration/upgrade or randomly when the admin interface was accessed. I'd recently made a change to introduce memory restrictions (to properly define boundaries for garbage collection) onto the OS. I was re-creating the docker containers (256Mb for the important blog and 128Mb for this one).

This worked fine for other containers but when I tried to spin up my blog I got this (or something similar):

npm info it worked if it ends with ok
npm info using npm@2.15.9
npm info using node@v4.5.0
npm info prestart ghost@0.10.1
npm info start ghost@0.10.1

> ghost@0.10.1 start /usr/src/ghost
> node index

Killed

npm info ghost@0.10.1 Failed to exec start script
npm ERR! Linux 3.16.0-4-amd64
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "start"
npm ERR! node v4.5.0
npm ERR! npm  v2.15.9
npm ERR! code ELIFECYCLE
npm ERR! ghost@0.10.1 start: `node index`
npm ERR! Exit status 137
npm ERR!
npm ERR! Failed at the ghost@0.10.1 start script 'node index'.
npm ERR! This is most likely a problem with the ghost package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node index
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs ghost
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!
npm ERR!     npm owner ls ghost
npm ERR! There is likely additional logging output above.
npm ERR! Linux 3.16.0-4-amd64
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "start"
npm ERR! node v4.5.0
npm ERR! npm  v2.15.9
npm ERR! path npm-debug.log.896050243
npm ERR! code EACCES
npm ERR! errno -13
npm ERR! syscall open

npm ERR! Error: EACCES: permission denied, open 'npm-debug.log.896050243'
npm ERR!     at Error (native)
npm ERR!  { [Error: EACCES: permission denied, open 'npm-debug.log.896050243']
npm ERR!   errno: -13,
npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'open',
npm ERR!   path: 'npm-debug.log.896050243' }
npm ERR!
npm ERR! Please try running this command again as root/Administrator.

npm ERR! Please include the following file with any support request:
npm ERR!     /usr/src/ghost/npm-debug.log

After much stuffing around I discovered the really important part of this log is the Killed line.

npm install ran out of memory and was unable to complete. You’ll need to increase the virtual memory available to npm.

Source

So at least for now it seems I can't get the official Ghost docker container to run with less than 256Mb memory. I might follow up on this and try to find out why but I thought I'd post it on here in case anyone else has a similar issue.

Update 25 Nov 2016 - This issue is resolved in the DSM 6.1 Beta, hopefully it's coming down the line soon!

So most of my little bits an pieces (including this blog at present) are now hosted on my Synology NAS using Docker. It'll let me move stuff around if traffic increases but at the moment it suites me just fine.

Anyway a problem I've noticed recently is that the newer versions of Ghost weren't appearing in the tags list when I attempt to pull the image down.

This is what you see in the WebUI for docker but if I look at the hub page there are tags for latest, 0.9 and 0.8 (and some others).

So whats going on here. I don't pretend to be an expert in Docker so I do some digging and ask around. Surprisingly Synology came back to me fairly quickly (although initially reported a bug in Docker Hub) and pointed out that this is related to Docker Hub changing to a new API.

Essentially Docker Hub is running 2 versions of their API (v1 and v2). The V2 API is a big change from the first so both are still available. Here are the links to the tags for Ghost.

https://registry.hub.docker.com/v1/repositories/library/ghost/tags
https://registry.hub.docker.com/v2/repositories/library/ghost/tags/

If we look at both the JSON objects returned it becomes pretty obvious what is happening. The V1 API isn't sending out any of the newer tags.

Now I couldn't find anywhere official that points this out but asking in Docker IRC channels leads me to understand Docker Hub has now depracated the V1 API and as a result it is now Read Only.

End result is because Synology queries V1 first then if it doesn't return anything has a shot at V2 it's not getting the new tags.

Synology support tells me the next update to the Docker Package should remove support for the V1 API or at least query V2 first. If you want the update faster I encourage you to log support tickets with Synology.

The workaround is that you can use SSH to run docker commands straight on the Synology if you absolutely must have a tag that's not showing up.

TLDR : Synology is looking at old data from a deprecated API on Docker Hub for its tags. Issue will be fixed in a coming update.

Long title, I know. First some background, I’ve tried this in the past and haven’t been able to get it to work. I tried it this weekend and had it working in no time at all so that’s good. This is the first cut of this guide so I might update it as OpenWRT changes and as I optimize my configuration or write a new post if it seems like a better way to go.

First off, my environment is a Netgear WNDR3700 running Barrier Breaker 14.07. The IOS device used is an iPhone 6 running IOS 8.1.2. Although there are guides out there for this I thought it might need a little more detail given I had some problems with my firewall on the router and certificate verification on the IOS device introduced in IOS 8. I used StrongSwan as my VPN terminator.

1 - Install Required Packages

Log into router using SSH (I’m using the shell for my instructions here) and run the following:

opkg update

opkg install strongswan-default strongswan-mod-dhcp strongswan-mod-af-alg strongswan-mod-gcrypt strongswan-mod-blowfish strongswan-mod-md4 strongswan-mod-openssl strongswan-mod-pkcs11 strongswan-mod-pkcs8 strongswan-mod-test-vectors strongswan-mod-farp strongswan-mod-kernel-libipsec kmod-tun openssl-utils

This should install all the required packages.

2 – Add Required Configuration

Add the following section to your /etc/ipsec.conf file:

conn ios
         keyexchange=ikev1
         authby=xauthrsasig
         xauth=server
         left=%any
         leftsubnet=0.0.0.0/0
         leftfirewall=yes
         leftcert=serverCert.pem
         right=%any
         rightsubnet=192.168.1.0/24
         rightsourceip=%dhcp
         rightcert=clientCert.pem
         forceencaps=yes
         auto=add

Make sure you change 192.168.1.0/24 to the whole subnet on the LAN side of your router. This configuration will cause the client device to be automatically allocated an IP address from your dynamically allocated range on the LAN side of your router as though it was joining the network via WIFI or wired ethernet connection.

Add the following to your /etc/ipsec.secrets file:

: RSA serverKey.pem
anyuser : XAUTH "anypassword"

Replace user and password with a username and password of your choice (this will be the “account” and “password” fields on your IOS device).

Replace your /etc/strongswan.conf with the following:

# strongswan.conf - strongSwan configuration file

charon {

        dns1 = 192.168.1.1

        threads = 16

        plugins {

                dhcp {
                        server = 192.168.1.1
                }
        }

}

pluto {

}

libstrongswan {

        #  set to no, the DH exponent size is optimized
        #  dh_exponent_ansi_x9_42 = no
}

Replace 192.168.1.1 with the LAN IP address of your OpenWRT router.

Add the following to your /etc/firewall.user file in order to permit ipsec traffic:

iptables -I INPUT  -m policy --dir in --pol ipsec --proto esp -j ACCEPT
iptables -I FORWARD  -m policy --dir in --pol ipsec --proto esp -j ACCEPT
iptables -I FORWARD  -m policy --dir out --pol ipsec --proto esp -j ACCEPT
iptables -I OUTPUT   -m policy --dir out --pol ipsec --proto esp -j ACCEPT

Add the following to your /etc/config/firewall file in order to permit ipsec traffic:

config rule
 option src 'wan'
 option proto 'esp'
 option target 'ACCEPT'

config rule
 option src 'wan'
 option proto 'udp'
 option dest_port '500'
 option target 'ACCEPT'

config rule
 option src 'wan'
 option proto 'udp'
 option dest_port '4500'
 option target 'ACCEPT'

config rule
 option src 'wan'
 option proto 'ah'
 option target 'ACCEPT'

3 – Certificate Generation

Generate the CA Certificate

Run the following commands to generate the CA key. You may leave all the certificate details as below or you may set the certificate attributes if you want. There are no requirements on the CA Key for IOS:

ipsec pki --gen --outform pem > caKey.pem
ipsec pki --self --in caKey.pem --dn "C=DE, O=xxx, CN=xxxx" --ca --outform pem > caCert.pem

Generate and Sign the Server Certificate

Run the following commands to generate the server side (OpenWRT router) certificate and sign it with your custom CA certificate:

ipsec pki --gen --outform pem > serverKey.pem
ipsec pki --pub --in serverKey.pem | ipsec pki --issue --cacert caCert.pem --cakey caKey.pem --dn "C=DE, O=xxx, CN=xxx.dyndns.org" --san="xxx.dyndns.org" --flag serverAuth --flag ikeIntermediate --outform pem > serverCert.pem

Here you must replace xxx.dyndns.org with the Hostname or IP address you are entering into the “server” field on your IOS device. The IOS device will validate the certificate and that will fail if it does not match when you try to create the VPN connection on your IOS device.

Generate and Sign the Client Certificate

Run the following commands to generate the client side (IOS device) certificate and sign it with your custom CA certificate:

 ipsec pki --gen --outform pem > clientKey.pem
 ipsec pki --pub --in clientKey.pem | ipsec pki --issue --cacert caCert.pem --cakey caKey.pem --dn "C=DE, O=xxx, CN=client" --outform pem > clientCert.pem

Now you have to convert the certificate to the format IOS is after. When you get prompted for a password you must specify one, if you don’t you will not be able to install the certificate as IOS prompts for one even when one doesn’t exist and the field on IOS won’t validate if it’s blank:

openssl pkcs12 -export -inkey clientKey.pem -in clientCert.pem -name "client" -certfile caCert.pem -caname "xxxx" -out clientCert.p12

Copy the Certificates
You now have to copy the certificates to where Strongswan expects them:

cp caCert.pem /etc/ipsec.d/cacerts/
cp serverCert.pem /etc/ipsec.d/certs/
cp serverKey.pem /etc/ipsec.d/private/
cp clientCert.pem /etc/ipsec.d/certs/
cp clientKey.pem /etc/ipsec.d/private/

5 – Start OpenSwan

Run /etc/init.d/ipsec start to start OpenSwan (make sure there are no errors). Set OpenSwan to start at bootup using /etc/init.d/ipsec enable.

6 – Additional Firewall Setting

I had trouble with my firewall so this section is a bit of a workaround. Under “Firewall” settings in the web interface on the router change “Forward” to “accept”. Without this I could only ever get connectivity to the router itself but nothing on the LAN. Once I enabled this setting I was able to get full access as though I was on the local LAN.

7 – Send Certificates to the IOS Device and Create VPN Setting

Download caCert.pem and clientCert.p12 from your router and then email them to an email account you have on the iPhone. Open the email on your iPhone and import the certificates by tapping on the attachments. I’m not including screenshots of this bit because it is quite straightforward. If you need them let me know and I’ll expand this article.

Create a VPN configuration and select IPSec.

• Server : VPN Server, remember this hostname/IP must match the CN attribute in the client certificate or it won’t validate
• Account/Password : The username/password from the ipsec.secrets file
• Use Certificate : Set to on
• Certificate : Select the client certificate imported earlier

At this point you should be able to turn the VPN on on your IOS device and it should connect fine. If you have problems I suggest you check the log on your OpenWRT router, there is a great deal of information about connectivity and authentication in the logs that should help you.