Ich habe deine beschriebenen Einstellungen vorgenommen. Funktioniert nun. Vielen Dank für deine Hilfe, @NOCling

@megbyte0469 said in Pfsense 2.6.0 letzte Version, Installation Mini PC mit einen Ethernet Port: Ist das ein Bug oder fehlt noch was in der Konfiguration ?! Hast du mittlerweile eine Lösung gefunden?

@greeneyedandy Ahso, das sollte ja kein großes Problem sein? Ich habe hier halt den Vorteil, dass ich das selbe Gerät, welches ich jetzt hinter der Firewall nutze, davor vor der Firewall genutzt habe und so die meisten Einstellungen halt eh noch richtig gesetzt sind, was Telefonie betrifft. Habe jetzt deinen Setup nicht mehr im Kopf, aber vielleicht kann es ja auch auf dich zutreffen.

@herry2 said in Externe IP bzw. Port über einen VPN auf eine Interne IP Umleiten: Hi, Ok sollte man wohl angeben, es ist ein OpenVPN und wird nur für diese Verbindung benötigt. Peer to Peer (Shared Key) tun - Layer 3 Tunnel Mode Mfg Heribert Nochmal da die Frage ignoriert wurde: Ist das ein VPN Tunnel der dafür gedacht / erlaubt ist, dass die IP weitergeleitet wird und bei welchem die IP überhaupt auch geforwarded wird? Und wie wird sie das? Oder kontrollierst du beide Enden und auf der Seite mit der öffentlichen IP steht auch ne Sense? Was ist da konfiguriert? Nur weil du über den Tunnel raus kommst, heißt das ja nicht das eingehend das gleiche einfach so schnippidiwipp funktioniert :) Darum bitte mal eine Aussage dazu, was das überhaupt für ein Tunnel ist (ja OVPN Shared Key ist jetzt klar) und ob es überhaupt sinnvoll möglich ist den eingehend zu benutzen. Sonst kommt da überhaupt kein Traffic für dich an und alles weitere was man ggf. auf der pfSense einstellen kann ist schlicht unnötig wenn nie Traffic ankommt. Cheers \jens

@bob-dig Ja, weil es mir effektiv nichts bringt mit "einer einzigen" IPv6 draußen unterwegs zu sein. Wenn ich alle dutzende Devices intern auf eine einzelne IPv6 ausgehend mappe, habe ich dadurch genau nichts gewonnen außer dass ich doppelte Buchführung machen darf und jede Regel zweimal abklopfen muss, ob sie mit IPv4/6 sauber funktioniert und auch alles korrekt ist. Alle Vorteile von IPv6 für mich verschwinden und nur die Nachteile mit IPv4 bleiben. Hab ich nicht wirklich nutzen dann davon.

@nowa-it Dein Thread wird natürlich immer in dem Topic/Unterforum erstellt, indem du auf "Erstellen" drückst. Das ist aber hier der deutschsprachige Bereich und da schaut auch kaum jemand auf englisch rein, daher macht der Thread hier dann auf englisch keinen gesteigerten Sinn. Ich lass den mal in den englischen General oder IPv6 Bereich verschieben, so macht es keinen Sinn bezüglich Sichtbarkeit und dann können dir ggf. auch andere englischsprachige Teilnehmer helfen, die das dort sehen.

ok, danke Euch. Ich werde mir mal den Vigor 167 bestellen. Gruß, Arti.

Hallo, habe einige Tests durchgeführt. Die Lösung des Problems scheint wirklich das Deaktivieren der sequentiellen Abfrage (Standard) der DNS Server 8.8.8.8 und 8.8.4.4. Bis zur Version 2.5.2 gab es hier aber keine Probleme. Nun gut, die parallele Abfrage scheint zu funktionieren. Gruß Peter

@toskium Wenn hier nichts bei rauskommt, kannst Du mit dem cron-package einen täglichen reboot des nachts einrichten.

So. Hatte die Sense wie zuvor erwähnt ganz frisch mit einer 2.6.0 vom Stick beglückt und gleich die SSD mit zfs behandelt. Alles frisch installiert und konfiguriert. Was soll ich sagen, bisher läuft das ohne zu Murren und ohne DNS Schluckauf. Auch das VPN-Gate ist wieder aktiv inzwischen.

@thiasaef Vielen Dank, hat funktioniert!

Hallo, Fehler gefunden. Nachdem ich gelogt habe, was ging und diese geprüft habe, konnte ich keinen Fehler feststelle. Höchstens Timeout am Client und Mar 26 18:31:40 openvpn 34260 1.2.3.4:51606 SIGUSR1[soft,tls-error] received, client-instance restarting Mar 26 18:31:40 openvpn 34260 1.2.3.4:51606 TLS Error: TLS handshake failed Mar 26 18:31:40 openvpn 34260 1.2.3.4:51606 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Mar 26 18:31:31 openvpn 34260 1.2.3.4:22613 SIGUSR1[soft,tls-error] received, client-instance restarting an der genüberliegenden pfsense. Per Komissar-Zufall wollte ich per threema einen Anrufen führen, der auch ins leere lief und das war der Hinweis. https://forum.netgate.com/topic/169879/udp-icmp-is-not-working-after-upgrade-to-2-6-0 Sorry wenn ich hier Verwirrung gestiftet habe... -Solved-

@thiasaef said in Bufferbloat Fix mit WAN und VPN-Gateway Group: Aber jetzt, wo ich noch mal darüber nachdenke, fällt mir auf, dass man das Problem eventuell dadurch lösen könnte, dass man von vorneherein zwei VPN Tunnel (einen über DSL und einen über LTE) aufbaut und eine Gatewaygroup (mit Failover) darüber anlegt. @JeGr, die Idee funktioniert mit WireGuard übrigens auch nicht ohne Weiteres, siehe: https://forum.netgate.com/topic/170725/forcing-wg-to-use-an-specific-wan-interface-to-build-the-tunnel

MTU und MSS auch Default Mir ging es bei der Umsetzung nicht um den Speed welchen der Adapter unterstützt sondern ich wollte eine pfSense mit der alten Apple Hardware umsetzen. Das hat zumindest funktioniert. Und ja es gibt Gegner von solchen Aktionen und auch Fürsprecher (scheinbar Geschmackssache) Selbst wenn der Adapter hohe Geschwindigkeiten unterstützt krankt es dann ja später am Apfel selber. Mal sehen was das wird wenn bald (in 4 Monaten) Glasfaser kommt.

@bob-dig said in [solved] Telekom pppoe IPv6 geht nich?: bei den Zugangsdaten kann man irgendwas eintragen Liegt am standardmäßig aktivierten Easy Login.

@nocling Wobei das VLAN 7 nur auf der Fritzbox konfiguriert ist. Also spricht wohl nix dagegen.

@nocling said in Outgoing RFC1918 blocken aber 192.168.1.1 zulassen: Aber baut ruhig so Umleitungen ein Es geht doch hier um Verbindungen, die aus dem LAN Netz heraus in ein WAN seitiges RFC1918 Netz aufgebaut werden und nicht um den umgekehrten Fall. Welche Rolle soll da bitte der Haken bei Block private networks and loopback addresses auf dem WAN Interface spielen? Statt sich mit Floating Regeln ins Knie zu schießen, wäre es vielleicht sinnvoller, bei den Pass Regeln auf den jeweiligen LAN Netzwerken (HERDE, GAST, IOT) einfach mit Destination = !RFC1918 zu arbeiten und Zugriffe auf 192.168.1.1 nur vom (Management) LAN aus zu erlauben. Ich sag nur KISS.

@scxma said in externe mDNS Request nach Update auf 2.6.0: Ich habe jetzt sogar Netscans von der Firewall auf andere Ports. Kann es sein, dass meine Firewall während des Updates kompromittiert wurde? Kann ich mir, ehrlich gesagt, schwer vorstellen. Dennoch hätte mich die Ratlosigkeit an deiner Stelle schon zu einer Neuinstallation bewegt. Das Ganze sieht doch sehr suspekt aus. @nocling said in externe mDNS Request nach Update auf 2.6.0: Wenn es von der WAN IP der Sense ausgeht, kann es auch ein System dahinter sein was per NAT auf die WAN IP der Sense umgesetzt wird. Das passt jedenfalls für die mDNS Pakete nicht zu dem Log Eintrag "let out anything from firewall host itself". @scxma Zumindest Port 22 könntest du ja noch blockieren, wenn du weiter forschen möchtest, und überprüfen, ob hier ebenfalls die Firewall selbst die Quelle ist. Eine Erklärung für dieses Phänomen fällt mir aber nicht ein.

@jegr said in weieter Schutzmaßnahmen. Login-Versuche, IDS?: Extern nicht Port 22, sondern ggf. sowas wie 8022 oder 4022 o.ä. nutzen. Im Gegensatz zu "RDP o.ä. auf fremden Ports verstecken" ist das in dem Fall kein Security through Obscurity - es geht nicht um das stumpfe Verstecken des Ports in der Hoffnung dass es keiner findet - sondern darum die Standard Scanner, Bots und Trojaner die alle via tcp/22 rumkreiseln abzufischen. Ok, klingt logisch. Je mehr ich darüber nachdenke - was ja oft hilft - desto klarer wird mir dass ich SSH eigentlich nicht benötige. Ich bin in 99,99999% der Fälle mit einem meiner Linux-Laptops unterwegs und darauf ist die OpenVPN-Verbindung eingerichtet. Ich lasse 22 einfach zu. @jegr said in weieter Schutzmaßnahmen. Login-Versuche, IDS?: Sinnvoll bei egal welchem VPN wäre saubere User-Auth. Und das eher nicht mit dem integrierten Local UserDB, sondern schöner mit bspw. dem FreeRadius Package. Dann packt man die User, die sich per VPN anmelden dürfen via FreeRadius3 ins System Das werde ich mir definitiv anschauen. Das mit dem Radius-Server habe ich schon oft gelesen. Im Moment habe ich pfSense an den im LAN vorhanden ADS/LDAP angebunden. @jegr said in weieter Schutzmaßnahmen. Login-Versuche, IDS?: und schon kann man nicht "aus Versehen" einen User anlegen der Zugriff auf die Firewall/Dashboard hat. Geht recht flott das sowas passiert Das passiert mit an Sicherheit grenzender Wahrscheinlichkeit hier nicht. Wenn ich irgend etwas teste habe ich fast die gesamte Umgebung innerhalb einer virtuellen Umgebung lokal auf einem Rechner. @jegr said in weieter Schutzmaßnahmen. Login-Versuche, IDS?: Da bin ich gerade nicht up2date aber IMHO konnte das nach letztem Stand IPsec nicht auswerten. Selbst wenn doch - da will ich nichts unterstellen - halte ich IPsec für Client VPN für die denkbar schlechtere Wahl. Unflexibel, störrisch einzurichten gerade in hybriden Umgebungen, die nicht "nur Windows" o.ä. sind, Debugging und Fehlersuche sind ein Albtraum - sorry keine 10 Pferde bringen mich dazu ;) Das kann ich technisch nicht beurteilen aber bei OpenVPN will ich bleiben. Das nutze ich schon lange und funktioniert hier auf allen Plattformen (Linux, Windows, Apfel) ohne Probleme. @jegr said in weieter Schutzmaßnahmen. Login-Versuche, IDS?: Zusätzlich zu User-Auth per Radius würde ich noch Zertifikate mit rein nehmen und den Server+Clients mit Zertifikaten bespaßen. Wer dann noch eins draufsetzen will kann sein FreeRadius Password ersetzen durch PIN+TOTP mit ner App oder nem TOTP Token Generator, das kann man in FreeRadius auch recht einfach einrichten. Das werde ich mir anschauen. Gerade bei den Zertifikaten habe ich noch beträchtliche Wissenslücken :-( Ich kann mich nur ein weiteres mal für deine ausführliche Erläuterung bedanken!!!!! Beste Grüße und ein schönes Wochenende