Messages

[It seems that dnscrypt is abandoned:]

Just for the records if anyone looks at this thread and for everyone using dnscrypt (and wondering why lookups won´t work anymore):

It seems that dnscrypt is abandoned: https://www.reddit.com/r/privacy/comments/7oyw0h/dnscrypt_is_now_abandoned/

[EDIT: Added a solution to create a cron job]
[EDIT 2: URL for dnscrypt-resolvers.csv has changed - actions.d corrected.]

One addition from my side:

/usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv should be updated regularly. Otherwise dnscrypt lookups will stop working when DNS resolvers change their IP.

Quick and dirty solution might be to set up an individual cron job (e.g. monthly) to update resolvers list and restart dnscrypt-proxy:

1. Create file /usr/local/opnsense/service/conf/actions.d/actions_dnscrypt.conf with this content:

Code Select Expand

[update]
command:wget -O /usr/local/share/dnscrypt-proxy/dnscrypt-resolvers.csv https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v1/dnscrypt-resolvers.csv && /usr/local/etc/rc.d/dnscrypt-proxy restart
parameters:
type:script
message:Updating dnscrypt-resolvers.csv
description: Update dnscrypt-resolvers.csv


2. Restart configd

Code Select Expand

service configd restart

3. Add new cronjob in WebGui: System -> Settings -> Cron -> + (= add new cron job):
Day of Month: 15 (= start job once in a month on every 15th day)
As command select "Update dnscrypt-resolvers.csv" from drop down list.
Save changes + Apply.

Nicer would be to use a script that is included in dnscrypt-proxy source package:
https://github.com/jedisct1/dnscrypt-proxy/blob/master/contrib/dnscrypt-update-resolvers.sh.in
Unfortunately I haven´t found this script in OPNsense. Maybe it is missing... beside I am not familiar enough with FreeBSD.

Issue #1872, siehe hier:
https://github.com/opnsense/core/issues/1872

Über dieses Phänomen bin ich auch gerade gestolpert. Die Internal-Access List wird offenbar anhand der Listen-Interfaces erstellt. Ich dachte, es würde reichen, das OpenVPN-Interface auszuwählen, damit alle VPN-Clients aus dem OpenVPN-Subnet auf den Unbound-DNS zugreifen können.

Das geht aber nur, wenn man noch manuell eine Access List für das OpenVPN-Subnet (z.B. 10.0.8.0/24) hinzufügt.

Ich gehe eigentlich davon, dass das so nicht gewollt ist. Jedenfalls ist mir nicht klar, wieso hier das OpenVPN-Interface anders als das LAN- oder WLAN- oder sonstige Listen-Interfaces behandelt werden.

EDIT: Möglicherweise besteht ein Zusammenhang mit dem hier beschriebenen Phänomen?

[ad 1 (no startup on boot time):]

Finally I figured out some solutions:

ad 1 (no startup on boot time): The script in the first post won´t start dnscrypt-proxy automatically on boot time. In this thread we see the solution (second post of the linked thread): "(Add rcvar=dnscrypt_proxy_enable after name=...)"

Solution: Grab the actual dnscrypt-proxy script from Github:

Code Select Expand

#!/bin/sh
#
# $FreeBSD: head/dns/dnscrypt-proxy/files/dnscrypt-proxy.in 373758 2014-12-02 09:21:49Z xmj $
#
# PROVIDE: dnscrypt_proxy
# REQUIRE: ldconfig cleanvar
# BEFORE: SERVERS
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf to enable dnscrypt-proxy:
#
# dnscrypt_proxy_instances (str): Set to "dnscrypt_proxy" by default.
#                                 List of dnscrypt_proxy instance id's,
#                                 e.g. "dnscrypt_proxy_1 dnscrypt_proxy_2", etc.
# {instance_id}_enable (bool):    Set to NO by default.
#                                 Set to YES to enable dnscrypt-proxy.
# {instance_id}_uid (str):        Set to "_dnscrypt-proxy" by default.
#                                User to switch to after starting.
# {instance_id}_resolver (str):   Set to "opendns" by default.
#                                Choose a different upstream resolver.
# {instance_id}_pidfile (str):    default: "/var/run/dnscrypt-proxy.pid"
#                                Location of pid file.
# {instance_id}_logfile (str):   default: "/var/log/dnscrypt-proxy.log"
#                                 Location of log file.
#
# To redirect a local resolver through dnscrypt-proxy, point it at 127.0.0.2
# and add the following to rc.conf:
# ifconfig_lo0_alias0="inet 127.0.0.2 netmask 0xffffffff"
# dnscrypt_proxy_flags='-a 127.0.0.2'

. /etc/rc.subr

name=dnscrypt_proxy
rcvar=dnscrypt_proxy_enable

load_rc_config ${name}

: ${dnscrypt_proxy_instances="${name}"}
: ${dnscrypt_proxy_enable:=NO}

dnscrypt_proxy_enable_tmp=${dnscrypt_proxy_enable}

command=/usr/local/sbin/dnscrypt-proxy
procname=/usr/local/sbin/dnscrypt-proxy

for i in $dnscrypt_proxy_instances; do
    name=${i}

    eval ${name}_enable=${dnscrypt_proxy_enable_tmp}
    rcvar=${name}_enable

    load_rc_config ${i}

    eval dnscrypt_proxy_uid_tmp=\${${i}_uid}
    eval dnscrypt_proxy_resolver_tmp=\${${i}_resolver}
    eval dnscrypt_proxy_pidfile_tmp=\${${i}_pidfile}
    eval dnscrypt_proxy_logfile_tmp=\${${i}_logfile}

:   ${dnscrypt_proxy_uid_tmp:=_dnscrypt-proxy}       # User to run daemon as
:   ${dnscrypt_proxy_resolver_tmp:=opendns}          # resolver to use
:   ${dnscrypt_proxy_pidfile_tmp:=/var/run/${i}.pid} # Path to pid file
:   ${dnscrypt_proxy_logfile_tmp:=/var/log/${i}.log} # Path to log file

    command_args="-d -p ${dnscrypt_proxy_pidfile_tmp} -l ${dnscrypt_proxy_logfile_tmp} -u ${dnscrypt_proxy_uid_tmp} -R ${dnscrypt_proxy_resolver_tmp}"

    pidfile=${dnscrypt_proxy_pidfile_tmp}

    _rc_restart_done=false # workaround for: service dnscrypt-proxy restart

    run_rc_command "$1"
done

ad 2 (dnscrypt-proxy not starting when unbound is already running):
Set Interfaces for Unbound DNS (General-> Network Interfaces) not to "All". If you mean "All" select everything except entries for dnscrypt-proxy.

I am not sure but it looks like dnscrypt-proxy (enabled in /etc/rc.conf) doesn´t start when Unbound is already running. In the dnscrypt-proxy we see the directive "BEFORE: unbound..." but this controls the normal "service... start" process. How can I make sure that the Unbound-Plugin will be started AFTER "service dnscrypt-proxy start" at boot time?

Unbound is part of our system, a base plugin if you will. We start auxiliary services afterwards, so in order to fix this we need to make dnscrypt-proxy a plugin as well to adhere to a correct starting order.

Ok, thank you for your reply. Unfortunately I have not the skills to develop a dnscrypt-proxy-Plugin. So the only option seems to wait for a plugin or - as a workaround - modify the dnscrypt-proxy-Start script in a way that Unbound will be stopped temporarily and started again after dnsycrypt-proxy has started. But... I have no idea how :-(

First, thanks to Cake for this nice Howto. I am wondering if anyone uses dnscrypt-proxy (as described in first post) with Unbound DNS.

I have the problem that after a reboot DNS isn´t working anymore. My workaround: Stop Unbound DNS manually (GUI -> Stop Button), than start dnscrypt-proxy via shell (service dnscrypt-proxy start) and finally restart Unbound via GUI.

I am not sure but it looks like dnscrypt-proxy (enabled in /etc/rc.conf) doesn´t start when Unbound is already running. In the dnscrypt-proxy we see the directive "BEFORE: unbound..." but this controls the normal "service... start" process. How can I make sure that the Unbound-Plugin will be started AFTER "service dnscrypt-proxy start" at boot time?

Thank you for the fast bug fix!

What about the account keys under /var/etc/acme-client/accounts/...? These are also world-readable and not part of ACME_DIRS in the setup script.

Hi,

is it a desired behaviour of the Let´s encrypt Package that "Test config" makes certificates and keys readable for any user with shell access?

New certificates are stored under /var/etc/acme-client/home/name_of_the_certificate with owner root:wheel and permission 0750 (drwxr-x---). That means normal users with restricted shell access cannot access the subdirectory. So far, so good.

BUT: "Test config" via WebGui (Let´s Encrypt -> Settings) changes permissions of the directory to 0755 (=drwxr-xr-x). This makes the certificate, configuration and key file readable for any user with shell access.

Actually I can´t see any reason for this behaviour as "Test config" shouldn´t change any permissions.

Thanks
beclar2

Same problem has been described here and here.
Pretty sure that OPNsense devs are already hunting the bug :-)

[EDIT:]

Hi folks,

I am running OPNSense 16.7.13 as VM under Proxmox. Everything works nice so far except Insight as flowd_aggregate doesn´t start.

Code Select Expand

/usr/local/opnsense/scripts/netflow/flowd_aggregate.py console
results in

Code Select Expand

Segmentation fault (core dumped)
Before the seg fault some .sqlite files are created in /var/netflow with 0B file size.

flowd seems to be working... flowd-reader /var/log/flowd.log shows nice data.

Are there any known issues with flowd_aggregate (or python2.7) under Proxmox/KVM?

Thanks in advance!

EDIT:Just for the records: Here is another thread about this issue.

Nein, hier (noch) kein produktiver Einsatz, wobei das für mein Anwendungsszenario ohnehin viel zu hochtrabend wäre (SoHo-Umgebung). OPNSense läuft bislang im Testbetrieb in einer VM.

Für die Clients, die ich testweise durch das virtualisierte OPNSense bedienen lasse, läuft allerdings bislang alles stressfrei mit SSL Domain/IP only. Als Remote Blacklist habe ich auch UT1 mit diversen Kategorien aktiviert, wobei ich Publicite noch nicht getestet habe. Als Browser läuft auf den Clients Chrome mit Adblock Plus, was vermutlich das Testergebnis beeinflusst.

Meine Testumgebung mit OPNSense in einer VM ist aber auch nicht Gelbe vom Ei, weil es doch manche Stolperfallen gibt, die auf die VM zurückfallen (gestern habe ich z.B. gelernt, dass IPS mit VirtIO-Netzwerktreibern Probleme macht). Neue Hardware für die FW soll noch angeschafft werden... vielleicht wird es ein Dell T20 mit Quad-Nic-Karte (ist zwar vermutlich als reine FW überdimensioniert, allerdings flexibler und derzeit sehr günstig).

Habe es mit bluewin.ch bei mir getestet und die Alerts tauchten auch in meinem Proxy-Log auf. Allerdings für mich nicht reproduzierbar. Die Seite wurde trotz der Alerts geladen.

Vielleicht ändert sich die IP just während des Zugriffs, weil dort ein Load-Balancer die Domain auf mehrere IPs verteilt? Oder ein Script auf der Seite ist die Ursache?

Ein manuelles nslookup liefert mir für die Domain jedenfalls gelegentlich wechselnde IP´s, ohne dass ich eine Regelmäßigkeit entdecken könnte.

Nochmals zum Thema "(local IP does not match any domain IP)": Mir ist aufgefallen, dass diese Warnungen und die Verbindungsprobleme zu https-Seiten via Proxy wieder auftauchten, als ich den DNS-Resolver nur auf das WLAN-Interface gelegt habe.

Seitdem ich DNS-Resolver->General->Network Interfaces wieder auf "All" gesetzt habe, ist keine Fehlermeldung im Proxy-Log aufgetaucht.

Die Einstellungen, die für mich laufen:
DNS-Resolver->General->Network Interfaces: All
DNS-Resolver->General->DNS Query Forwarding: unchecked
System->Settings->Do not use the DNS Forwarder as a DNS server for the firewall: unchecked

Schönes WE,
beclar

Hi folks,

I have entered a lot of DHCP Static Mappings and now it´s time to set up firewall rules for these clients. Is there any way to set (or export) DHCP Static Mappings as Firewall Aliases?

Thanks in advance,
beclar2