I bought a new router for my home office. It's a Celeron J1900 2.0 GHz, 4 x 1 Gbps Intel NICs, 4GB DDR3 RAM, 8GB mSATA SSD sold by Protectli and preloaded with pfSense 2.3. It's a solid product. You can pick one up at Amazon. This replaced an older single-board computer running pfSense one point something. My motivation was to get something I could use to establish a site-to-site IPSec VPN between my home office network and Amazon VPC. More on that later.
The trouble I had after the initial setup of the new router was in DNS response queries for things that have private network addresses (RFC 1918). I'll give you a practical example so you don't think it's crazy to have a public DNS server returning addresses for private networks: one of my Vagrant configurations has a lot of private addresses that I share with my engineering team. We use a public DNS server to hold our development IP addresses. This keeps them all consistent and nobody needs to hack on their /etc/hosts (or gods forbid, C:\WINDOWS\SYSTEM32\drivers\etc\hosts) file. Anyway, responses for these internal addresses weren't arriving when my workstation made a request for them using the pfSense Unbound configuration. They mention this in the documentation. The solution is simple:
I'll write about setting up the VPN to AWS EC2 soon. Let me know if that seems interesting.
@ 10:20 AM
by Joseph Lamoree
The newsletter from OpenDNS went out this morning. I took a stitched screenshot because I couldn't find a way to link to the article that didn't include my marketing tokens, and I didn't want to skew their stats with my meta-sharing. The article about 80,000,000 malicious DNS requests being blocked every day piqued my interest and clicked the Learn More link from the message in Apple Mail (not that it matters). My default browser on Mac OS X (haven't upgraded to OS X yet) is Chrome (not that it matters). I have installed the fabulous extension from EFF, HTTPS Everywhere, which will prevent my browser from accessing sites that are known to support SSL/TLS and instead rewrite the outbound request to use the secure form. Unfortunately, the rules for such URL rewriting aren't always perfect, and instead of viewing the article after bouncing through go.opendns.com, I got an error message that indicated that the connection was refused.
The Git repository for the HTTPS Everywhere extension source code for both Firefox and Chrome is hosted at gitweb. I've drilled down into the tree and located the specific rules for OpenDNS. You can see that go.opendns.com is not an exception, so the link from the newsletter was rewritten to an unsupported scheme.
OpenDNS uses Marketo for marketing support (not that there's anything wrong with that). The problem is that go.opendns.com is a CNAME to mkto-m0127.com. Similarly, info.umbrella.com is a CNAME to opendns.mktoweb.com. Both these hostnames make user's feel warm and fuzzy -- the ones that pay attention to hostnames anyway. However, the servers are operated by the marketing partner. Unless the vendor supports SSL on behalf of the client, none of these domains will support SSL.
What can be done? Well, I suppose the client could operate their own redirector that does have valid certificates. HTTPS Everywhere users could mark opendns.com as an exception to URL inspection, but that is rather ham-fisted; it would be better to request that more exceptions be made to the HTTPS Everywhere rules. It's kind of a sticky wicket.
@ 9:57 AM
by Joseph Lamoree