Messages

Hallo zusammen,

hatte als Werbe- & Tracking-Blocker lange Zeit folgende Lösung genutzt:

https://devinstechblog.com/block-ads-with-dns-in-opnsense/

Nun bin ich auf eine etwas aktuellere Lösung gestoßen (die aber ebenfalls auf der ursprünglichen Variante von Devin's Tech Blog basiert):

https://github.com/matijazezelj/unbound-adblock

Das scheint auch alles gut zu funktionieren ... zum testen nutze ich normalerweise bild.de (da die manchmal selbst bei aktivierten uBlock Origin 'erkennen', dass ein Werbeblocker aktiv ist). Aber da wird alles geblockt wie es soll.  :)

Nicht so jedoch bei spiegel.de – da ist alles nur im ersten Moment geblockt, nach 2-3 Sekunden wird dann aber eine große Werbung von Dianomi eingeblendet, dazu noch am rechten Rand eine Werbung von Vodafone.

Beides lässt sich zwar (zum Glück) nicht anklicken (Seiten führen ins 'Leere', der Filter funktioniert also grundsätzlich).

Aber was kann bzw. muss man machen, damit auch so etwas wirklich geblockt wird? Ich würde sehr gern auf PiHole verzichten und das lieber weiterhin mit OPNsense-Bordmitteln lösen.

Erinnere mich, dass so etwas in der Art auch schon bei golem.de auftauchte, hatte dann irgend etwas von Proxies, Caching etc. gelesen, was die Webseitenbetreiber mittlerweile nutzen, um die Werbeblocker "auszutricksen"?

Im zweiten Posting zum Thread werde ich mal der Vollständigkeit halber noch meine Setup beschreiben.

Danke für Hilfe im Voraus.

Hallo,

die Qotom-Geräte mit i5 oder sogar i7, 16 GB RAM und 250er SSD finde ich super, vor allem auch dass sie lüfterlos sind finde ich gut.

Die Preise gehen auch in Ordnung – aber kann man die auch bei einem deutschen Händler beziehen?

Aliexpress wirkt auf mich eher nach 'ner Menge Ärger (Zoll etc.) – könnt ihr einen zuverlässigen Händler in der EU oder im Idealfall in Dtl. empfehlen?

Danke und Gruß

[In jedem Fall wie immer vielen Dank Euch allen für die tolle Unterstützung.]

Ok, der Thread kann wahrscheinlich als 'gelöst' markiert werden:

Bin gerade an einem Glasfaseranschluss (per Ethernet), die Werte sind jetzt denke ich so wie sie sein sollten:

Code Select Expand

Mac:~ user1$ iperf3 -c 192.168.1.199 -w 2m
Connecting to host 192.168.1.199, port 5201
[  5] local 10.23.8.2 port 56942 connected to 192.168.1.199 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  2.64 MBytes  22.2 Mbits/sec                 
[  5]   1.00-2.00   sec  1.16 MBytes  9.69 Mbits/sec                 
[  5]   2.00-3.00   sec  1.01 MBytes  8.47 Mbits/sec                 
[  5]   3.00-4.00   sec  1015 KBytes  8.30 Mbits/sec                 
[  5]   4.00-5.00   sec  1.01 MBytes  8.46 Mbits/sec                 
[  5]   5.00-6.00   sec  1.01 MBytes  8.50 Mbits/sec                 
[  5]   6.00-7.00   sec  1.03 MBytes  8.61 Mbits/sec                 
[  5]   7.00-8.00   sec  1.02 MBytes  8.58 Mbits/sec                 
[  5]   8.00-9.00   sec  1.01 MBytes  8.49 Mbits/sec                 
[  5]   9.00-10.00  sec  1.02 MBytes  8.57 Mbits/sec                 
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  11.9 MBytes  9.99 Mbits/sec                  sender
[  5]   0.00-10.21  sec  9.92 MBytes  8.15 Mbits/sec                  receiver

Das sieht nun so aus, wie ich es erwartet hätte.  :)

Also kann man festhalten: Per LTE-Hotspot gern testen, ob die Verbindung überhaupt zustande kommt – Geschwindigkeitstests sollte man über LTE aber eher nicht machen ...  ;)

Ich muss dazu sagen, dass ich die Buffer-Werte und auch den MTU-Wert noch etwas angepasst habe (interne Tests brachten mich zu dem Schluss, dass diese Werte zumindest bei meinem Anschluss die besten Praxiswerte liefern).

Code Select Expand


sndbuf 44000
rcvbuf 44000
push "sndbuf 44000"
push "rcvbuf 44000"
link-mtu 1360


Komprimierung habe ich deaktiviert, cipher ist AES-128-CBC, auth SHA1. Und statt des UDP-Standardports 1194 benutze ich aktuell UDP Port 43210. Wobei der Port wahrscheinlich keinen Unterschied macht (wollte da nur prüfen, ob mein ISP eventuell Traffic-Shaping oder so etwas auf dem Standard-OpenVPN-Port macht).

Aus sicherheitstechnischer Sicht sollte das ja wahrscheinlich auch wumpe sein, ob ich nun wieder zurück auf Standard-UDP-Port 1194 gehe oder es bei UDP-Port 43210 belasse, oder?

In jedem Fall wie immer vielen Dank Euch allen für die tolle Unterstützung.

Ich teste so etwas eigentlich immer mittels iperf (iperf 3.6), da viele Online-Tests ja doch eher ungenau sind ...

speedof.me und der Zack-Speedtest von AVM liefern meiner Erfahrung nach noch die verlässlichsten Ergebnisse.

Sollte ich es nicht per iperf testen? Gibt es etwas Besseres?

Proxy oder so ist nicht aktiv, Neustart ändert auch nichts.

Es sind ganz normale Dienste aktiv:

Code Select Expand

configd System Configuration Daemon
dhcpd DHCPv4 Server
dyndns Dynamic DNS
login Users and Groups
ntpd Network Time Daemon
openssh Secure Shell Daemon
openvpn OpenVPN server: OpenVPN-UDP-1194
pf Packet Filter
syslog Syslog
unbound Unbound DNS

Die Last der CPU ist sehr gering ohne VPN-Verbindung. Wie es diesbezüglich mit aktiver OpenVPN-Verbindung aussieht, schaue ich noch einmal, sobald ich das per Glasfaser von außen teste (wird erst kommende Woche werden).

Bin schon am überlegen, den OpenVPN-Server, die VPN-User, die entsprechenden certs der CA und auch die Firewall-Regeln noch einmal komplett platt zu machen. Ob das was bringt?

Oder sogar ein weiteres mal OPNsense komplett frisch installieren? Also sogar ohne Config-Import?

Und dann würde ich mir vielleicht auch noch einmal dieses sehr ausführliche Tutorial zu Rate ziehen:

https://arstechnica.com/gadgets/2017/05/how-to-build-your-own-vpn-if-youre-rightfully-wary-of-commercial-options/

Viel schöner wäre es natürlich, wenn man die Ursache für diese doch sehr langsamen OpenVPN-Verbindungen finden könnte. Aber ehrlich gesagt bin ich hier mit meinem Latein am Ende – und auch von Eurer Seite her scheint ja prinzipiell alles i.O. zu sein mit meiner Config ...

Dass ich den LibreSSL- statt OpenSSL-Build nutze sollte ja kein Problem sein eigentlich, oder?

Das einzige, was mir noch eingefallen war als mögliche Erklärung: Wenn mein Anschluss auf dem Papier sowieso nur schlappe 12 MBit/s im Upload bietet und das in der Praxis sich eher im Bereich von 6-9 MBit/s abspielt – sind die mageren Durchsatz-Werte dann vielleicht doch gar nicht sooooo ungewöhnlich?

Code Select Expand

dmesg | grep -i aes

Features2=0x3ed8220b<SSE3,PCLMULQDQ,MON,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C>
aesni0: <AES-CBC,AES-XTS,AES-GCM,AES-ICM> on motherboard

kldstat | grep -i aes

45    1 0x0 7298     aesni.ko

kldload aesni

kldload: can't load aesni: module already loaded or in kernel

Klingt eigentlich auch erst einmal gut soweit, oder?

@Reiter der OPNsense: Ok, da ist unter Hardware acceleration "AES-NI CPU-based Acceleration ()aesni" aktiviert bei mir.

Dass ich es dann beim OpenVPN-Server trotzdem nicht explizit anwählen kann und dort nur "Hardware Crypto" ... "No Hardware Crypto Acceleration" angezeigt wird, scheint also normal zu sein?

Vielen Dank schon mal für Eure Beiträge soweit.

Bei "Hardware Crypto" steht bei mir leider nur "No Hardware Crypto Acceleration" ...

Hatte aber an anderer Stelle gelesen, dass das wohl trotzdem (automatisch?) aktiv sein sollte normalerweise?

Kann ich wahrscheinlich per SSH auf der OPNsense prüfen?

WireGuard https://www.wireguard.com/ klingt wirklich sehr gut, nur ist das ja leider nach wie vor nicht finalisiert. Ist es denn geplant, das zukünftig auch in OPNsense zu implementieren?

PS: Werde es demnächst mal an einer echten 500er Glasfaser testen, das macht natürlich mehr Sinn als LTE.

[Vielen Dank für Hilfe und input.]

Hallo,

grundsätzlich funktioniert die Verbindung zum OpenVPN-Server gut und zuverlässig, soweit alles prima.

Nur die Geschwindigkeit macht mich wirklich stutzig – bei einem Kabel-Anschluss mit 400 MBit/s Down und 12 MBit/s Up (netto sind es eher 250 bis 380 MBit/s Down und 6 bis 9 MBit/s Up, je nach Zeit) komme ich nur auf folgende Werte, sobald die VPN-Verbindung steht (getestet per LTE-Hotspot mit knapp 150 MBit/s):

Download: 2,9 MBit/s
Upload: 4,1 MBit/s

Habe schon einiges gelesen (und auch versucht) – bisher leider keine Besserung ...  :-[

Encryption algorithm: umgestellt von AES-256-CBC (256 bit key, 128 bit block) auf AES-128-CBC (128 bit key, 128 bit block)
Auth Digest Algorithm: umgestellt von SHA512 (512-bit) auf SHA1 (160-bit)
DH Parameters Length: 2048 Bit (das sollte ja i.O. sein)

Im 'Advanced Bereich" habe ich zusätzlich zum Test noch folgendes eingetragen:

Code Select Expand

sndbuf 393216
rcvbuf 393216

push "sndbuf 393216"
push "rcvbuf 393216"

tun-mtu 1400

Aber auch das ändert erst einmal nichts bei meinem Setup vom Speed her.

OPNsense-Version: OPNsense 19.1.2-amd64, FreeBSD 11.2-RELEASE-p9-HBSD, LibreSSL 2.8.3
CPU: AMD GX-416RA SOC (4 cores)

Was mache ich falsch? Ist einfach nur der SOC zu lahm? Brauche ich für ordentlich Speed einen Xeon?  ;)

PS: Mir ist klar, dass bei meinem Anschluss maximal 6 bis 9 MBit/s drin wären, aber davon schaffe ich ja aktuell gerade mal die Hälfte ... irgendwo ist da doch der Wurm drin, oder?

Wie immer: Vielen Dank für Hilfe und input.

Da ich vermutlich nicht der Einzige mit dem Problem sein werde, anbei mal eine Übersicht über die nötigen Schritte (ausgeführt unter macOS), hoffe das hilft dem einen oder anderen ...

Hier holt man sich das aktuelle Image: https://opnsense.org/download/

Dann vergleicht man die Prüfsumme – auf der Webseite steht z.B.:

OPNsense-19.1-OpenSSL-serial-amd64.img.bz2 (SHA256) : c71274cea2b910cd4b3454b4ad29f7f70503fcb52ffa5b7f65ea96a27ac9e10d

Per Terminal kann man das folgendermaßen prüfen (den User- bzw. Download-Pfad müsst ihr natürlich entsprechend eures Systems anpassen):

Code Select Expand

openssl dgst -sha256 /Users/marcel/Downloads/OPNsense-19.1-OpenSSL-serial-amd64.img.bz2
SHA256(/Users/marcel/Downloads/OPNsense-19.1-OpenSSL-serial-amd64.img.bz2)= c71274cea2b910cd4b3454b4ad29f7f70503fcb52ffa5b7f65ea96a27ac9e10d

Die Prüfsummen sollten übereinstimmen, also so wie hier im Beispiel zu sehen.

Dann bereitet man einen USB-Stick vor, habe hier einen FAT32-Stick mit ,,Master Boot Record" Partitions-Schema per Festplattendienstprogramm erstellt. Im Terminal zeigt man sämtliche Laufwerke folgendermaßen an:

Code Select Expand

diskutil list

Interessant ist das externe Laufwerk (das ist der 16 GB USB-Stick) und dessen IDENTIFIER (disk2):

Code Select Expand

/dev/disk2 (external, physical):
   #: TYPE NAME                    SIZE         IDENTIFIER
   0: FDisk_partition_scheme       *15.8 GB     disk2
   1:  DOS_FAT_32 FAT              15.8 GB      disk2s1

Dann in das Download-Verzeichnis wechseln:

Code Select Expand

cd /Users/marcel/Downloads/

Und das komprimierte Image entpacken:

Code Select Expand

bzip2 -d OPNsense-19.1-OpenSSL-serial-amd64.img.bz2

Nun den USB-Stick vom System abmelden:

Code Select Expand

diskutil unmountDisk /dev/disk2

Und per dd das Image auf den Stick kopieren:

Code Select Expand

dd if=OPNsense-19.1-OpenSSL-serial-amd64.img of=/dev/disk2 bs=64k

ACHTUNG: Das dauert eine ganze Weile (knapp eine Viertelstunde), das entpackte Serial-Image ist immerhin 1,13 GB groß.

Bei dd sieht man leider keinen Fortschrittsbalken oder eine Prozent-Anzeige, am Ende wird einem dann etwas in der Art ausgegeben:

Code Select Expand

17232+0 records in
17232+0 records out
1129316352 bytes transferred in 944.175746 secs (1196087 bytes/sec)

Das war erst einmal die Anleitung zur Erstellung des OPNsense-Sticks, die Vorgehensweise für den Router folgt.

Ok, danke für den Hinweis.

Ursprünglich war da tatsächlich mal 16.x drauf, von daher werde ich um eine komplette Neuinstallation wohl nicht herum kommen ...  :-\

Die Config habe ich schon exportiert, dann werde ich mal einen 19.x Stick vorbereiten ...

Hallo,

wollte soeben von OPNsense 18.7.10 auf 19.1 upgraden – leider schlägt das fehl, da die Disk schon recht voll ist:

61% / [ufs] (1.0G/1.8G)

Das Upgrade startet zwar, aber scheinbar werden mehr als 800 MB benötigt/geladen? Kann das sein?

Es kam dann jedenfalls immer die Meldung "write to restore size failed" und UFS war laut GUI mit 108% befüllt ...

Habe mich dann erst einmal per SSH eingeloggt und genauer geschaut.

Code Select Expand

df -T

Filesystem          Type  1K-blocks    Used   Avail Capacity  Mounted on
/dev/ufs/OPNsense0  ufs     1895054 1882235 -138785   108%    /
devfs               devfs         1       1       0   100%    /dev
tmpfs               tmpfs   2263248   15292 2247956     1%    /var
tmpfs               tmpfs   2248788     832 2247956     0%    /tmp
devfs               devfs         1       1       0   100%    /var/unbound/dev
devfs               devfs         1       1       0   100%    /var/dhcpd/dev

Außerdem noch so:

Code Select Expand

du -mah | sort -rh | head -n 20
1.8G .
805M ./root/var
805M ./root
794M ./root/var/cache/opnsense-update
794M ./root/var/cache
777M ./usr
578M ./root/var/cache/opnsense-update/18247
472M ./root/var/cache/opnsense-update/18247/packages-19.1-OpenSSL-amd64.tar
426M ./usr/local
285M ./usr/local/lib
216M ./root/var/cache/opnsense-update/.sets.pending/packages-19.1
216M ./root/var/cache/opnsense-update/.sets.pending
216M ./boot
215M ./root/var/cache/opnsense-update/.sets.pending/packages-19.1/All
171M ./usr/bin
124M ./usr/local/lib/python2.7
107M ./boot/kernel.old
107M ./boot/kernel
81M ./usr/share
79M ./root/var/cache/opnsense-update/18247/base-19.1-amd64.txz

Ein beherztes

Code Select Expand

rm -Rf /root/var/cache/opnsense-update* half jetzt zwar erst einmal, d.h. aktuell sind wieder nur 61% voll laut GUI (1.0G/1.8G) und 18.7.10 ist zum Glück immer noch aktiv.

Aber wie komme ich jetzt zum 19.1 Upgrade, ohne dass wieder die Fehlermeldung "write to restore size failed" auftaucht?

Wahrscheinlich muss ich mir einen Install-Stick mit 19.1 anfertigen und das Upgrade dann davon starten?

Oder gäbe es doch noch eine einfachere Möglichkeit?

Danke für Eure Hilfe!  :)

[Dazu muss ich sagen, das hatte schon mal problemlos geklappt in der Vergangenheit!]

Hallo,

leider muss ich bei meinem OpenVPN-Server als DNS-Adressen zusätzlich mind. 1.1.1.1 (oder auch 8.8.8.8 und/oder 9.9.9.9) eintragen, damit ich per OpenVPN und iPhone unterwegs online komme.

Lasse ich diese DNS-Server weg und trage dort nur den DNS-Server meines IPv4-Tunnelnetzwerks 10.1.2.0/24 ein, also 10.1.2.1, kann ich keine Seiten mehr ansurfen.

Und deshalb funktioniert nun leider auch nicht mehr der Werbeblocker (per Unbound DNS) von unterwegs aus – das war für mich eigentlich der Sinn bei der Sache (speziell beim iPhone).

Der Router selbst ist unter der 192.168.1.1 erreichbar, nutze zu Hause also ein 192.168.1.0/24.

Dazu muss ich sagen, das hatte schon mal problemlos geklappt in der Vergangenheit!

Normalerweise sollte doch die 10.1.2.1 als DNS-Adresse ausreichen?

Als Anleitung hatte ich damals dies hier benutzt:

https://www.sparklabs.com/support/kb/article/setting-up-an-openvpn-server-with-opnsense-and-viscosity/

Danke für Unterstützung & beste Grüße,
Marcel

[Any idea how to check what's going wrong here?]

@elektroinside: Thank you for this nice guide. Followed it step by step.

Unfortunately, I still can download the Eicar Test Virus from https://www.wicar.org/test-malware.html without any problem.

So my IDS/IPS isn't working as it should, right?

Any idea how to check what's going wrong here?

PS: My client computer has a manual IP and the DNS server is the same as the Gateway. Also your Firewall rule is added to avoid DNS overrides from client side. And all rulesets are activated as recommended, so the download speed is not over 100 MBit now (without Suricata I have nearly 400 MBit normally). It seems to be "on" but I still can download the Eicar Test Virus? Why? That's strange ...

Ok, Thema hat sich erledigt – das schnellste (und vermutlich einfachste) war jetzt:

1) APU2C2 aufschrauben und SDCard entnehmen.
2) Das Nano-Image auf die SDCard kopieren per:

Code Select Expand

dd if=OPNsense-18.7-OpenSSL-nano-amd64.img of=/dev/disk3 bs=64

So klappte wieder das booten, auch der Einrichtungs-Wizard startete beim ersten Web-Login.

Danach das Gerät ausschalten und zum Test auch noch ein zweites mal booten hat auch problemlos geklappt.

Jetzt sollte also alles i.O. sein erst einmal hoffe ich.