If you've used my IPTables VPN Killswitch thread together with the Local Caching Name Server thread, you'll likely be unable to connect or reconnect to your VPN Provider Servers.
That's because IPTables will interfere with BIND (basically it won't be able to resolve your VPN's hosts), but there is a fix.
BETWEEN THIS RED TEXT, CONSIDER THIS WORK IN PROGRESS!
$ cat /etc/named.conf
options {
directory "/var/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
So what you need to do is this. And by the way, at this point the VPN Killswitch should be active and OpenVPN inactive (disabled).
1. Stop BIND:
# cd /etc/rc.d/
# ./rc.bind stop (you can use status instead of stop if you want to verify the current state)
2. Uncomment (remove the /'s) from the line "// query-source address * port 53;" in /etc/named.conf, so it looks like this "query-source address * port 53;". You can also leave the original line and just paste an uncommented copy right below like I did (check this threads image).
# vi /etc/named.conf (or use your favourite text editor)
3. Start BIND:
# cd /etc/rc.d/
# ./rc.bind start
4. Start OpenVPN:
# /etc/rc.d/rc.openvpn start /path/to/some/other/configfile.conf (read /etc/rc.d/rc.openvpn for more instructions)
You should now be able to connect to your VPN Servers normally (your local BIND server should be able to resolve the host names).
BETWEEN THIS RED TEXT, CONSIDER THIS WORK IN PROGRESS!
When the VPN goes down, there are still issues with the method above. I'll try to explain the problem the best I can. My IPTables VPN Killswitch is very restrictive, so much so that I have to start BIND, OpenVPN, sleep 10 seconds (less than 10s might work but it needs testing) and only then start the IPTables VPN Killswitch. If I start the IPTables VPN Killswitch first, BIND won't work and so OpenVPN cannot find the VPN servers. Now I know you might argue that it's unsafe to not have the IPTables VPN Killswitch running first, but if BIND doesn't work then OpenVPN will fail to connect. Below is the current order of commands that I'm doing. Hopefully I won't have to change it anymore.
Start BIND, OpenVPN and the IPTables VPN Killswitch (in order): # sh /etc/rc.d/rc.bind start && sh /etc/rc.d/rc.openvpn start /etc/openvpn/vpnconfig.conf && sleep 10s && sh /etc/rc.d/rc.firewall
Flush the IPTables VPN Killswitch, flush all the routes (so when you run /etc/rc.d/rc.firewall it won't complain about NETLINK), stop OpenVPN and then stop BIND (in order): # iptables -F && iptables -P INPUT ACCEPT && iptables -P FORWARD ACCEPT && iptables -P OUTPUT ACCEPT && ip route flush all && sh /etc/rc.d/rc.openvpn stop && sh /etc/rc.d/rc.bind stop
Also the line "// query-source address * port 53;" should be left as it is (do not remove the //'s). Since /etc/rc.d/rc.firewall is run last, uncommenting is unnecessary and apparently named won't work if you do so.
I've used some of the DNS Leak Tests below, and no DNS leaks were detected.
Once this situation is stable, I'll do a cleanup of this thread.I apologize if you tried this and had issues, but then so did I.
If you want to test your local DNS Server, there are plenty of online DNS Leak Tests available. Below are some for you to try.
http://dnsleak.com/
https://www.dnsleaktest.com/
https://tenta.com/test/
https://ipleak.org/
http://www.doileak.com/
http://cryptoip.info/
https://browserleaks.com/
https://hidester.com/dns-leak-test/
Post last edited at