Messages

8)
Sorry- I had to log off and logon again. And then it worked. My fault!

Ok, I guess it is done now. Sorry for confusion.

Going to add a second entry for my local domains.
THANKS!

You have not tried, no?

I can not add a second entry with same domain.

Hi,

sorry, I was not clear enough.

I was talking about the zone-based forwarding. I have a local DNS for my local zone. So I want Unbound to forward only those queries to my local DNS servers. And use the system configured servers for all other queries.

So yes, my Unbound uses configured "uolink" servers- except for the local domain. But for the local domain I can only add a single server in the GUI...

/KNEBB

[s]

Hi,

as far as I can tell the docs for Unbound say it can use multiple forwarders for query forwarding: "The servers listed as forward-host:"
In OPNSense I have not found an option to set multiple forwarders- seems like only a single one is possible.

How can I configure multiple hosts as forwad hosts?

Thanks!

/KNEBB

Und Du bist Dir sicher, dass das die richtige IP ist? Hast Du an den `nmap`mal ein "-O" rangehängt?

Und zur Struktur: V-DSL? Fritz!? Welche IP zeigt Deine OPNSense auf "ROT" an?

Ja, das mit den Pools ist mir schon klar... ich dachte halt nur, der betrachtet die dann als einen. Aber nein, er greift sich ein paar davon raus. Verstanden.

So sieht das aktuell aus:

Code Select Expand

root@router:~ # ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.opnsense.pool .POOL.          16 p    -   64    0    0.000   +0.000   0.000
 1.opnsense.pool .POOL.          16 p    -   64    0    0.000   +0.000   0.000
-185.252.140.126 218.73.139.35    2 u  493  512  377   25.704   -0.404   0.432
+152.70.19.169   169.254.169.254  3 u  248  512  377   22.091   +0.289  12.878
-31.209.85.242   .GPS.            1 u  393  512  377   21.890   +3.028   0.272
*78.47.168.188   17.253.14.123    2 u  488  512  377   26.540   +0.170   0.124
-148.251.5.46    192.53.103.103   2 u  491  512  377   25.612   -0.229   0.103
-77.90.40.94     3.227.217.39     4 u  379  512  377   20.700   -0.159   0.473
-49.13.14.46     205.46.178.169   2 u  466  512  377   26.436   +0.392   0.123
-85.214.83.151   192.53.103.104   2 u  342  512  377   26.057   +1.241   0.595
-212.132.97.26   192.53.103.104   2 u  434  512  377   15.758   -3.255   0.698
+158.180.28.150  169.254.169.254  3 u  422  512  377   22.092   +0.298  13.660
-5.45.97.204     68.126.43.53     2 u  193  512  377   25.851   -0.022   0.259


Verstehe ich nicht ganz,

die "roten" Failover haben doch nichts mit den Regeln zu tun?
Von internesNetz1 in internesNetz2 geht doch komplett an den Gateways (ROT) vorbei!

Und für den Internetzugang muss das doch auch nicht sein- gibst einfach kein Gateway an (ist ja bei DSL sowieso dynamisch). Dann entscheided die Sense, welches Gateway sie nimmt. Die bisherigen WErte Quelle, Zile und Port sind doch unverändert gültig, braucht man doch keine neuen Regeln...

Das bringt mich jetzt nicht weiter :D

Verstehe halt nicht, warum er immer nur einen als "Aktiver Peer" nutzt und die anderen alle als "Ausreißer" (bzw. einer "Kandidat") markiert sind...


Dann holt er sich doch die Zeit nur von einem? Sollte er nicht wenigstens zwei haben?

Moin!

Bei meiner OPNSense (aktueller Stand) habe ich den ntp-Dienst (Netzwerk-Zeit) aktiviert. Zwei externe Zeitserver sind konfiguriert und als "Bevorzugt" eingetragen:
```
0.opnsense.pool.ntp.org
1.opnsense.pool.ntp.org
```
Bei beiden zeigt er im Status "Unerreichbar/ Ausstehend" an :( Einen anderen Server hat er dagegen als "Aktiver Peer" gelistet- vermutlich ein Server aus dem Pool.

Fragen:

• Ist das normal, dass er die beiden Pool-Aliase als "Unerreichbar/ Ausstehend" anzeigt?
• Warum synct er sich mit nur einem Rechner, obwohl ja eigentlich zwei angegeben sind?

Die Namensauflösung der Sense ist einwandfrie, gerade direkt auf der ssh-Konsole bei Pool-Aliase problemlos auflösen (und pingen) können.
Und nein, es sind keine Regeln definiert, die den ausgehenden Verkehr beschränken...

Danke für Tipps!

/KNEBB

Ich habe bei SWN angerufen, Antwort: Für Private GEräte geben wir keinen Support, dafür ist der Kunde selber verantwortlich.

Das ist die übliche Ausrede von den Providern. Es gibt eine eindeutige Schnittstellenbeschreibung- lass Dir die geben (bzw. den Link dazu). Dazu sind sie verpflichtet. Und wenn dann Benutzername/ KEnnwort notwendig sind, müssen sie das auch rausrücken.
Die sollen keinen Support für Deine OPNSense machen, verlangt ja keiner. Aber die Schnittstelle muss problemlos genutzt werden können.

Bei mir (nicht NMS) haben sie auch ewig rumgezickt, aber letztendlich akzeptiert.

/KNEBB

Hi,

I have Unbound running on my OPNSense and a public mailserver with spamassassin behind.

I noticed log messages on my mailserver like this:

Code Select Expand


Jun 11 06:16:23 net spamd[9635]: check: dns_block_rule URIBL_BLOCKED hit, creating /root/.spamassassin/dnsblock_multi.uribl.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny multi.uribl.com" to disable queries)
Jun 11 06:16:23 net spamd[9635]: check: dns_block_rule RCVD_IN_ZEN_BLOCKED_OPENDNS hit, creating /root/.spamassassin/dnsblock_zen.spamhaus.org (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny zen.spamhaus.org" to disable queries)
Jun 11 06:30:12 net spamd[9635]: check: dns_block_rule URIBL_BLOCKED hit, creating /root/.spamassassin/dnsblock_multi.uribl.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny multi.uribl.com" to disable queries)
Jun 11 08:00:35 net spamd[9635]: check: dns_block_rule RCVD_IN_VALIDITY_CERTIFIED_BLOCKED hit, creating /root/.spamassassin/dnsblock_sa-trusted.bondedsender.org (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny sa-trusted.bondedsender.org" to disable queries)
Jun 11 08:00:35 net spamd[9635]: check: dns_block_rule RCVD_IN_VALIDITY_SAFE_BLOCKED hit, creating /root/.spamassassin/dnsblock_sa-accredit.habeas.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny sa-accredit.habeas.com" to disable queries)
Jun 11 08:00:35 net spamd[9635]: check: dns_block_rule RCVD_IN_VALIDITY_RPBL_BLOCKED hit, creating /root/.spamassassin/dnsblock_bl.score.senderscore.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny bl.score.senderscore.com" to disable queries)
All with different but similar error messages.
Initially I did not have unbound configured but used some default open DNS servers.

Doing a search for the above errors lead into "install a local resolver like unbound". So did I. Same result, just less frequent.

For those who have similar issues, here's the solution.

The root cause is the blacklist queries are coming from very high frequent nameservers like Google (1.1.1.1) or Quad (9.9.9.9) which I had configured as forwarder. And the blacklists saw the queries only from these IPs and blocked them due to high volume.
I noticed this by doing a dig command:

Code Select Expand

root@netp:/# dig @opnsense 2.0.0.127.multi.uribl.com txt +short
"127.0.0.1 -> Query Refused. See http://uribl.com/refused.shtml for more information [Your DNS IP: 172.70.241.83]"

So this revealed a Cloudflare IP. But where did it come from?

In my Unbound I had configured forward servers. So my Unbound forwarded all queries to the high volume DNS servers, too.

Obviously using a local cache did not help here.

Finally I configured my Unbound to NOT use any forwarders - or use the local ISP DNS servers.
Once done, the above messages went away and I am back to proper spam protection.

Just in case it helps for some guys searching for the same issue.

/KNEBB

Moin,

ich habe das jetzt nicht geteste und bin mir auch nicht sicher, ob es funktioniert.

Wenn Du (ähnlich einer Failover-Lösung mit zwei WAN Anschlüssen) so konfigurierst, dass Du eine GatewayGruppe baust? Dann sind doch die NEtzwerkkarten definiert und dann ist es doch eigentlich egal, über welches GW er rausgeht. Der Core-Router routet ja dann an die jeweilige NAT-Ip zurück.

Nur als Idee....

/KNEBb

Moin,

hier läuft OPNSense auf einem ThomasKren LE-Server (Celeron J6412 @ 2.00GHz (4 cores, 4 threads)) mit 8G RAM.

Die Speicherauslastung leigt lt. Dashboard bei 48%, die CPU-Auslastung steigt nie über 40%.

Es läuft ein NGINX als Reverse-Proxy, der zwei Ports https:// (via LetsEncrypt) an zwei interne Server per http:// weiterleitet. Funktioniert auch wunderbar.

Ich habe nur mit den URLs Schwierigkeiten.

Im Ideallfall möchte ich für externe als auch interne Zugriffe die gleiche URL verwenden. Das ist natürlich aus zwei Gründen schwierig:
Zum Einen wegen der https:// bvs. http:// Problematik. Beide Anwendungen können kein https. :(
Zum Zweiten wegen den IPs- Ich kann den gleichen Namen intern auf die interne IP zeigen lassen, und extern auf die öffentliche. Nur doof wg. https...

Aktuell habe ich es so, dass ich intern den öffentlichen Namen auch auf die öffentliche IP zeigen lasse und die öffentliche https-URL verwende. D.h. ich greife von intern auf das WAN-Interface der OPNSense zu, diese betreibt den NGINX, der die Anfrage an den internen Server weiterleitet und die Antwort läuft dann ebenfalls wieder via OPNSense/NGINX.
Grundsätzlich funktioniert das, aber die Performanz läßt im Vergleich zum direkten Zugriif doch zu wünschen übrig. Ich vermute, dass das (auch) am NGINX liegt, deshalb die Frage, ob es Optimierungen gibt, so dass die Geschichte etwas schneller vonstatten geht?

danke& Grüße

/KNEBB

Jo, Dein "Modem" ist vermutlich ein Speedport, oder?

Der gibt auf seinem LAN Interface eine IP raus. So wie es aussieht aus dem 192.168.19.0er Netzbereich.

Du darfst also Dein WAN-Interface auf DHCP umstellen und NICHT PPPoE!

Dann sollte das klappen.

/KNEBB

Moin,

ich habe das nun anders gelöst.

Der Nginx macht weiterhin nur https, ohne Umleitung.

Statt dessen habe ich dem internen DNS gesagt, dass der lokale Hostname auf die externe, öffentliche IP zeigt (und nicht auf die interne).

Jetzt kann der Client vom lokalen Netz auf die öffentliche IP des Routers zugreifen mit der gleichen URL wie von Außen. Funktioniert!

Einziger Nachteil: Es geht jetzt auch intern IMMER über die OPNSesnse, aber das wäre es ja auch im anderen Falle gegangen.,

/KNEBB