@JeGr said in [solved] Traffic Shaper: LAN seitig mit einem Mix aus physikalischen und VLAN Interfaces: Gern hier verlinken, dann leg ich mir das auf Beobachtung, das interessiert mich auch :) Klar, hier.

@esquire1968-0 said in pfSense als DynDNS Server: Gibt es eine Möglichkeit, die pfSense als DynDNS Server zu verwenden? Inwiefern Server?

Guten Morgen und danke für die Rückmeldung. Wie du erwähnt hast, habe ich ein privates Metz zwischen FB und pfSense. Den Haken auf der WAN-Schnittstelle für das Blocken von privaten Netzen habe ich raus genommen. Daher verstehe ich nicht, warum das nicht durch die FB durch geht. Weitere Portforwarding-Regeln in der FB zur pfSense (z.B. auf das Kunden-NAS) funktionieren einwandfrei. Bei dem LOG für die pfsense hatte ich auf dem WAN-Interface nur den OpenVPN-Port angegeben. Das ist alles, was dort steht. Gruß singer

@tpf said in IPv6-Adressen erneuern?: Korrekt Das ist immer Providerabhängig, bei mir "darf" es wohl dran bzw. habe keine Probleme damit, manche wollen aber nur das Prefix weitergeben und machen das Routing über die fe80 LinkLocal Adressen, das ist dann auch nicht außergewöhnlich :) Dass das WAN seine v6 IP auf Basis seiner MAC erhählt, also keine PE, ist gewünscht, nehme ich an Das ist m.W. die normale/alte Implementation vom RFC dass an Hand der MAC Adresse die ID auswürfelt. Inzwischen gibts aber noch ein neueres RFC was das Generieren anders ohne MAC implementiert, das ist aber IMHO in FreeBSD noch nicht enthalten wenn ich mich recht erinnere. Somit: Ja ist (noch) normal so, sollte sich ggf. zukünftig ändern um Rückschlüsse via MAC zu minimieren. Gruß

@JeGr said in externe IP bei 2 x DSL + LTE Backup: Aber gerade wenn ihr Mail ins Haus sendet, solltet ihr da MX und Mailgateway checken, da reicht das kleinste Ärgernis schon und eure Mails werden zukünftig gerne mal als Spam geflaggt. Leider alles schon gehabt :/ Mails kommen direkt auf unsere per MX hinterlegte IP. Senden geht immer über den Hoster als Relay. Ich hatte das Vergnügen schon mal, eine Domain bzw IP von mehreren DNSBL-Listen und den Listen von Antiviren-Herstellern wieder raus zu bekommen - macht keinen Spaß und ist langwierig. Gemeint ist einfach, dass DynDNS für einen anderen Anwendungsfall konzipiert wurde, weil alleine TTLs Caching von Domainnamen etc. etc. nicht dafür ausgelegt sind einen schnellen und sauberen Failover zu garantieren. Darum gehts mir dabei :) So schnell muss das auch nicht sein. Selbst wenn das 30 Minuten dauern würde, wäre das in Ordnung für uns. Hab das jetzt mehrere Male getestet. Alle von mir getesteten externen DNS-Server lösen den Domainnamen innerhalb weniger Sekunden korrekt auf. Caching ist dann natürlich ne andere Sache.

@DaLeberkasPepi said in Probleme mit PIA VPN: Macht es irgend einen Sinn AES-NI und BSD Crypto zu aktivieren oder ist BSD-Crypto eher nur eine Art Fallback Auswahl? Jein. BSD Cryptodev sollte IMHO inzwischen nicht mehr benötigt werden - soweit ich weiß und ohne Gewähr was zukünftige Versionen angeht. AES-NI zu aktivieren (unter adv. Options) lädt das entsprechende Kernel Modul und AES-NI erscheint in der Auswahl (und auf dem Dashboard unter Crypto). Das Kernelmodul ist aber im Prinzip meist nur nötig, wenn man IPSEC VPNs benutzt. Da OVPN im Userspace läuft, nicht im Kernel, wickelt OVPN das alles über die OpenSSL Bibliothek ab, die selbst Wege hat zu erkennen, ob das System AES unterstützt oder nicht -> daher nichts auswählen. Das ist bislang soweit ich weiß das "schnellste" Setting. Wobei wirklich ins Gewicht fällt das nur, wenn man anfängt Linespeed in höheren Geschwindigkeiten erreichen zu wollen, 100, 200, 300Mbps+ Bei den meisten Einwahl-Geschichten geht es nicht unbedingt um 4h Dauertransfer à 100Mbps Max ;)

(Behelfs-) Lösung: komplette Neuinstallation der pfSense und Suricata läuft nun im Legacy-Blocking Mode, statt Inline-IPS.

Hallo, evtl hast du das Problem inzwischen schon gelöst. Aber falls nicht und für alle die bei einer Suche darauf stoßen: Nicht selten ist die Ursache der Browser-Cache. Daher einfach mal den Cache des Browsers löschen und Browser neu starten und dann nochmal versuchen. Klingt banal, wird aber oft vergessen. Ximix

Hallo, Sehe eventuell: --pull-filter accept|ignore|reject text im manual 2.4 https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage

Hallo, kann es sein du hast das gleiche Problem wie hier: forum.netgate.com/topic/144621/pfblockerng-und-ie11-ca_dnslb ? Grüße

Erstmal vielen lieben Dank für deine Mühe diese Wand aus Text zu lesen, dich damit zu befassen und auch noch so umfassend drauf zu antworten. Das was du in Bezug auf NAT geschrieben hast hilft mir schon mal einiges weiter. Ich lass es grad noch so wie ich es zuletzt eingestellt hab, es wird noch selektiv getestet. Das nächste wäre dann an dieser Schraube rumzudrehen oder s.u. . Log auf der pfSense habe ich mich mit befasst, ist halt nur eine Seite. Das parallel an den Testclients oder über ein MITM Device zu fahren hatte ich noch nicht gemacht, wird aber werden müssen wenn wir die ursächlichen Probleme erkennen wollen. Alles Aufwand, wollte ich vermeiden wenn geht, trägt u.U. nicht zur Lösung bei wenn die Konstellation bleibt wie sie ist, man würde evtl. nur erfahren warum es nicht funktioniert. An dem Windows Server (kein ISA, auch deswegen und weil alt: Rauswurf) war nichts spezielles eingerichtet. Den hab ich noch da und kann den auch so starten, hab das mehrfach kontrolliert - nichts besonderes gefunden. Auch wenn mir das die liebste Lösung wäre: wir können dem Kunden und dem TS Dienstleister - der doch einiges größer ist und mit dem TS und der Software darauf deutschlandweit operiert - im Moment schlecht verklingeln dass wir - die wir nachträglich dazugekommen sind - mal eben sagen und vorschreiben wie der VPN Tunnel aufgebaut wird. Da geht erstmal kein Weg rein. Da kommt dann auch der Spruch 'das ging bisher ja auch' und 'andere machen das auch' usw. . Müssen wir wohl absehbar mit leben. Die von dir angesprochene Alternative - die mir sehr gefällt - den Cisco umzukonfigurieren so dass der in eine DMZ kommt - sprich einfach ein anderes LAN Segment und eine weitere Zielroute zuzuweisen - wird für die 'einfach zu aufwändig', hatten wir schon kurz angesprochen, wollen die nicht mal eben so machen. Die Alternative wäre das primäre Netzwerk umzukonfigurieren aber auch das steht im Moment in keinem Verhältnis, da sind wir länger beschäftigt. Da ist sehr viel zu beachten, da laufen an dem einen Standort x Server und xx Diagnosegeräte, wird wohl eher nicht passieren. Wenn sich das Problem weiterhin manifestiert werde ich den Kunden so richtig gut überzeugen müssen (Argument ASA Updates und Pflege, weiss kein Mensch hier) und mit dem Kunden zusammen dem Dienstleister die Pistole auf die Brust setzen dass der die Cisco entspr. umkonfiguriert. Das ist einer der letzten Wege, erfordert Überzeugungsarbeit, wäre aber eine saubere Lösung. Das mit dem Routing der Druckjobs in das Kundennetz lässt sich auch lösen, müssen die an der ASA machen. Aktuell läuft es zeitweilig unter Beobachtung mit einem Testclient. Falls das dennoch bleibt ist der nächste Schritt mehr Dumps zu erzeugen und damit das Problem einzukreisen sofern es bleibt. Danach läuft es auf Überzeugung des Kunden und Druck auf den TS Dienstleister hinaus. Danke für deine Hilfe, ich bleibe dran, das Thema ist noch nicht durch weil wir das noch testen lassen. Grüße

Moin. Dafür ist die Sense nicht gedacht. Über den Traffic Graph lässt sich was darstellen, nur keine Statistiken. Mit einem Limiter den Download auf 30 Mbit/s festnageln, da bist Du auf der sicheren Seite. Das ist hier gut dokumentiert. Und Traffic Shaper einzurichten ist kein Hexenwerk.

@tpf said in [solved] Site to Site VPN - IPSec oder OpenVPN: Ich darf mich bei Euch bedanken ;-) Anscheinend hat sich in der Zwischenzeit Etwas weiterentwickelt. Statt SHA1 geht nun SHA512. Irgendwann schaue ich mal nach, was neuerdings sonst noch so geht.[image: 1561743915645-fritteipsec.jpg] Gerade heute wieder mit einer 7390 auf die Nase gefallen und festgestellt, dass AVM seine Doku aufgebohrt hat: https://avm.de/service/fritzbox/fritzbox-7390/wissensdatenbank/publication/show/3331_FRITZ-Box-mit-einem-Firmen-VPN-verbinden/ In der URL einfach die Modellbezeichnung zw. /fritzbox/ und /wissensdatenbank/ editieren. Die Modelle, die ich jetzt versucht habe, sind allesamt dokumentiert. Da findet man die möglichen Einstellungen.

Danke, Männer! Bzgl. der Custom-Konfig: manchmal sieht man den Wald vor lauter Bäumen nicht kopfklatsch. Ich habe das vor zig Jahren mal gemacht und musste damals noch händisch in einer Konfig via SSH wurschteln. An sich gefällt mir das mit OSPF, hatte das auch mal in der Doku gelesen. Ich glaube, ich werde das mal ausprobieren. Für den Moment dann mit der zweiten IP.

War auch spaßig gemeint ;) Und nicht vergessen, dass man auch Separatoren einfügen kann (4 Farben, beliebiger Text) um das entsprechend zu organisieren und besser verständlich zu machen

Dir ist schon klar, dass pfSense kein Linux ist, es ergo kein Netfilter (sondern PF) und daher kaum ein nf_conntrack gibt? Bei FTP, ich glaube in der passiven Verbindung gibt es da bezüglich NAT auch immer Schwierigkeiten, das das FTP Plugin für pfSense auch nicht alles abdeckt Du hast gelesen, dass das FTP Modul für pfSense (das neue) für aktives FTP ist und als Mini-Proxy einspringt, damit man eingehend Port 20 nicht von der ganzen Welt öffnen muss? Und du hast gelesen, wie es konfiguriert sein muss, damit es sauber funktioniert? Auch bei SIP-DirectMedia ist es nur möglich, wenn man eine sehr große Port-Range auf macht, das lässt sich mit solchen Modulen eigentlich verhindern... Lässt es sich auch indem man seinen Provider nach Details fragt und nur von deren IP Range die Ports öffnet. Wobei SIP ein schlechtes Beispiel ist weil hier wieder jeder seine eigene Suppe kocht. Ergo: nein, es gibt kein nf_conntrack. Was es ansonsten für SIP oder FTP (warum will das noch jemand benutzen?) für Ansätze gibt, hängt auch von der Problemstellung ab. Ich frage mich aber, was conntrack bringen soll, wenn ich mir da gerade SIP in den USA anschaue. Gerade eine Umstellung dort gemacht und SIP Provider gibt IPs 1,2,3 an als Gegenstelle für SIP Ports. Freigegeben, klingelt. Kein Gespräch gehört. Im Log geschaut: angekündigte RTP Ports udp10000-20000 kommen an, aber von einer wildfremden IP die keiner irgendwo zuordnen kann. Auch nicht im SIP Provider Dokument. Nachgehakt: joa könnte unseres sein, vllt. über nen CDN oder so... Im SIP Outbound Paket stand auch diese IP nirgends drin. Wie willst du also so eine Verbindung "tracken" und automatisch irgendwas öffnen? Einfach auf Verdacht ankommenden UDP Highport Traffic einfach reinlassen? Solang Provider so nen Quatsch machen und nicht dokumentieren, wird das leider immer abenteuerlich bleiben ;)

@JeGr said in Konfiguration Netzwerk und pfsense: @paprikawuerzung Ich sage ja nicht, dass die IP nicht stimmt oder das WAN setup. Aber die Fritte im Bridge Modus sollte/hat normalerweise gar keine IP. Soll sich auch gar nicht. Dein Gateway steht normalerweise bei UM/KabelBW und ist die Gegenstelle. Ansonsten wäre das sehr merkwürdig konfiguriert. Sollte aber bspw. ein Traceroute auf der Sense zeigen, ob das GW die Fritte ist oder UM, dann müsste man das an dem ersten Hop und seinem Ping sehen. Ja, vielleicht habe ich das falsch verstanden als der Techniker von UM mir das erklärt hat - kann sehr gut sein. Er hat mich aber auch nicht korrigiert als ich ihm geschildert habe, wie ich denke, dass das alles funktioniert. Davon abgesehen musst du wie im anderen Post schon geschrieben ein paar mehr Details posten damit man was sehen/helfen kann. Ja, ich habe leider nur einen pfSense Router, mit dem ich auch mein (altes, funktionierendes) DSL Internet eingerichtet habe. Ich werde später die Einstellungen wieder auf das Kabel Internet umstellen und dann weiterschauen - gerade brauche ich das funktionierende Internet noch! Aber jetzt schon tausend Dank für deine Antworten. Ist sehr positiv, dass es so eine hilfsbereite Community gibt - hoffentlich kann ich mich bei der Community irgendwann wieder revanchieren :) Ich werde dann im anderen Thread weiter antworten und aufhören, den Post hier zu "spammen"!

Hi, ja den match habe ich nach etwas Überlegung dann auch verstanden. Schade, dass man nicht im blockerng eine CA ausstellen kann, via Lets Encrypt oder self cert die man im lokalen Netz zumindest verteilen und importieren kann. Ich habe dann auch für die Seiten die geblockte Site ausfindig machen können, hier wird via XMLHTTP request die mscom.demdex.net Verindung aufgebaut die vom blockerng in der Yoyo List glaub ich auch zu finden war. Nachdem Whitelist kommt diese Meldung nun nicht mehr. Danke für die Rückmeldung :) VG

@Gladius said in [solved] pfsense OpenVPN hinter Fritzbox 7490: aus heutiger Sicht unsicher und worauf beruht die Unsicherheit? Das "warum" ist etwas sehr ausführlich, da kann man sich IMHO selbst ganz gut anlesen. Die "sicherste" Konfiguration per se gibt es auch nicht, aber es gibt sicherlich sichere(re) Konfigurationen im Gegensatz zu solchen, die Schwächen aufweisen. Was bspw. IPSec angeht sind das Konfigurationen die bspw. DES, 3DES oder auch MD5 bzw. SHA1 benutzen sowie DH Gruppen <=2k RSA einsetzen. Warum? Weil es einfach heute bereits theoretische oder sogar praktische Angriffsszenarien gibt, diese Verschlüsselungen aufzubrechen und somit das "P" in VPN nicht mehr erfüllt sind. Genauso wie man PPTP heute ebenfalls nicht mehr zu VPNs zählen kann. In Kürze gilt das für OVPN auch. Dabei gehts aber nicht nur um Sicherheit aber auch um Abbildbarkeit in Crypto Beschleunigern, weshalb es ggf. eben unsinnig ist, AES-CBF oder -OFB zu nutzen, wenn der Crypto Beschleuniger CBC oder GCM wesentlich stärker beschleunigen kann. Bei Blowfish ist aber mit SWEET32 tatsächlich ein Angriffsvektor bekannt. Auch DES, 3DES und RC4 und Konsorten sind anfällig. Für PerfectForwardSecrecy (PFS) braucht es einen sicheren Schlüsselaustausch (Key Exchange, KEX). Ist der der zu schwach gewählt kann es einem Angreifer gelingen die Sitzung vollständig hinterher aufzudröseln. Daher ist kleiner als 2k (2048) schon länger nicht mehr als genügend anzusehen. Diese Punkte kennt man bspw. auch aus TLS/SSL Zertifikaten und der Zertifikatsgenerierung. Auch hier wird empfohlen mind. 2048bit DH Keys sauber zu erzeugen, die TLS Suite selbst auf min. 1.2 zu setzen und bspw. als Signatur Algorithmus für die Zertifikate SHA-256 zu nutzen, da SHA-1 zu schwach wurde. Genauso auch bei OpenSSH, die kürzlich auch mehrere Schnitte gemacht haben und diverse alte Ciphersuites und Blockcipher ausgemottet haben (Blowfish und alle RC bspw.) und bei denen bspw. inzwischen gar kein RSA Key mehr empfohlen wird (und wenn dann nur mind. 2k besser 4k), sondern ED25519 Keys (elliptische Kurve EC25519). Die Diskussion ist da weniger "Airbus vs. Boeing", sondern eher: Boeing 7x7-400 Frachtklasse hatte mehrfache Fehler im Triebwerk und bleibt "grounded", müssen wir ggf. die 7x7 Passenger auch runterholen und einmotten oder lassen wir die noch weiter rumkurven, obwohl vielleicht weil gleicher/sehr ähnlicher Body/Frame es ein ähnliches Problem geben könnte? Oder gehen wir nicht zur 787 die ganz anders funktioniert und motten den Rest gleich ein? Grüße

BTW gerade heute gepostet worden: https://www.netgate.com/blog/choosing-the-right-netgate-appliance.html