OpenVPN tutorial: Full tunnel add-on

Recently I had the need to get myself a VPN since I was more travelling and had to use networks with proxies that not only blocked illegal sites, but yielded timeouts on perfectly legal content. Using BSDnow‘s excellent OpenVPN tutorial I whent ahead in a breeze.  But normally I use OpenVPN to connect to a remote (internal) network. This time I it needed to pass all traffic through the VPN so I could access the net ignoring local proxies.

As the tutorial mentions, adding push “redirect-gateway def1 bypass-dhcp” to the server’s openvpn.conf temporarily overrides the client-side default gateway forcing all traffic throug the VPN, that’s what I needed. Another (later on added) line was “topology subnet” since otherwise each client only gets a /32 subnet per connection which makes things a bit hairy at the next stage. tun0 on the server side then uses a /24 by default. “Large” missing piece for my use case was pf to NAT the VPN clients through the box to the internet. Here is the minimal ruleset for /etc/pf.conf I used:

ext_if = "vtnet0"
vpn_if = "tun0"

vpn_net = ""

nat on $ext_if from $vpn_net to any -> ($ext_if)
pass in on $ext_if inet proto tcp from any to ($ext_if) port 22
pass in on $ext_if proto tcp from any to any port 1194

I had to declare vpn_net since instead of i.e. a $vpn_if:network since at boot pf doesn’t know the network tun0 uses before OpenVPN comes up. Then it just NAT’s traffic arriving from VPN network on tun0 to the external interface. The 2 other rules let me SSH to the VM and allows OpenVPN traffic.

Since this setup needs forward traffic (two) network interfaces I had to enable packet forwarding, in the end all it needed was:

# sysrc gateway_enable="YES"
# sysrc pf_enable="YES"

To avoid a reboot and enable forwarding right now:
# sysctl net.inet.ip.forwarding=1 

Start pf and restart OpenVPN
# service pf start
# service openvpn restart 

Just in case: Make sure pf.conf is really loadable
# pfctl -f /etc/pf.conf

And that’s about it. It’s not a full tutorial, but just an add-on to the one over at BSDnow for those situations where you need a full tunnel for $REASON (and no, ToR isn’t always a working solution). A big thanks to the Adam McDougall, the original author and helping hand – and the BSDnow crew for their high quality content!

September 17, 2014

Posted In: Uncategorized

Tags: , , ,

One Comment

A low-power FreeBSD journey: High resolution terminal

Certainly managing a Unix-like server includes SSH and less often local console the screen resolution on the local console isn’t much of a matter, though having a little bit more than the standard can be nice when browsing through large files or grepping through logfiles. Thankfully as I learned, on the current (yet upcoming) FreeBSD 10 the GENERIC kernel is coming with reasonable defaults which limits the effort for high(er) resolution terminal to a minimum, or in short:

echo "allscreens_flags="MODE_280" >> /etc/rc.conf

… OK that’s definitely to short to be helpful. This article in the is quite good for me as beginners but, but it starts about having to recompile your kernel with VESA included. Right, not particularly something I’d like to do first just to get a better resolution right on a server’s console? Actually it seems that FreeBSD 10.0-RC3 on amd64 (at least) have the vesa driver built into the GENERIC kernel. The section of how to compile your own kernel is not required (anymore?). Just check your available modes, test it before messing up rc.conf and be happy.

# To check the available modes
vidcontrol -i mode

# To test your chosen mode works 
# FIXME: You do unmess if it doesn't except from rebooting?
vidcontrol MODE_280
# Once successful put the appropriate line in your rc.conf

MODE_280 equals to 1024×768 in 24-bit colour which isn’t exactly considered a high resolution to current standards but still more pleasant than the mere 80×25 characters yet still not too big for my smallest and oldest screen in the back of my cellar (i.e. a regular 4:3 15″ TFT) . Finally I should add that the FreeBSD handbook also contains a worthy-to-read section on this topic – and apparently it seems sufficient to load the vesa module with kldload. Though, not having an older release available I can’t relly check back. Another similar post can be found on this blog.

December 29, 2013

Posted In: Uncategorized


Leave a Comment

FreeBSD: How git and OpenLDAP server can collide via openldap24-(sasl-)client

I’ve have been doing some progress on my journey with bare FreeBSD, the tutorials are good and provide reasonable defaults to get started quickly. I quicklygot both a poudriere package builder inside a VM of my workstation and ezjail up and running on a small homeserver with an Atom CPU (that is quite not that quick a building). I actually wanted some extra switches enabled in my self-built packages not present in the binaries frome from

One jail would become a testbed for OpenLDAP I configured poudriere to build net/openldap24-server (default, except with SASL as enabled in i.e. Debian)  and since I like and use: devel/git (default). When I wanted to install git AND the OpenLDAP package in this jail, pkg  ended ith an obscure message telling me that files in openldap24-client conflicted with openldap24-sasl-client. Following the dependencies I tried to find the cause of the dependency conflict:

  • devel/git depends on  ftp/curl (default)
  • ftp/curl was (non-standard) configured to support LDAP and LDAPS since I want to play with LDAP:
    • That is what caused a dependency on openldap24-client for git.
    • Most other packages will do so once LDAP/LDAPS support is enabled (i.e. php5) – not on openldap-sasl-client.
  • net/openldap24-server with SASL results
    • in a package called openldap24-sasl-server (not openldap24-server!)
    • in a dependency of the server package depending on openldap24-sasl-client
  • Both openldap24-sasl-client got built and openldap24-client were almost identical (beyond SASL-support) and thus they conflict since they provide the same thing

I wanted SASL support but also git and curl. For whatever reason to fix this was to change make.conf as follows:


Using poudriere and a build jail called 10amd64, this was in: /usr/local/etc/poudriere.d/10amd64-make.conf.  Afterwards I (preferred to) completely rebuild all  package to make sure all package would take that switch (with -c):

poudriere -f /path/to/list-of-pkgs -j 10amd64 -c

Afterwards on the destined ldap server  both git and openldap-(sasl)-server now depended on openldap-sasl-client and could be installed alongside:

 # pkg install git openldap-sasl-server
Updating repository catalogue
The following 19 packages will be installed:

        Installing cyrus-sasl: 2.1.26_3 [1Labs]
        Installing openldap-sasl-client: 2.4.38 [1Labs]
        Installing curl: 7.33.0_1 [1Labs]
        Installing openldap-sasl-server: 2.4.38 [1Labs]
        Installing git: [1Labs]

The installation will require 279 MB more space

20 MB to be downloaded

Proceed with installing packages [y/N]:y

Unfortunately I wasn’t able to quickly find a reliable source why that switch has to be placed or is more closely explained. It can be found in a couple of packages, likely someon with more thorough FreeBSD experience would be able to bring a correct cause. It thoug causes packages with LDAP dependency to move their dependency from the normal to the sasl-enabled OpenLDAP client. At least, once I found about WANT_OPENLDAP_SASL, finding others who had this issue wasn’t difficult at all, i.e.

December 9, 2013

Posted In: Uncategorized

Tags: , , ,

Leave a Comment

Bootstrap pkgng without answering “y”

As per FreeBSD 8.4 9.2 and 10.0 (BETA as of writing) pkg will start replacing the old pkg_* tools, but the installed pkg command is only a bootstrapping command that downloads a current version of pkg and install it.
I like pkg, and coming from Debian apt-get and Redhat yum, the old pkg_* tools looked a bit – let’s say “rough” – while pkg looks and behaves quite familiar after using apt and yum.

I was looking for bootstrapping pkg (inside a ezjail flavour) without having to hit the ‘y’ each and every time. I was pointed to a very simple solution:

env ASSUME_ALWAYS=YES pkg bootstrap

Sometimes it’s just a matter of a) thorougly reading a manpage and b) put the pieces (switches, variables) correctly together.
Thanks Mat Arnold on this place for the right hint!

December 5, 2013

Posted In: Uncategorized

Tags: ,

Leave a Comment

Atom D510: FreeBSD cpu scaling, temperature and the non-existing C-states

A D510MO board was lying in the shelves and I decided to give a try for some FreeBSD testing. One topic I wanted to check out was power saving and getting to know. Most CPUs nowadays (even the now dated D510 Atom) support frequency scaling and most often C-States. Without digging into the details of FreeBSD’s ‘powerd’ enabling basic frequency scaling works as simple as adding the following line to /etc/rc.conf


sysctl can tell us what frequencies the CPU can work at ans the current freqency:

# sysctl dev.cpu | grep freq
dev.cpu.0.freq: 208
dev.cpu.0.freq_levels: 1666/-1 1457/-1 1249/-1 1041/-1 833/-1 624/-1 416/-1 208/-1

Now to check if the frequency scaling was working, hitting the CPU with some load was required, but where to take? On Windows a pretty simple tip taken from old journals was to fire up the system calculator app in scientific mode and let it calculcate very large factorials (german: Fakultät) like 999999999999! which will load the CPU and cause some heating in order to verify how loud a system can become – or in this case: Cause the CPU frequency to go up under load and scale down when back idle. It turns out FreeBSD base ships a with console-based calculator  called bc (on most Linuxes it’s GNU bc) which according to this yet old but still working article in Linux journal allows exactly this with a factorial function:

# bc
define f(x) {
 if (x <= 1) return (1);
 return (x*f(x-1));


In parallel on a second terminal execute “powerd -v” to see how the frequency goes up and down:

# powerd -v
powerd: unable to determine AC line status
[... system is idle, starting bc in the meantime ...]
load   0%, current freq  208 MHz ( 7), wanted freq  208 MHz
load   0%, current freq  208 MHz ( 7), wanted freq  208 MHz
load   4%, current freq  208 MHz ( 7), wanted freq  208 MHz
load  38%, current freq  416 MHz ( 6), wanted freq  261 MHz
load 141%, current freq  416 MHz ( 6), wanted freq 1044 MHz
changing clock speed from 416 MHz to 1249 MHz
load 100%, current freq 1457 MHz ( 1), wanted freq 3332 MHz
changing clock speed from 1457 MHz to 1666 MHz
load  93%, current freq 1666 MHz ( 0), wanted freq 3332 MHz
load 100%, current freq 1666 MHz ( 0), wanted freq 3332 MHz
load 100%, current freq 1666 MHz ( 0), wanted freq 3332 MHz
load 101%, current freq 1666 MHz ( 0), wanted freq 3332 MHz
load 100%, current freq 1666 MHz ( 0), wanted freq 3332 MHz
[ ... bc is running and now gets stopped ...]
load 100%, current freq 1666 MHz ( 0), wanted freq 3332 MHz
load  68%, current freq 1666 MHz ( 0), wanted freq 3332 MHz
load   0%, current freq 1666 MHz ( 0), wanted freq 3227 MHz
load   0%, current freq 1666 MHz ( 0), wanted freq 3126 MHz
load   0%, current freq 1666 MHz ( 0), wanted freq 3028 MHz
load   0%, current freq 1666 MHz ( 0), wanted freq 1453 MHz
changing clock speed from 1666 MHz to 1457 MHz
load   0%, current freq 1457 MHz ( 1), wanted freq 1407 MHz
load   0%, current freq 1457 MHz ( 1), wanted freq 1238 MHz
changing clock speed from 1457 MHz to 1249 MHz
load   0%, current freq 1249 MHz ( 2), wanted freq 1199 MHz
[... we see all supported clock speeds freq_levels passing by]
load   0%, current freq  416 MHz ( 6), wanted freq  208 MHz
changing clock speed from 416 MHz to 208 MHz
load   6%, current freq  208 MHz ( 7), wanted freq  208 MHz

This little experiment show that powerd is not that agressive when slowing the frequency back down as quickly as it rushes up, maybe tha its something to tune more aggressively on laptops.

Temperature readings

For CPU temperatures it happens to be as simple as loading the ‘coretemp’ module via kldload coretemp. Adding coretemp_load=”YES” to /boot/loader.conf enables the module ad system start. Afterwards CPU temperatures were readable via sysctl too:

# sysctl dev.cpu | grep temperature
dev.cpu.0.temperature: 44.0C
dev.cpu.1.temperature: 44.0C
dev.cpu.2.temperature: 41.0C
dev.cpu.3.temperature: 42.0C


Now most CPUs also support C-States to send to sleep when possible which would be actually quite good for power saving. In FreeBSD it seems sysctl can be used to query what C-states the CPU cores support via dev.cpu.<id>.cx_supported i.e.

# sysctl dev.cpu.1
dev.cpu.1.cx_supported: C1/1/3
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% last 58973us

Technically this would suggest that the CPU has the capability to use C3 but the current lowest C-State would be C1? I tried sysctl dev.cpu.1.cx_lowest=C3 as well as the global hw.acpi.cpu.cx_lowest=C3 (for boot this would be put in /etc/syctl.conf) but allas it remained always using 1 C-State.

It seems the Atom D510 is one of those low-end CPUs that do not support C-States anyway as per I’ve come across this thanks to FreeBSD PR 160561 where a very similar D525 was reported.
Possibly the CPU isn’t telling correctly about its supported C-states allas.

This was done on FreeBSD 10-BETA3 btw.

November 7, 2013

Posted In: Uncategorized

Tags: , ,

Leave a Comment