OpenVPN on pfSense with Chrome OS

Do you need to connect a Chromebook to an OpenVPN running on pfSense? Here’s how you need to configure your OpenVPN server to be compatible with Chrome OS.

Under VPN / OpenVPN edit the server configuration as follows

Server mode: Remote Access (SSL/TLS + User Auth)

TLS Configuration: Unchecked

DH Parameter Length: 2048 bit

Encryption Algorithm: BF-CBC (128 bit key by default, 64 bit block)

Auth digest algorithm: SHA1 (160-bit)

Compression: Omit Preference (Use OpenVPN Default)

Setup the VPN on Chrome OS

See instructions from Google Support

To get the user and server certificates, from the pfSense UI go to System / Cert. Manager.

  1. Under the CAs tab,  find the certificate used for the OpenVPN server and click the certificate export icon  to export the certificate authority.
  2. Under the Certificates tab find the User Certificate for the VPN user you want to setup. Click the box icon  to export it as a P12 file.
  3. These files need to be available on the Chrome device, you can add them to the users Google Drive, or use some other method as desired.

Install the certificates using the steps listed under “Install certificates” via the Google Support link above.
Essentially in Chrome, you need to go to chrome://settings/certificates and import the CA certificate under the Authorities tab and the user certificate under the Your Certificates tab. When it asks for a password to install the .p12 file just leave it empty.

Add the OpenVPN connection to Chrome OS

  1. From the Chrome OS settings screen, click on Add connection, Add OpenVPN / L2TP…
  2. Enter the server hostname, for example vpn.mydomain.com or the public IP address.
  3. Under service name just give it any friendly name that makes sense, such as Acme. VPN.
  4. For Provider Type select OpenVPN.
  5. Select the CA certificate that you imported under Authorities.
  6. Select the user certificate you imported under Your Certificates.
  7. Enter the VPN username and password, and click Connect.

For larger deployments see https://support.google.com/chrome/a/answer/6080885 which talks about deploying using a Chrome extension which can be deployed using the Chrome Management Console.

NAT64 How-to with pfSense and TAYGA

Today pfSense does not support NAT64, although you can track the feature request #2358 in redmine.

In this how-to I will show you how to setup NAT64 for an IPv6-only LAN using TAYGA and pfSense as the edge router.

Topology

The topology I am using below looks like this. Replace the IPs with the associated IP addresses on your network.

  • pfSense v4 IP: 10.1.1.1
    The pfsense gateway IP on your network
  • pfsense v6 IP: 2001:4:1f:98::1
    The pfsense IPv6 gateway on your network
  • TAYGA device IPv4: 10.1.1.3
    An IPv4 address that the debian machine uses
  • TAYGA device IPv6: 2001:4:1f:98::2
    An IPv6 address that the debian machine uses
  • TAYGA tunnel IPv4: 192.168.64.1 (dynamic pool: 192.168.64.0/24)
    A IPv4 tunnel that is outside of the range of any subnets handled by pfsense. I used 192.168.64.0 but you can choose anything you’d like.
  • TAYGA tunnel IPv6:  2001:db8:1::2 (prefix: 64:ff9b::/96)
    Similar to the prior tunnel subnet, except that the prefix we are using is the RFC 6052 prefix used by the public Google DNS64 service.

Step 1 – Setup TAYGA

This should be done on a basic Debian linux installation. It could be a physical machine or a virtual machine. In my case I used a VM.

Assign it a static IPv4 and IPv6 address. Modify /etc/network/interfaces

allow-hotplug eth0
iface eth0 inet static
     address 10.1.1.3
     netmask 255.255.255.0
     gateway 10.1.1.1

iface eth0 inet6 static
     address 2001:4:1f:98::2
     netmask 64
     gateway 2001:4:1f:98::1
     dns-nameservers 2001:4:1f:98::1

Install the tayga debian package.

sudo apt-get install tayga

Modify /etc/tayga.conf and configure these line items.

tun-device nat64
ipv4-addr 192.168.64.1
ipv6-addr 2001:db8:1::2
prefix 64:ff9b::/96
dynamic-pool 192.168.64.0/24

Modify /etc/default/tayga as follows. This will automatically create the static routes and create the TUN interface for you on reboot.

RUN="yes"
CONFIGURE_IFACE="yes"
CONFIGURE_NAT44="yes"
DAEMON_OPTS=""
IPV4_TUN_ADDR=""
IPV6_TUN_ADDR=""

Modify /etc/sysctl.conf to allow the system to forward IPv4 and IPv6 packets, as tayga essentially acts as a router / translator.

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Now reboot your debian machine and when it’s rebooted you should see a new interface called nat64 that is configured.

Step 2 – Setup pfSense

There are 2 more things that need to happen. First DNS AAAA queries need to get translated for A-only domains to NAT64. And your network needs to know how to route those IP addresses through tayga.

For DNS64 we will use Google DNS.

From the pfSense webConfigurator, go to Services / DNS Resolver. And check the box that says Enable Forwarding Mode.

Next go to System / General Setup and enter the Google DNS64 addresses as shown below.


2001:4860:4860::6464
2001:4860:4860::64

We also need to create a firewall rule that allows traffic from 192.168.64.0/24 to get out from the LAN interface.

In pfSense go to Firewall / Rules. Select your LAN interface. Add a new rule with the following properties.

Action: Pass
Address Family: IPv4
Protocol: Any
Source: Network 192.168.64.0/24
Destination: Any

The final firewall configuration that you may want to change in pfSense, is under System / Advanced / Firewall & NAT
The following option is needed as otherwise some traffic is filtered by the pfSense firewall and things like Zoom.us video calls, and WebSocket connections will drop and come back up constantly.

Static route filtering: Bypass firewall rules for traffic
on the same interface
(check this box)

Now we’ll need to add the static routes so that the RFC 6052 prefix and IPv4 pool will be routed back to the debian machine running tayga.

Once again in pfSense go to System / Routing.
Let’s create two new gateways. Both should be on the “LAN” interface.
One with the IP of 10.1.1.3 and the other with an IP of 2001:4:1f:98::2

Next let’s create 3 static routes.

Route #1 – IPv4 pool

Destination network: 192.168.64.0 / 24
Gateway: 10.1.1.3

Route #2 – IPv6 prefix

Destination network: 64:ff9b:: / 96
Gatway: 2001:4:1f:98::2

Route #3 – IPv6 Tunnel Address

Destination network: 2001:db8:1::2
Gatway: 2001:4:1f:98::2

Ready to test

We are now ready to test! Go to the following URL.

http://[64:ff9b::d8da:e477]/

If it is working that site should load and say “NAT64 detected”

There are services such as Google’s Chromecast that do not yet work with NAT64. But Apple is making a big push towards all apps being compatible, so it’s only a matter of time before we can run our local networks v4-free!

Quick & Easy Let’s Encrypt Setup on pfSense using ACME

There is a wonderful new capability in pfSense to use Let’s Encrypt to automatically and securely generate fully recognized TLS certificates.

This is a great thing because security is important. Using self-signed certs is annoying at best. You still completely control your private key when using ACME via services such as Let’s Encrypt, so there is no security downfall to using it.

How-to use Let’s Encrypt on pfSense

Under System / Package Manager / Available Packages you should find a package called acme. Click the install button and allow it to complete.

Once installed you should find Acme Certificates under the Services menu.

The first step is to create your account keys. Enter a name, select the production server if you want this to be live.
Click “Create new account key” to generate a key and insert it into the Account key box.
Finally click the Register button and Save.

The next step is to create your certificate. Under Certificates click the Add button.
Enter the details such as the name.

In the Table you will see I selected “standalone HTTP server” and in the options set the listen port to 8082. This is important because the ACME server needs to be able to access this standalone HTTP server on port 80. We will accomplish this with a port forward rule in the next step.

Under Firewall / NAT / Port Forward create a new rule that forwards port 80 HTTP to your pfSense IP address which is 192.168.1.1 by default.
This allows the ACME server to communicate with your device to verify ownership.

Of course you can use other methods, I just found this to be the simplest option assuming that you have something already running on port 80 like I do.

Now let’s go back to Acme Certificates, and click the Issue/Renew button. If the domain name you used has correctly configured DNS, you should have a freshly minted certificate available for use under System / Cert. Manager.

To use this new certificate from the pfSense webConfigurator like I am, go to System / Advanced / Admin Access and select your new certificate under the SSL Certificate drop down menu.

Onward to TLS everywhere!

How-to configure Wi-fi in pfSense

Netgate offers the 802.11a/b/g/n wireless kit for APU but configuring pfSense to use it is not immediately apparent and I was not able to find a recent how-to or tutorial on how to do the setup. This tutorial is using pfSense 2.2 but should work with 2.1 as well.

This tutorial will help you configure a bridged LAN Wi-fi network. We won’t be dealing with creating a guest wifi network but if requested I’m willing to do that later.

It’s all about the bridge

The most tricky part of this is configuring the LAN bridge to the Wi-fi interface. I’m going to assume that you already have a LAN interface configured and your pfSense is working great. Now all you want to do is configure the wireless.

If you go to Interfaces->(assign) you probably see something like this.
Screen Shot 2015-02-20 at 21.17.13

Now in order to create the bridge without getting disconnected we need to do a bit of trickery.

Assign a new interface to something that is not in-use. For example a network port that you’re not using or even create a PPP interface temporarily just so you have something to assign it to. Once created it will probably be called OPT1 or OPT2. Go ahead and click on it, enable it, and rename it to LAN_PORT. It should then look something like this.
Screen Shot 2015-02-20 at 21.23.31

You should also have an interface assigned for you wifi card such as the wireless kit from Netgate. It might look like this.

Screen Shot 2015-02-20 at 21.26.44

And if you open the interface it should be enabled.

Screen Shot 2015-02-20 at 21.26.55

IPv4 and IPv6 configuration should be set to None for both the Wifi and LAN_PORT interface.

Now it’s time to actually configure the bridge. Under Interfaces->(assign) click on the Bridges tab. Click the + icon to add a new bridge.

Under Member interfaces select both the Wifi and LAN_PORT interfaces that you setup.
Click Save and apply these changes and you should see something like this.
Screen Shot 2015-02-20 at 21.33.18

Now go back to Interface assignments, and we want to adjust the assignments a little.

Assign the BRIDGE0 port to your LAN interface. And assign the port that was originally assigned to your LAN interface to the LAN_PORT interface. It should then look something like this.
Screen Shot 2015-02-20 at 21.34.46 Screen Shot 2015-02-20 at 21.34.54

In my case re2 was originally assigned to LAN and is now assigned to LAN_PORT.
Save these settings and apply, and you’re finished with the bridge!

More Wi-fi Settings

Now it’s time for the wireless settings. There are some gotchas that we’ll mention, but first here are screenshots of my configuration that is working great.

(To get to this configuration click on the Wifi interface from the Interfaces assignment tab.)

Screen Shot 2015-02-20 at 21.40.32 Screen Shot 2015-02-20 at 21.40.45 Screen Shot 2015-02-20 at 21.41.28

WPA Pairwise has to be set to Both, if you set it to AES the wifi will stop working. In my testing I found it was best to set WPA Mode to WPA2 and leave the Pairwise set to Both.

Otherwise you should be fine copying all the wireless settings from my screenshots, of course you’ll choose a different pre-shared key and SSID 🙂

Remember that your LAN IP address and other network settings must now be configured on the interface that you assigned to the bridge, and also DHCP should be enabled on that same interface.