@michael-schumann said in Jede DNS Anfrage mit der gleichen IP beantworten: Ich kenne die Clients nicht und kann denen kein Zertifikat einer CA unterjubeln Ohne ein CA Zertifikat auf den betroffenen Clients installieren zu können, kannst du die Sache gleich bleiben lassen. Die Seite würde dann nicht angezeigt. Du könntest ebenso gut die Zielports 80 und 443 der Clients auf einen eigenen Webserver umleiten. Da könntest du auch Ausnahmen fürs Intranet einbauen. Aber das Problem bleibt dasselbe, HTTPS-Aufrufe, die ein anderes SSL-Zertifikat erwarten lassen, werden nicht angezeigt. Setze eine Reject-Regel, dann bekommt der User die Fehlermeldung, dass die Seite nicht angezeigt werden kann, sofort. Grüße

@NOCling , ja da hast Du recht. Danke.

Hallo zusammen. Ich habe mich bisher mit Reverse Proxy noch so intensiv beschäftigt... An Diensten sind das 2x vpn Server 4 web Services 2 Datei Sharing dazu kommt dass für HTTPS letsencrypt zum Einsatz und bei meinen letzten versuchen mit letsencrypt und Reverse Proxy bun ich immer auf die .. geflogen hab das aber aufgrund ausreichend vorhandener öffenrlicher ips dann immer sehr schnell gelassen ...

@viragomann said in Dynamic DNS aktualisiert die falsche IP Adresse: Das Grün kannst du für das Nicht-Default-WAN mit den Standardeinstellungen vergessen. pfSense schickt einen Request auf http://checkip.dyndns.org und übernimmt die IP aus dem Respond. Diese ist jene, der der Server sieht. Also das Default-WAN. Wenn du das nutzen möchtest, musst du eine statische Route für die IP von checkip.dyndns.org auf das VDSL Gateway setzen. Das ist so nicht richtig. Bei MultiWAN kann absolut korrekt unterschieden werden zwischen den beiden Interfaces. Das klappt im Normalfall auch völlig OK. Ohne irgendwelches Routen-Geklüngel. Wichtig ist das korrekte Interface auszuwählen, dann sollte auch Custom die korrekte IP übermitteln. Klappt bei mir mit Custom Setup und DeSec als Empfänger bspw. völlig problemlos. Das klingt aber als würde noch was anderes mit reinspielen. [image: 1692991860776-3ec8650f-4ae0-4240-ba09-7f6e3e4f20c6-image.png] Bei mir ist mein DSL Interface primary (1_WAN_DSL), daher geht der zweite Eintrag nur via forced interface settings im DynDNS Client. Mit den drei Settings wird das laut Log (und reel getestet) problemlos an desec übertragen und aufgelöst. Wenn das aus irgendeinem Grund nicht klappt sollte man ggf. nochmal in den Regeln untersuchen ob man ggf. Traffic irgendwo über WAN1 geforced hat so dass der Update Job gar keine Chance hat über WAN2 zu gehen. Die Anzeige im Status ist dann dabei korrekt und spiegelt wieder, was das System via checkip.dyndns.org zurückbekommen hat: [image: 1692992024176-8882c20f-0b15-4555-b3d6-9acdc1d76b7a-image.png] Das ist dann im Normalfall auch das was bei "Custom" via <ipaddr> Platzhalter denn in der URI verwendet werden kann. Den Platzhalter muss man dann aber auch nutzen, sonst klappt das Ganze natürlich nicht Cheers

@viragomann said in sub-domains on one IP: Fürs TLS-Protokoll kann auch via SNI die Domain ermittelt werden, aber auch dafür ist HAproxy nötig. Was @viragomann sagt, mit einer Ergänzung: das HAproxy Package hat einen Reiter "Templates" in welchem genau dieses Szenario exemplarisch vorbereitet ist (mit der Variante Unterscheidung der Domains im gleichen Frontend oder alternativ mit shared Frontend - geht beides, man sollte sich nur für eines von beidem entscheiden). Aber wie gesagt, da gibts ein Tempalte für, was einem die ersten Schritte etwas erleichtert. Cheers

@chris-7e said in Now monitoring attacks: Gibt's dafür eine Erklärung? Ja, irgend eine Log-Datei wurde rotiert (da sie die eingestellte Größe erreicht hat) was zu einem Neustart von sshguard führt - also kein "Angriff" oder Sonstiges ...

@bosco Update ... Offensichtlich waren hier plötzlich Firewall Regeln aktiv aus einem alten Paket was ich mal installiert hatte vor 2 Jahren. Diese habe ich und alle ist wieder ok. Es ist mir dennoch ein Rätzel warum die plötzlich aktiv waren...

ah hat endlich mithilfe von alias geklappt

Hey AndyN ich weiß dass der Thread schon recht alt ist. Ich dachte mir schreibe meine Lösung, vielleicht kann sie jemand anders gebrauchen. Ich hatte das gleiche Problem wie du ... Ich habe dann in die spezifikation von CERT Files geschaut und habe folgendes entdeckt: wikipedia on X.509 Übliche Dateinamenserweiterungen für X.509-Zertifikate sind: .CER – DER- oder Base64-kodiertes Zertifikat .CRT – DER- oder Base64-kodiertes Zertifikat .CSR – Base64-kodierte Zertifizierungsanfrage des öffentlichen Schlüssels (plus weitere Metadaten des Besitzers) an eine CA, umschlossen von „-----BEGIN CERTIFICATE REQUEST-----“ und „-----END CERTIFICATE REQUEST-----“ .DER – DER-kodiertes Zertifikat .P12 – PKCS#12, kann öffentliche Zertifikate und private Schlüssel (Kennwort-geschützt) enthalten. .P7B – Siehe .p7c .P7C – PKCS#7-signierte Datenstruktur ohne Dateninhalt, nur mit Zertifikat(en) oder Zertifikatsperrliste(n) .PEM – Base64-kodiertes Zertifikat, umschlossen von „-----BEGIN CERTIFICATE-----“ und „-----END CERTIFICATE-----“ .PFX – Siehe .p12 Ich denke, dass sich Synology den aufbau der cert files nach Dateiendung determiniert. In diesem Sinne ... Ich habe alle meine cert files dann mit .pem bezeichnet und den aufbau wie folgt angelegt: -----BEGIN CERTIFICATE----- MIIDMTCCApqgAwIBAgIJAOSBBMR+7wPrMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNV .... byYdVKj2xZDv+sodTc7zzLkFKUImi0Rcr8I6xtJklBLNAZBcjlns0p5/yAxT5YN7 nCslmxg= -----END CERTIFICATE----- ich habe das ca.pem sowie client.pem und key.pem angelegt in drei seperaten dateien und diese in die maske von synology hinzugefügt. danach hat es sofort geklappt. hoffe es hilft jemand beste grüße tom

Leute es funktioniert. Ich war einfach zu ungeduldig. Es hat fast 10 Minuten gedauert, bis die pfsense online gegangen ist. Nach einem Reboot ging es dann allerdings super schnell. Vielen Dank euch allen

@JeGr said in Device Load Cycle Count zu hoch.: Crontab wird hier nämlich gern nach Neuinstallation zurückgesetzt, Shellcmd speichert aber in config.xml :) Das gilt für cron doch auch.

@Sperber said in Dual OpenVPN-Setting, CARP & Failover (HA, MultiWAN): (Vorkbaard hat das bereits beschrieben: https://vorkbaard.nl/openvpn-in-a-pfsense-carp-cluster/ ) Die Info ist aber relativ alt und nicht zutreffen. Wir haben da sehr verschiedene und komplexe Services laufen und keiner braucht irgendwelche seltsamen Settings mit "local <extIP>" o.ä. - das sollte heute überhaupt nicht mehr nötig sein. Macht im CARP Setup auch keinen Sinn, da die CARP VIPs alle auf dem Master laufen und man diese so nicht ansprechen kann. Split CARP mit Master/Backup auf dem selben Node ist in der FreeBSD Variante von CARP/pf nicht enthalten, das ist leider nur in OpenBSD enthalten. Mich interessiert allerdings auch wie @viragomann wie man überhaupt auf der 2. pfSense im CARP die Annahme von OpenVPN erlauben will. Der Traffic kommt ja nicht bei ihr an, weil der via CARP IMMER zur primären läuft, nicht auf den sekundären Node. Und wenn man das forwarden sollte auf Node 2, würde der Node versuchen asymmetrisch zu antworten (oder es läuft alles wieder über Node1), was auch wieder nicht sehr schön ist. Wie ist das also realisiert, dass die Clients sich auf Node2 connecten und das auch funktioniert, wenn Node2 mal aktiv wird und Node1 passiv weil vlt. gerade gewartet wird o.ä.? Ansonsten wäre mir schleierhaft wie das im Redundanzfall wirklich sauber funktionieren sollte ohne dass manuell eingegriffen wird? Cheers \jens

@johndo said in OpenVPN Server für Clients: Ich habe nun die Möglichkeit eine komplett neue Netgate Appliance 7100 einzurichten. Ich würde nun gerne einen OpenVPN Server inkl. CA analog dem bestehenden Guide einrichten und kann im Anschluss das ganze wieder als HowTo hier im Forum bereitstellen. Eventuell wäre es für den ein oder anderen Interessant. Ich sehe nicht ganz den Grund für einen Guide, wenn es die Docs/Howtos von Netgate selbst gibt, aber vielleicht gibt es ja durchaus Bedarf. Ich sehe das persönlich ein wenig kritisch, weil sich die Howtos, Docs, Blogs und Co immer weiter Häufen und jeder irgendwas anders bastelt und schraubt und irgendwann stehen dann wieder alle im Kreis und keiner weiß, was man denn dann jetzt tun soll. Am Schlimmsten sind dann die dutzenden (teils sehr schlechten/invollständigen/falschen) VPN Anbieter Tutorials. Darum rate ich da zur Vorsicht, aber ansonsten dokumentiere gerne mit. @johndo said in OpenVPN Server für Clients: Die ersten Fragen die ich hätte beziehen sich auf das erstellen der CA. Zur Info die CA soll nur für OpenVPN verwendet werden... [image: 1691434178159-a12620b9-bd3c-4969-b57a-481409d1596e-grafik.png] Sollte man "Randomize Serial" aktivieren? Klingt für mich logisch das immer zu aktivieren? Key type RSA oder ECDSA? Wenn RSA Keysize 4096 oder höher? Wenn ECDSA secp384r1 oder secp521r1? Digest Algorithm sha384 oder höher? Da die CA nur für OpenVPN genutzt wird und man die Clients eh selbst deployed, kann man hier auch wählen was modern und sicher ist. Wenn man hier keine Rücksicht auf steinalte OpenVPN Versionen in veralteten Geräten, Routern oder sonstwas nehmen muss, kann man hier moderne Standards wählen. Randomize Serial würde ich hier empfehlen, genauso ECDSA mit mind. prime256. secp384r1 oder 521 muss nicht unbedingt sein. Mehr ist nicht immer besser. Ebenso SHA256. 384 oder 512 sind auch hier nett, aber keine Pflicht. Es geht auch um Performance und Co. Daher würde ich hier auf gute Sicherheit ohne es zu übertreiben setzen. @johndo said in OpenVPN Server für Clients: Eine weitere Frage wäre was ist die "Beste" Cryptographic Hardware für mein vorhaben? Voreingestellt ist das hier: Es hat einen Grund, warum die 7100 (auch wenn sie EOS ist) so ausgeliefert wird. Daran gibt es auch nichts zu ändern. QAT ist für den C3000-Atom immer noch die beste Option. In manchen wenigen Situationen kann IPsec MB ein Quentchen mehr aus der HW herausholen aber im Normalfall bzw. in der Breite wird die QAT Beschleunigung des C3k Atom besser funktionieren. OpenVPN sucht sich via OpenSSL selbständig den Beschleuniger den es nutzen kann. Wenn AES oder QAT da und enabled ist, wird es also gneutzt. Sofern man dann bei den OpenVPN Settings nicht die Verschlüsselung signifikant absichtlich kaputt konfiguriert, sollte das passen. Auch hier gilt wenn keine Altlast mitgeschleppt wird kann hier das neueste und schnellste ausgewählt werden. Ergo GCM mit 256 und ggf. noch Chacha20 als Alternative. Das wars. CBC ist da Altlast und verhindert ohnehin, dass man DCO benutzen kann. Seit OVPN 2.6 ist das bei Clients - sofern die Konfig nicht Murks ist - eh schon aktiv. Wenn man es auf Serverseite auch noch ins Spiel bringen kann - bestens und senkt Last und erhöht Performance nochmal deutlich. Einige Vergleiche mit IPsec und Wireguard erzielen mit OpenVPN DCO sogar je nach Szenario gleiche oder höhere Geschwindigkeiten ohne das "leichte" Chaos von Wireguards Public/Private Key Konfiguration für jeden Peer. Daher viel Erfolg :) Cheers

@viragomann said in OpenVPN - TLS Handshake failed :-(: ich würde erstmal überprüfen, ob die Pakete überhaupt am Server ankommen. Naja - wenn ich eine Fehlermeldung vom Server quote, werden sie das wohl… Ich habe inzwischen - nach vielem Herumprobieren - eine funktionierende Konfiguration. Case closed.

so richtig schlau werde ich aus dem Beitrag nicht. Habe jetzt mal den Loglevel für openVPN2 auf 11 gesetzt. Jul 26 14:44:20 openvpn 15236 /usr/local/sbin/ovpn-linkup ovpns2 1500 0 10.42.42.1 10.42.42.2 init Jul 26 14:44:20 openvpn 15236 /sbin/ifconfig ovpns2 10.42.42.1 10.42.42.2 mtu 1500 netmask 255.255.255.255 up Jul 26 14:44:20 openvpn 15236 TUN/TAP device ovpns2 exists previously, keep at program end Jul 26 14:44:20 openvpn 15154 dev = 'ovpns2' Jul 26 14:44:19 openvpn 82902 Flushing states on OpenVPN interface ovpns2 (Link Down) Jul 26 14:44:19 openvpn 98318 /usr/local/sbin/ovpn-linkdown ovpns2 1500 0 10.42.42.1 10.42.42.2 init Jul 26 14:44:19 openvpn 98318 /sbin/ifconfig ovpns2 10.42.42.1 -alias Jul 26 14:43:51 openvpn 98318 /usr/local/sbin/ovpn-linkup ovpns2 1500 0 10.42.42.1 10.42.42.2 init Jul 26 14:43:51 openvpn 98318 /sbin/ifconfig ovpns2 10.42.42.1 10.42.42.2 mtu 1500 netmask 255.255.255.255 up Jul 26 14:43:51 openvpn 98318 TUN/TAP device ovpns2 exists previously, keep at program end Jul 26 14:43:51 openvpn 98105 dev = 'ovpns2' Jul 26 14:43:50 openvpn 66818 Flushing states on OpenVPN interface ovpns2 (Link Down) Jul 26 14:43:50 openvpn 45248 /usr/local/sbin/ovpn-linkdown ovpns2 1500 0 10.42.42.1 10.42.42.2 init Jul 26 14:43:50 openvpn 45248 /sbin/ifconfig ovpns2 10.42.42.1 -alias

@slu Also, die 23.05.1 war nicht die Lösung! Ich habe an meinem Unify AP einen TCPDUMP durchgeführt und festgestellt, das fragmentierte Paket die Verbindung des AP zum Windows NPS Server verhindern. Habe dann etwas mit den FRAME MTU Raten am NPS rumgespielt, einerlei Erfolg! Erfolg brachte das setzen des nachfolgenden Punktes Reassemble IP Fragments until they form a complete packet in den System\Advanced\Firewall & NAT Einstellungen unter VPN Paket processing Nach setzen dieses Hakens ging mein WLAN (mit Zertifikat) über IPSEC sofort wieder. Das hat mich einiges an Debug Aufwand gekostet......

@aboutchris Wollte ich gerade als Lösung schreiben - einfach Update Pfad hin- und zurück switchen - aber du hasts selbst schon gefunden. Grund kann einfach sein, dass die Box beim letzten Check einen (dann schon gefixten) falschen Pfad oder Zertifikat abbekommen hat und damit die Paketquellen zerwürfelt. Umsetzen auf einen anderen Pfad lädt das komplett neu statt nur zu updaten, darum klappt das meistens. Müsste via Konsole und mit einem erzwungenen reset/refresh auch gehen, aber in der UI gibts da wenig Möglichkeit aktuell, daher ist da das hin-zurück-schalten der Workaround der oft klappt :) Aber schön, dass es geklappt hat und gut, dass es jetzt hier für deutschsprachige User auch nochmal zu finden ist! Cheers \jens

@Blumagine said in IPv6 Konfiguration: @JeGr Hallo, danke schon einmal für deine Hilfe, folgende Konfiguration - ich habe bei einem Dritten einen Hetzner Dedicated Server gemietet. Auf diesem läuft ein Hyper-V mit drei VMs. VM pfsense, WAN geht direkt durch auf Hetzner LAN, LAN geht auf virtuellen Hyper-V-Switch 2./3. Windows Server mit LAN am Hyper-V-Switch. Von Hetzner bekomme ich leider nur ein /64 (2a01:XXXX:XXXX:2d4f::/64), davon habe ich momentan die ::1/64 auf das WAN als feste IPv6 gebunden mit WAN Gateway fe80::1. EDIT: ich bekomme auch kein zweites /64, da sich der Anbieter schon bei IPv6 überhaupt total quergelegt hat - das bräuchte ja heutzutage keiner... Wunsch wäre jetzt, dass die beiden Windows-Server am LAN eine IPv6 aus diesem Bereich bekommen (oder zu mindestens ipv6.google.com öffnen können). Leider kann ich im LAN aber nicht das gleiche Präfix eintragen, da mir die pfsense das nicht zulässt? Liebe Grüße, Lars Moin Lars, dann bleibt wahrscheinlich nichts anderes übrig als das LAN mit einem Lokalen IPv6 Prefix hochzuziehen. Also mit einem Prefix aus dem fdXY:: Bereich, bei welchem empfohlen wird, das zu randomisieren. Also die ersten 64bit der Adresse zufällig mit fd-Prefix zu wählen. Man könnte aber auch ein Auge zudrücken und bspw. bei einem 2a00::xy bspw. das passende fd00::xy intern zu nutzen, damit die Adressen einfacher greifbar werden. Dann müsste es IMHO relativ einfach machbar sein, ein NPt zu definieren mit dem Hetzner IP6/64 auf dem WAN und dem zugehörigen ULA aus dem FD-Bereich. Also bspw.: Vom Provider: 2a00:3210:abcd:1242::/64 ULA: fd00:3210:abcd:1242::/64 Und dann das FD-Netz intern eben ganz normal wie ein statisches Netz ausrollen. Entweder mit SLAAC oder wenn Erreichbarkeit von extern via V6 passieren soll, dann statisch eine Dienst-IP6 vergeben (und ggf. die zusätzlichen privacy extensions per SLAAC/DHCP6 erlauben). Diese sollten dann wenn NPt sauber konfiguriert wurde sauber nach draußen gehen. @Blumagine said in IPv6 Konfiguration: Wunsch wäre jetzt, dass die beiden Windows-Server am LAN eine IPv6 aus diesem Bereich bekommen (oder zu mindestens ipv6.google.com öffnen können). Leider kann ich im LAN aber nicht das gleiche Präfix eintragen, da mir die pfsense das nicht zulässt? Natürlich lässt sie das nicht zu, man darf auf zwei unterschiedlichen Interfaces auch nicht die gleiche IP-Range nutzen, da ansonsten ja keiner weiß WO das Paket hin soll. Darum muss man mit zwei verschiedenen Netzen arbeiten. Man könnte jetzt zwar damit kommen, dass man auch mit einer "transparenten Bridge" arbeiten könnte, aber das ist in den meisten Fällen gerade wenn man mit Netzwerk nicht ganz firm ist eher überkomplex und fehleranfällig. Cheers

@dogfight76 said in Installation PFSense auf alten PC per USB-Stick: Und dort ist der gleiche Eintrag wie bei den Gateways die funktionieren, darum verstehe ich nicht warum: AUTH_FAILED Das betrifft doch den Username und Passwort. Oder ? Dann ist ganz klar User/Pass bei deinem Client falsch oder wird von der Gegenseite abgelehnt. Ganz egal was woanders eingetragen ist, wenn das hier als Feedback im Log kommt, ist das was deine Config an den Server übermittelt falsch. Dann hast du entweder deine Credentials falsch eingetragen, es haben sich irgendwelche Kontrollzeichen reingemogelt (Leerzeichen, Linebreak o.ä.) oder man muss bei Nord noch irgendwas anderes machen, dass das bei deren Servern funktioniert mit dem Login. Aus Mangel an Account und Co kann ich da leider wenig zu sagen. Ich habe das hier mit Proton, die dazu auch ne vernünftige Anleitung haben, zweimal für völlig unterschiedliche Standorte durchgespielt - da funktioniert alles einwandfrei. Die Credentials die mir Proton ausgibt, werden sauber beim Client in den Feldern User/Pass eingetragen und ausgelesen und er kann sich verbinden. Notfalls mal bei Nord nachfragen warum OVPN da sagt, dass User/Pass falsch wären.