Hallo,
vielen Dank für eure Antworten.
Ich habe gedacht, ich hätte alle Infos geschrieben, Sorry.

Ich führe es mal genauer aus.
Wir werden zu Events eingeladen und stellen verschiedene Dienste zur Verfügung.
Vor Ort ist meistens schon eine kleine Netzwerkstruktur vorhanden (komplett unbekannt wie aufgebaut).
In dieser Struktur gibt es einen Server, auf den wir unsere Daten erhalten, die auf unseren Systemen dann angezeigt werden.

In unserem Netzwerk ist ein LTE Router für die Internetverbindung, DHCP usw. also ganz einfach gehalten.
Mein Gedanke war nun (zugegeben sehr naiver Gedanke :-D), eine pfSense zu haben mit der wir uns da mit "rein hängen".

Das Problem an dem ganzen ist nur das alle Daten, die wir raus schicken über unser ISP laufen müssen und nicht über den ISP des Veranstalters laufen kann/darf.

Danke für die Infos, damit konnte ich mir schon einiges raussuchen und mein nicht vorhandenes Wissen aufbessern :-).
Zeichnung mache ich noch fertig.

VG

@tux84 said in IPv6 Prefix für PfSense nach Reboot der Fritzbox weg:

Scheint so als würde hier kein dringender Bedarf bestehen um das Problem zu lösen.

Absolut. Die meisten Businesses haben wohl eh feste IPs und in den USA vorrangig in der vierten Version.

Wirklich trivial scheint es aber auch nicht zu sein, sonst hätte die andere Sense doch längst eine Lösung parat haben müssen...

Meine 21er hatte 23.01 und 23.05. und den .1, ohne Probleme.

Nur habe ich halt eben bei den gesagten Problemen das Recovery gemacht, dauert 10 Minuten mit noch mal 10 Minuten Kaffee trinken weil man wartet bis alle Pakete wieder da sind.

Wir sprechen hier von einer Firewall die auch mal Dienste wie VPN oder anderes anbietet, da sollte die schon auf einem aktuellen Stand sein.
Ja das ist ein wenig Arbeit bei der Pflege, aber von dem zfs Bug beim Upgrade abgesehen, hatte ich mit den Kisten bisher keine Probleme, nutz man keine Dev Version.

Auch das Upgrade Problem wurde für die ARM Kisten bei zfs inzwischen gelöst, man kann die einfach gemütlich wieder per Klick auf Stand bringen.

Wobei ich bei so großen Versionssprüngen dann eher ein Recovery machen würde.

Eine gebrauchte Sophos 125/135 Rev3 tut es auch, die gibts mit ein wenig Glück bei eBay für schon mal unter 100€.

Das ist dann eine echte Firewall Appliance und wurde für diesen zwecke entworfen.
Mit dem C Atom hast du Intel QA und damit alles an Hardware Crypto was man so braucht, dazu einen Verbrauch von unter 20W.

Die Hardware muss schon rock solid sein, wenn man da eine Firewall drauf laufen lassen will, das Ding muss ja immer funktionieren, sonst ist halt gleich eine Störung da.
Und im Normalfall setzt man so was ja ein, wenn man mehrere VLANs betreibt und damit auf das Gateway angewiesen ist um über diese in die anderen Netzte hinein zu routen.

Lösung gefunden, es war eine falsche netmask in der /etc/network/interfaces bei der VM die nicht erreichbar war:

Falsch: netmask 255.255.255.255
Richtig: netmask 255.255.255.0

damit klappt es jetzt.

Danke!

@grantorino 1. warum kaufst du dir nicht einfach ein modem (z. b. Vigor 16x) leider hast du nicht zu geschrieben bei welchem provider du bist.
2. ich habe es bei mir auch so das die Fritzbox nur als VoIP telefonanlage dient. ich hänge mal mein netzwerkplan an.

┌──────────────────────────┐ │ │ │ WAN / Internet (PPPoE) │ │ Willy.tel │ │ 1000/250Mbit/s Glasfaser │ │ │ └─────────────┬────────────┘ ─ ─ ─ ─ ─ ─ ─ ─WAN─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┼ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ WAN ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │ ┌────────────────┐ ┌────────────────┐ │ │ │ │ Switch │ ╔════════╩══════════════ pfSense+ 23.01 ══╗ Stand: ─ ─ ┐ │ TrueNAS ├───┤ USW-Flex-XG ├─────────╣ ║ │ │ │ │ │ ║ Intel NUC BNUC11TNHV50L00║ 29.03.2023 │ └────────────────┘ └───┬────┬───────┘ ║ LAN: 192.168.3.0/24║ │ ┌────────────────┐ │ │ ║ Gäste (W)LAN (VLAN33): 192.168.33.0/24║ ─ ─ ─ ─ ─ ─ ┘ │ UBNT │ │ │ ║ IoT WLAN (VLAN34): 192.168.34.0/24║ │UniFI AP AC Pro ├───────┘ │ ║ DynDNS über deSEC mit eigener Domain║ │ │ │ ║ VPN's:║ └────────────────┘ │ ║ 2 x Fritzbox (7490 & 6591) IPSec║ │ ║ 1 x OpenVPN Road Warrior (172.16.3.0/24)║ │ ║ 1 x WireGuard Road Warrior║ │ ║ (172.16.33.0/24)║ │ ╚═════════════════════════════════════════╝ │ ┌────────────────┐ ┌────────┴───────┐ ┌────────────────┐ ┌────────────────┐ │ Fritzbox 7490 │ │ Switch │ │ UBNT │ │ 1 x UBNT │ │ (Nur VoIP) ├───┤ USW-Flex-XG ├─┤USW-ENTERPRISE-8├─┤UniFi AP-Flex-HD│ │ │ │ │ │ -POE │ │ │ └────────────────┘ └────┬───────────┘ └──────┬─────────┘ └────────────────┘ ┌────────────────┐ │ │ │ UBNT │ │ │ ┌───────────┐ │UniFI AP AC Pro ├────────┘ │ │ │ │ │ └────┤ Clients │ └────────────────┘ │ │ └───────────┘ zu deinen APs kann ich dir nichts sagen, wie du in meinem netzwerkplan sehen kannst setze ich UBNT ein. ich denke die meisten hier im forum nutzen UBNT an der sense.

@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.

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:

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...

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.