Ugly bug in Draytek Vigor firewall?

One day I came across a unique error. A client reported that they were unable to query any nameserver outside their network, except for the case they query standard A records. So, A records worked fine but, e.g. NS or MX records failed with timeout. Local DNS servers was properly set with valid forwarders.
So, we experienced:
nslookup    
Default Server:  dc01.hq.local           
Address:  192.168.80.248                                                                 

> google.org
Server:  dc01.hq.local                   
Address:  192.168.80.248

Non-authoritative answer:                       
Name:    google.org                             
Address:  216.239.32.27                                                                         

> set type=mx 
> google.org                                 
Server:  dc01.hq.local                   
Address:  192.168.80.248                                                                       

DNS request timed out.                              
timeout was 2 seconds.                      
*** Request to dc01.hq.local timed-out   

> server 8.8.8.8                                   
Default Server:  google-public-dns-a.google.com           
Address:  8.8.8.8        

> google.org                            
Server:  google-public-dns-a.google.com        
Address:  8.8.8.8

DNS request timed out.                              
timeout was 2 seconds.                      
*** Request to google-public-dns-a.google.com timed-out      

What a riddle! Guess that! :)
After three hours it turned out that in their Vigor 2925 firewall router there was a built-in rule called "xNETBios > DNS" in the section called "Data filter" (very informative names by Draytek guys, phuhh). That blocked such special DNS queries - even if it was DISABLED!

Default factory settings

Factory settings

In the end I had to disable the entire Data Filter section - in that way, external DNS queries got to work as expected. I'm still unable to find any explanation for this.

Model Name : Vigor2925n
Firmware Version : 3.7.6
Build Date/Time : Nov 17 2014 17:20:57

Working

That's the screen you never want to see on your FSMO roles holder DC!

Windows failed to boot

OpenVPN and eToken5100 SafeNet token

SafeNet ePass USB token is a PKI authenticator tool. It's fully supported in, of course, Windows operation systems and, also, in Linuxes. A neat but expensive toy. It also can be used with OpenVPN. With Windows. But you will never find any documentation on how to make these two guys work together in Linux! Except for this blog. Follow these steps on a Debian/Ubuntu system: (this worked in a 12.* Ubuntu+Gnome, not tested with newer ones.)
apt-get update
apt-get upgrade
apt-get install openvpn libhal1 hal-info
unzip the stock driver, unzip the .iso and find your proper .deb or .rpm version. In my case, I installed:
dpkg -i SafenetAuthenticationClient-9.0.43-0_amd64.deb
Run your client tool to check if the token works (and you know your password):

Make your sudo system unsecure, lol: (only this line needs to be modificated)
%sudo    ALL=NOPASSWD: ALL
This is needed because we want to use a simple way to run openvpn by root privileges. Don't forget to restart sudo. And here comes the tricky part. Find the hardware id of your token in the command line with:
openvpn --show-pkcs11-ids
Then, your client.config must look like this: (only the bold lines matters:)

client
dev tun
proto udp
remote your.server.com 2001
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/ca.crt
ns-cert-type server
comp-lzo
verb 3
script-security 2
# for the sake of proper DNS working
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
# this is the connection with the token
pkcs11-providers /usr/lib/libeTPkcs11.so
# your ID goes here
pkcs11-id 'EnterSafe/PKCS\x2315/0250184313021110/ftsafe\x20\x28User\x20PIN\x29/5F4DD36B4A23533FC9BDBB2AC7372236E48F99E5'
or, for example:
pkcs11-id 'SafeNet\x2C\x20Inc\x2E/eToken/0223127c/John\x20token/FC67BBDD7AD8EACD'

Important: don't run the openvpn as a service because you won't see the authentication promt! Instead, in a command line do:
/usr/sbin/openvpn --config /etc/openvpn/client.conf

Entering password

Succesfully typed and connected, you will see:

Connected

Do not close this terminal x-window because the vpn process will die immediately. But the tun interface somehow remains up, so you had better create a "stopopenvpn" script and use it to clean up the processes and interfaces. In my case, that was a
x-terminal-emulator -e "sudo su -c /bin/vpndown"
command, the it called this simple vpndown script in a new window
#!/bin/bash
echo "Please wait..."
killall -9 openvpn
sleep3

The VPN started with a user friendly desktop icon:
x-terminal-emulator -e "/bin/vpnup"
command. That called:
#!/bin/bash
if $(ifconfig|grep tun); then echo "OPENVPN already started, please stop it first. (click -> stopvpn)"
sleep 5
exit 1
fi
sudo su -c "/usr/sbin/openvpn --config /etc/openvpn/client.conf"
echo "Closing interface......"
sleep 5  
The funniest part is the echo Closing interface because that runs only if the openvpn itself is already terminated by the stopvpn in the other window. That is an elegant way to keep the user informed what's going on.
An alternative way to make the connection up without typing anything could be done by the help of the interactive shell expect:
apt-get install except
cat startvpn
#!/usr/bin/expect
spawn sudo su -c "/usr/sbin/openvpn --config /etc/openvpn/client.conf"
expect "Enter John token Password:\r"
send "MyL1ttleP4ssword\r"
interact

Living with IPFire (bye-bye pfSense)

In the first part of this article I discussed some interesting facts about pfsense. I, again, strongly recommend not to use pfSense 2.2.* in production environments because it is a totally unreliable and buggy system. Okay but what to use then ?
For instance, one can choose IPFire. Yep, I did. It's rock solid, lightning fast and easy to use system. Everything that can't be told about pfSense. I like it.
Except for one minor thing... And that thing is, sadly, not that minor.
For anyone who is familiar with standard iptables chains and logic (I mean input/output/forward/etc) it's very confusing the way pfsense and IPFire virtually handles the traffic.
IPFire consists lots of built-in chains that can be troublesome at the first glance. But you will never get to know about those ones if you use only the GUI based rules editor. I've spent 3 days, frankly, on creating some very basic allow and deny rule on the red0 interface, without any success. That totally screwed me up. You can just never be sure where (I mean, which chain) your web edited rules will be put in. E.g. below shown rules are all faulty, God knows why.

Playing with basic IPFire rules

So I ended up with editing the /etc/sysconfig/firewall.local file and tadaaam, that worked. If you are an expert on iptables, forget your firewall fancy GUI editor forever.

case "$1" in
  start)
        iptables -A CUSTOMINPUT -d 255.255.255.255 -p udp --dport 7437 -j DROP
        iptables -A CUSTOMINPUT -i red0 ! -s 192.168.1.1 -p udp -j DROP
        ;;
  stop)
        iptables -D CUSTOMINPUT -d 255.255.255.255 -p udp --dport 7437 -j DROP
        iptables -D CUSTOMINPUT -i red0 ! -s 192.168.1.1 -p udp -j DROP
        ;;

Just a small side note: reloading the rules with the GUI also reloads your .local defined rules.