Multi-Gateway change script for pfSense

Since pfSense is not actually rerouting router traffic itself (such as DNS, VPN, …) but only incoming traffic when a gateway goes down and another one is configured in the same gateway group, I have written the following script that you can use in a cron job. It will change the IPv4 default route for basically all traffic not specifically treated via FW rules – including the internal services.

  • MOBILE1 needs to be set to your second gateway, in my case a mobile LTE device
  • MOBILE2 and MOBILE3 need to be set to rarely used IPs – so the LTE traffic going there is not too much as
  • MOBILE2 and MOBILE3 need to be statically routed via LTE, always, to check their reachability
  • WAN1 needs to be set to your main gateway, in my case a FritzBox
  • WAN2 and WAN3 need to be set to pages you usually want to reach, but it is not so bad to be unreachable in case of a downtime of the WAN gateway as
  • WAN2 and WAN3 need to be statically routed via WAN, always, to check their reachability

The script will log changes and send mails to the email address configured in pfSense.

Bulk import DHCPD data into pfSense

Similar to my previous post, if you are trying to bulk import your current DHCPD data into pfSense, the built-in pfSense shell comes in handy.

Here we’ll start to use the current ISC-DHCPD configuration file, /etc/dhcp/dhcpd.conf, which will have entries like this:

Then run the following script – modify it to your needs – which will print out the commands for the pfSense shell. Since my DHCPD configuration is relying upon existing DNS entries and I am having hostnames as “fixed-address” entries, I need to resolve these entries with a dig command. If your file is always using IP addresses, just parse them out:

This will generate the following output, ready to paste into the pfSense shell:

Please keep in mind the index starts at 0, valid for an empty list of host names in your pfSense DHCPD configuration. For each already existing entry you have to add 1 to the starting index of 0.

Bulk import DNS data into pfSense

If you are trying to bulk import your current DNS data into pfSense, the built-in pfSense shell comes in handy.

First, get your current data into a file with 2 columns like this:

Then run the following script – modify it to your needs – which will print out the commands for the pfSense shell:

This will generate the following output, ready to paste into the pfSense shell:

Please keep in mind the index starts at 0, valid for an empty list of host names in your pfSense Unbound/DNS configuration. For each already existing entry you have to add 1 to the starting index of 0.

Sixxs Heartbeat Tunnel without Aiccu but Python (pfSense compatible)

For systems that do not provide Sixxs’ aiccu package to setup a GIF tunnel automatically, you can easily start the tunnel (not setup the routing ­čÖé ) by executing the following script once per minute via cron:

This solution was first posted here:

UBNT – Sixxs Tunnel

Output JSON-Code in readable and sorted form so it’s diffable

This code will read in a JSON file and print it out again in readable form and keys in sorted order – making two files diffable!

Usage: jsonsort.py

OpenVPN complains about wrong user/password without you requesting one?

If your OpenVPN client is complaining about a wrong user/password combination (AUTH_FAILED), although you are not requesting it on your server, it might be a completely different reason.

After migrating to a new operating system but taking OpenVPN’s configuration with me, I was running into this problem. All clients were complaining about wrong username and password.

The reason is simple:

I configured OpenVPN to send an email on connect and disconnect of a client. The script wants to use the mail command – which is not installed as default by Xenial. This leads to a client-connect-script error which in turn leads OpenVPN to respond with an AUTH_FAILED. Which in turn gives the “Wrong username/password” error message on the clients.

Solution: Make the client-connect script working again ­čśÇ

Epic fail: Wo lebt unser Innenmister? Auch in Deutschland?

Zitat aus dem Spiegel:

Maa├čen warnt vor IS-Anschl├Ągen – “Deutsche St├Ądte werden genannt

Der “Islamische Staat” (IS) hat mit seinen Anschl├Ągen auch in Europa f├╝r Angst und Schrecken gesorgt. Jetzt gesteht Verfassungsschutzpr├Ąsident Hans-Georg Maa├čen: Seine Beh├Ârde habe die Terrormiliz zun├Ąchst falsch eingesch├Ątzt. So habe man es zun├Ąchst f├╝r unwahrscheinlich gehalten, dass der IS den Fl├╝chtlingsstrom nutzen werde, um Anh├Ąnger nach Deutschland zu bringen, sagte Maa├čen der “Welt am Sonntag”. “Wir dachten, das Risiko sei schlichtweg viel zu hoch. Mittlerweile wissen wir: Was den IS angeht, m├╝ssen wir eben auch dazulernen.”

Was die Spatzen von den D├Ąchern pfeiffen, hat unser oberster Verfassungssch├╝tzer anscheinend nicht mitbekommen… wozu brauchen wir nochmals noch mehr Daten ├╝ber die B├╝rger, wenn wir schon das Offensichtliche nicht sehen?

EPIC FAIL, Herr Minister!

Installing a Vagrant BaseBox of CentOS

  • Install a minimal system of CentOS in VirtualBox
  • Activate networking on boot by enabling eth0 in
  • Add a vagrant user and assign the password vagrant to it
  • Give sudo rights to that user by adding vagrant ALL=(ALL) NOPASSWD: ALL with visudo
  • Disable requirement of having a TTY by commenting out the following settings with visudo:
  • Add insecure Vagrant public key from https://github.com/mitchellh/vagrant/blob/master/keys/vagrant.pub to vagrant’s authorized_keys
  • Add development tools for building the guest addons with
    The repo options are useful if you want to install from local installation media (ISOs) instead of fetching all from the net.
  • Install guest addons with
  • halt the machine
  • Remove all hardware that is not necessary from the base machine or else it will be available on the machines set up with Vagrant later!
  • Package Box with

Done!

Should Vagrant be unable to connect to your boxes derived from that base box, you might have a problem with SELinux, see here how this can be fixed!

SSH doesn’t allow logins with keys? SELinux!

If you have correctly setup your authorized_keys and are sure it should allow you logins with keys – then maybe SELinux is giving you a hard time. Especially if your user is not under the normal home directory folder /home. In your /var/log/{auth,secure} files you will see that sshd is not allowed to open authorized_keys and/or authorized_keys2 after you set the “LogLevel DEBUG” in /etc/ssh/sshd_config.

In that case, try to set the correct settings again:

chcon -t ssh_home_t ~PROBLEMATIC_USER/.ssh/
chcon -t ssh_home_t ~PROBLEMATIC_USER/.ssh/authorized_keys

Now everything will work again.