Messages

Thanks Franco,

I was organizing this device's access for different server, all linux, and just continued in the same way with my sense. In fact I wasn't even aware I could do it via OPNsense's gui :D

I deleted the second entry in the file. Checked file. Added the second key via gui. Et violá authorized_keys is again carrying two entries.

Cool coincidence indeed.

Thanks guys!

ssh-copy-id would work for a standard FreeBSD or Linux system but in OPNsense you must use the UI to add the key to the user account in question.

Wow, what a coincidence :)

Just this morning, I manually edited /root/.ssh/authorized_keys on my OPNsense instance and added a second public key to it.

I tend to generate device based keys, which in this case leads to at least two public keys for the same user "root" on OPNsense.

Now: If I checked user parameters via gui, I can only see the original, first key. The second one is not visible. A quick test from my second device shows it nevertheless works. Shouldn't we be able to add more than one pub key to a user for device based keys?

Hi Franco,

concerning ... "would temporarily fix this anyway?"

I applied before mentioned patches yesterday around lunchtime. I haven't done anything since with OPNsense. And zerotier is still working as it should.

A restart of zerotier didn't do anything when the problem occurred for the first time a couple of days ago with the unpatched version.

Confirmed. Patch works here as well. Thanks

This (solution 2) helped me to get my local gateway working. Thanks :)

This helped me to get local DNS and outbound DNS working. Thanks :)

Keep up the great work AND spirit here. OPNSense is not only about a peace of software, it is about people as well. It just feels like being home ;)

Donated!

Thats almost 4 years ago. Some time after my donation I got infected with a virus that caused a lot of pain, for way too long: its name is "USG-PRO-4". I later accepted the fact that I made a mistake and approximately a year ago I returned back and feel relieved ever since.

Today's release of 22.1 reminds me of the great value OPNsense provides to me. Hence I am pleased to donate again.

Hier steht, wie ich es grundsätzlich eingerichtet habe: https://forum.opnsense.org/index.php?topic=21196.0

Damit ist der DNS auf allen Clients, die ihre IP Adresse über sense beziehen, gesetzt. Ausnahmen: Manuel gesetzter DNS oder in IoT Geräten manchmal fest verdrahteter DNS (meist 8.8.8.8 oder so).

Thanks, corrected :)

Ich sehe das genau so: Macht immer weniger Sinn. Gilt m.E. auch für IPS/IDS. Bin auf Feedback gespannt.

Same here.

DHCPv4 shows "Stopped" on dashboard. However, according to logs it is still running and clients still receive IP addresses. A reboot indeed solves it, until changes are made. I did not touch DHCP settings though. The last change I did was related to DynDNS and Gateway Monitoring.

@franco might be worth to look at it?

@meschmesch: might be appropriate to temporarily change thread title to "not solved yet?" so that it gains attention.

Ich habe auf meiner IPU662 mit 16GB proxmox mit 3 VMs laufen:

OPNsense (8GB RAM) - CPU auf HOST
2x Debian mit zahlreichen Docker-Containern - CPU auf kvm

Im Mittel konsumiert die Maschine 21% CPU, in den Spitzen (Updates) sind es mal 80%. Stromverbräuche sind im übrigen auf der Webseite zu den IPUs von nrg-systems in den Daten aufgeführt.

Einfach auf dem Dashboard die Anzeige für das Gateway aktivieren. Dort steht dann IP und Status.

[Summary]

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/

Code Select Expand

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/

Code Select Expand

apt install unbound

Code Select Expand

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):

Code Select Expand

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


Code Select Expand

service unbound restart

Now let's test it:

Code Select Expand

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

Code Select Expand

dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5335

==> Should output a SERVFAIL

Code Select Expand

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

Code Select Expand

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

And add the following text:

Code Select Expand


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

Code Select Expand

ping 8.8.8.8

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

Code Select Expand

ping www.google.com

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

Code Select Expand

nslookup doubleclick.net

==> should output:

Code Select Expand

    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

Code Select Expand

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

Code Select Expand

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

Vielen lieben Dank, nasq ! Super Hilfestellung. Jetzt hat es Klick gemacht.

Ich habe mittels der Controller Software jetzt

1) die benötigten VLANs unter Netzwerke angelegt (in meinem Fall 2 für WLAN-Family und WLAN-Guest). Das Standard-Netzwerk (Subnetz der Controller-Software) ist mein drittes Netzwerk, genannt "Management".

2) im AP die SSIDs mit VLANs versehen (siehe Drahtlose Netzwerke)

3) korrespondierende Profile gefunden, inkl. "Management" (siehe Profile)

4) im USwitch die Ports benannt und als Switch-Port-Profil je einem Port VLANA, VLANB und Management, also analog Netzwerke aus (3), zugeordnet.

5) Vom USwitch geht an die Sense ein Kabel direkt (WLAN-Guest/VLANA an GUEST Port der Sense). Das Kabel WLAN-Family/VLANB geht an den dummen LAN Switch (von da an LAN Port der Sense) und das Kabel "Management" geht an den dummen SERVER Switch (von da an SERVER Port der Sense).

So hat alles geklappt ... WLAN-Family ist im LAN und es braucht keine Bridge :D ...


Hinweis:

Sobald man ein VLAN in der Controller Software anlegt (1), wird automatisch ein korrespondierendes Profil angelegt (3). Letzteres verweist dann ausschliesslich auf das jeweilige Netzwerk, also bspw. VLAN100 auf VLAN100 oder Management auf Management oder ... je nachdem, was man in den Netzwerken angelegt hat (1).

Diese automatisch generierten Profile sind nicht änderbar und weisen ausschliesslich auf das zugrunde liegende Netzwerk. Damit liegt an Ports auch jeweils nur das zugeordnete Netzwerk an. Will man mehr über eine Leitung tragen, muss man ein Profil Manuell anlegen.


Ich bin seelig :D