Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - you

#1
Summary

This is how I setup my DNS environment with pihole and OPNsense. With this I achieved the following:

  • Clients are exlusively referred to pihole as DNS server
  • pihole acts as adblocker with logs, simple whitelisting and statistics
  • pihole acts as recursive DNS server
  • internal name resolution works as well

Some additional remarks:

  • DNS changes often only apply if you disconnect and then re-connect a client.
  • Sometimes a reboot of pihole instance might be helpful.


1) Example: Network Setup

  • LAN:     10.10.1.0/24    - local_lan.domain
  • LAN2:   10.10.10.0/24  - local_lan2.domain
  • sense:  10.10.1.1
  • pihole:  10.10.1.254

2) pi-hole (Example: debian VM, all executed as root)

a) Installation

Check here for details: https://docs.pi-hole.net/main/basic-install/

curl -sSL https://install.pi-hole.net | bash


b) Prepare pi-hole as recursive DNS server

Check here for details: https://docs.pi-hole.net/guides/dns/unbound/

apt install unbound

nano -w /etc/unbound/unbound.conf.d/pi-hole.conf 

Add the following text to pi-hole.conf (edit the end according to your networks):

server: 

    # If no logfile is specified, syslog is used
    # logfile: "/var/log/unbound/unbound.log"
    verbosity: 0

    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

    # You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
    prefer-ip6: no

    # Use this only when you downloaded the list of primary root servers!
    # If you use the default dns-root-data package, unbound will find it automatically
    #root-hints: "/var/lib/unbound/root.hints"

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # Suggested by the unbound man page to reduce fragmentation reassembly problems
    edns-buffer-size: 1472

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes

    # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
    num-threads: 1

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m

    # Ensure privacy of local IP ranges
    private-address: 10.10.1.0/24
    private-address: 10.10.10.0/24


service unbound restart

Now let's test it:

dig pi-hole.net @127.0.0.1 -p 5335

==> Query should succeed. Takes longer first time. Less as of second time, because it's cached by pihole

dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5335

==> Should output a SERVFAIL

dig sigok.verteiltesysteme.net @127.0.0.1 -p 5335

==> Should output NOERROR plus an IP address.


c) pihole DNS Settings 

Edit only what is listed below and leave everything else empty:

  • Upstream DNS Server #1: 127.0.0.1#5335
  • Listen only on interface eth0 (or whatever is available as interface)
  • Check Never forward non-FQNs
  • Check Never forward reverse lookups
  • Check Use DNSSEC
  • Check Use conditional forwarding: 10.10.1.1/24 | 10.10.1.1 | local_lan.domain
and don't forget to save :)


d) Enable Local Name Resolution

nano -w /etc/dnsmasq.d/02-custom.conf

And add the following text:


server=/local_lan2.domain/10.10.1.1
server=/local_lan.domain/10.10.1.1
server=/10.10.10.in-addr.arpa/10.10.1.1
server=/1.10.10.in-addr.arpa/10.10.1.1


These settings have to be seen in conjunction with Use Conditional Forwarding in pihole's DNS settings. Due to them pihole forwards all queries concerning local devices from itself to pfsense's Unbound DNS (10.10.1.1 in my example). All other requests are either forwarded to corresponding Root-Server or blocked, due to pihole's blacklists.


2) OPNsense

a) Systems / Settings / General

Leave `DNS`empty (that's all  ;))


b) Services / DHCPv4 /  NETWORK

Add pihole IP - 10.10.1.254 as only DNS server and maintain static IP addresses as needed.


c) Services / Unbound DNS / General

Check Register DHCP leases and Register DHCP static mappings to enable local name resolution.



3) Final Tests

a) On any client with internet access

ping 8.8.8.8

==> this should confirm you have a working internet connection at all  ;)

ping www.google.com

==> this should confirm your DNS setup is working, external addresses are resolved

nslookup doubleclick.net

==> should output:

    Server: 10.10.1.254
    Address: 10.10.1.254#53

    Name: doubleclick.net
    Address: 0.0.0.0


Address: 0.0.0.0 indicates it has been blocked. If not, check settings.


b) On any client of your internal networks

Check internal name resolution with

nslookup 10.10.1.254
==> provides pihole.local_lan.domain (in my example)

nslookup pihole.local_lan.domain
==> provides IP 10.10.1.254 (in my example)
#2
Hi,

ich habe an der Sense noch einen Port frei. Meine Überlegung war, an diesen den Ubiquiti AP zu stecken. 3 VLAN für VLAN1: ADMIN, VLAN2: WLAN-LAN, VLAN3: WLAN-Gäste.

Wenn ich nun die VLAN2 und LAN zu einer Bridge mache und VLAN2 keine eigene IP gebe, bleiben dann die Einstellungen für LAN (inkl. DHCP) gültig für beide Mitglieder der Bridge oder muss ich die Einstellungen von LAN auf die Bridge "hochziehen"?

Je mehr ich lese, umso konfuser werde ich ... und ich kann grad nicht wirklich experimentieren.

Merci
#3
Moins,

ich habe einen Knoten im Hirn:

1) Alle Clients in meinem Netzwerk bekommen die Firewall als DNS Server (DHCP oder manuell). Selbige verweist unter System/Einstellungen auf die AdGuard-DNS 176.103.130.132/176.103.130.134 (also Adblock, kein Schweinkram :) ).

2) Eine NAT Regel routet ALLE DNS Anfragen auf die Firewall (127.0.0.1) zurück. Damit können die AdGuard-DNS am Client nicht umgangen werden.

3) Alle Clients lösen sauber auf. Sowohl ping ins Internet, als auch ping hostname.domain.local. Werbung wird geblockt und Schweinkram ist nicht erreichbar. DNS kann nicht umgangen werden. Soweit so gut.

Problem:

Ich versuche einzelnen Clients vollen Zugriff aufs Internet zu geben. Spiegel Online bspw. wird wegen des Adblocks nicht mehr angezeigt. Was meine Frau auf die Barrikaden bringt :(

So bin ich vorgegangen:

a) Die NAT, die auf die Firewall für DNS zurückverweist, gilt für ALLE, außer Unlimited-Alias.
b) Die Unlimited-Mitglieder bekommen über den DHCP-Server LAN statisch ihre IP Adresse und explizit 8.8.8.8 als DNS zugeordnet.

Damit funktioniert zwar die Auflösung ins Internet, ABER ... pings an hostname.domain.local funktionieren nicht mehr.

Ich habe bereits versucht, in der DHCP Zuordnung entweder Firewall-DNS/8.8.8.8 oder 8.8.8.8/Firewall-DNS zu setzen. Es bleibt aber dabei. Internet-Ping geht, lokal wird nicht aufgelöst.

Ist das, was ich vorhabe, überhaupt zu machen?


#4
Wir haben hier in jedem Zimmer LAN Dosen an der Wand. Der Hausanschlussraum ist kein Hochsicherheitsraum, mithin für jeden zugänglich. Damit steht es jedem frei, ein Gerät via LAN-Kabel anzukoppeln. Ändern lässt sich das nicht, wäre fürs Heim auch nicht gewollt.

Gegenwärtig fahre ich quasi Clientless, Zugriffe werden ausschliesslich über IPs gemanaged, User müssen sich nicht anmelden. Und eine DHCP Guest-Range bietet ja nur so lange "Sicherheit", bis ein "findiger" Anwender sich selbst eine IP gibt. Und, wenn er/sie dann auch noch meine Admin-IP erwischt, kann ein Zugriff auf kritische Bereiche, außer durch entsprechend starke Passwörter für die darin erreichbaren Dienste, im Prinzip nicht mehr verhindert werden. Auch ließen sich so WebFiltering Profile umgehen.

Was bei WLAN noch einfach zu managen geht (Zugang nur über WPA2-Passwort) ist bei mit OPNSense für LAN-Bereiche über welchen Weg "analog" gestaltbar?

Ich bin für Ideen dankbar :)
#5
Hi,

nach einigen Tests in der VM, bin ich Vorgestern von Sophos XG auf OPNSense Bare-Metal umgestiegen. Ich habe viel im Forum lesen können. Sehr angenehm zu sehen, wie Moderatoren, FW-Cracks (und solche, die es werden wollen) und Developer hier Unterstützung geben. Das ist eine Riesen-Hilfe und "fühlt" sich alles in allem nach einer guten Entscheidung an :)

Nachdem es bzgl. der FW Regeln Klick machte und ich nunmehr nach Belieben in Local administrieren kann :) ,  steht bei mir nur noch die VPN Verbindung von unterwegs an, um produktiv wieder alles Wesentliche am Laufen zu haben.

Ich habe mich an die beiden Anleitungen für Road Warriors via IPSec und OpenVPN gehalten. Ich kann mit beiden auch eine Verbindung etablieren (erkennbar auf dem mobilen Device und im Status von OpenVPN). Ich bekomme aber zum "Verrecken" keinen Zugang ins heimische Netz.

Meine Konfiguration im Überblick:

Internet:
Public IP -> Fritzbox (incl. Telefonie) 192.168.2.1 -> Portfreigaben ESP/500/4500/1194 (grün) -> 192.168.2.110 (static) WAN -> OPNSense ....

Local:
.... OPNSense <- LAN (10.10.10.1 in 10.10.10.0/24) / OPT2 (10.10.1.1 in 10.10.1.0/24)

DHCP läuft auf den Schnittstellen LAN und OPT2. DNS ist eingerichtet und funktioniert soweit gut. Intern, wie extern sowie Reverse lösen Anfragen sauber auf.

VPN:
IPSec (10.10.100.0/24) -> Client (aus Telekom LTE Netz) bekommt 10.10.100.1 bei Connect zugewiesen
OpenVPN (10.10.0.0/24) -> Client (aus Telekom LTE Netz) bekommt 10.10.0.6 bei Connect zugewiesen

Meine Präferenz wäre im Moment IPSec. Von daher möchte ich mich zunächst darauf konzentrieren. Vielleicht löst sich damit auch das Problem bei OpenVPN gleich mit :)

IPSec

Schnittstelle IPSEC hat folgende Regel:

IPv4 *   *   *   *   *   *      Allow IPSec to CLIENTS

Schnittstelle WAN hat folgende Regeln:

IPv4 ESP   *   *   WAN Netzwerk   *   *      IPSec ESP    
IPv4 TCP/UDP   *   *   WAN Netzwerk   500 (ISAKMP)   *      IPSec ISAKMP    
IPv4 TCP/UDP   *   *   WAN Netzwerk   4500 (IPsec NAT-T)   *      IPSec NAT-T

NAT (Automatische ausgehende NAT Regelgenerierung - (keine manuellen Regeln können verwendet werden) aktiviert)

Es gibt weder Portweiterleitungen, noch Eins-zu-Eins, noch NPT. Lediglich die folgenden zwei Regeln für Ausgehend.

WAN   127.0.0.0/8 10.10.10.0/24 10.10.1.0/24 10.10.0.0/24 10.10.100.0/24   *   *   500   WAN address   *   JA   Automatisch erstellte Regel für ISAKMP
WAN   127.0.0.0/8 10.10.10.0/24 10.10.1.0/24 10.10.0.0/24 10.10.100.0/24   *   *   *   WAN address   *   NEIN   Automatisch erstellte Regel

Interessanter Weise sehe ich in den Logs der Firewall/Regeln, dass Verbindungen vorgenommen werden wollen. Sowohl in Richtung DNS, als auch in Richtung Device im OPT2 Subnetz bspw. Ich habe auch schon automatische Regeln zur Freigabe dieser Anfragen gesetzt. Alles leider ohne Erfolg. Mit der Regel auf IPSEC ist ja eh alles offen (oder?).

Ich wäre für jeden Tipp dankbar, diese Verbingung zeitnah wieder nutzen zu können 8)

Merci
you