@Mansaylon said in pfSense Startet nicht durch:

Bei der Installation nicht das vorgegebene Disk Format verwenden, sondern ZFS.

Hmm OK das ist dann ein Sonderfall - ich tippe allerdings immer noch eher auf eine BIOS Besonderheit. Evtl wird mit der ZFS Installation noch ein anderer Parameter gesetzt, aber an sich sollte es keinen Unterschied machen. Der BootManager ist eigentlich der gleiche 🤷 Seltsam.

ZFS ist auf nackter Hardware aber eh zu empfehlen und die bessere Wahl über UFS :) Insofern auch gut ;)

Also für das, was @bosco in seinem initialen Post schreibt, ist er bei Host Overwrites erstmal richtig. Die tun genau das:

mail.boscolab.de löst extern auf 1.2.3.4 auf Diesen Eintrag in Host Overrides machen auf 192.168.3.4 mail.boscolab.de löst intern auf 192.168.3.4 auf WENN(!) die Hosts alle brav die pfSense als DNS nutzen, bzw. du intern DNS nutzt, die die pfSense als Forwarder haben (e.g. PiHole, AD oder ähnliches gehen trotzdem, wenn die die pfSense als Forwarder drin haben und damit den Override sehen/nutzen).

Was @viragomann aber korrekt "anmängelt":

Wenn deine Hosts intern dann kein HTTPS machen, weil du das ja auf dem HAProxy vorher terminierst, dann kannst du die intern natürlich nicht über bspw. https://mail.boscolab.de erreichen, weil sie intern ja nur HTTP sprechen.

Aber: Hast du mal versucht was passiert wenn die externe IP aufgelöst wird? Klappt es dann nicht? Wenn du HAproxy auf die WAN IP konfiguriert hast sollte er da eigentlich auch reagieren und dich weiterleiten? Aber könnte aus irgendeinem Grund auch schief gehen, daher erstmal die Frage ob es nicht eh eigentlich schon geht und du dann via Proxy kommst.

Wenn du den Proxy umgehen willst, dann muss natürlich dein Endgerät auch sauber HTTPS sprechen können, nicht nur der Proxy, sonst fällt man natürlich auf die Nase.

Wenn du aber willst, dass sich die Dinge intern genauso verhalten wie extern, dann kannst du auch schlicht ein zusätliches Frontend anlegen (und ganz schamlos dein vorhandenes vom WAN Interface kopieren) und dieses bspw. auf die interne IP der Firewall konfigurieren (so wie das externe auf die WAN IP vermutlich). Zumindest wenn es mit dem WAN Frontend wie oben gefragt nicht eh schon geht :)

Dort dann alles wie gehabt konfigurieren (bzw. eben einfach das WAN Frontend kopieren) und statt intern dann die bspw. 192.168.3.4 auszugeben, die Firewall interne LAN IP ausgeben.

Resultat:

externe Hosts -> https://<domain.tld>/

DNS Auflösung -> Public IP von öffentlichem DNS kommen auf WAN an werden vom HAproxy auf internen Server geproxy'd

interne Hosts -> https://<domain.tld>/

DNS Auflösung -> Host Override auf pfSense IP kommen auf bspw. LAN an werden auch von HAproxy auf interne Server geproxy'd

Somit gleiches Verhalten. :)

Cheers
\jens

@vantage09
Die Verbindungsabbrüche sind nun keine Thema mehr?

@vantage09 said in LAN -> WAN Verbindung (Internetverbindung) bricht häufig ab // Port Forwarding:

Wenn ich die pfSense durch meine alte Firewall TPLink SafeStream tausche, funktioniert die Portweiterleitung ohne Probleme.

Macht der etwa S-NAT (Masquerading) bei der Weiterleitung? Dieses sicherheitsbedenkliche Verhalten haben leider so manche der o8/15-Router, damit auch die totalen DAUs damit zurechtkommen.

Wenn so, musst du eventuell die Firewall bzw. den Service auf dem Zielrechner anpassen.

Ok schau ich mir an. Musste sie nochmal als vm neu aufsetzen da die watchguard firebox x750e für unsere Leitung zu schwach war.
Dann werd ich mir das ganze zu Gemüte ziehen damit der cloud Server und Webserver freigegeben werden.

Danke euch

In der Hoffnung, dass der Fehler nicht in der Konfiguration steckt, würde ich die gesamte Konfiguration sichern und in die neu installierte pfSense importieren.

Ansonsten könntest du OpenVPN gesondert exportieren. Die User sind aber im Bereich System zu finden, so weit ich weiß.
Wenn du diesen Bereich nicht übernimmst, müsstest du jeden User mit Name und Passwort neu anlegen und über den Cert-Manager die Zertifikate und Keys eines jeden exportieren und wieder importieren.

Hallo,

"sehr gut" beobachtet" :-)

Meine Firewall hat drei Netzwerkschnittstellen:

WAN LAN DMZ

Das Handy hängt an der LAN-Schnittstelle.

Mein Ziel ist ein VPN mit Zugriff auf die DMZ, dass ich "immer eingeschaltet lassen kann". Der externe Hostname existiert daher doppelt:

beim DynDNS-Anbieter (zeigt auf die Provider-IP) im lokalen DNS (zeigt auf die LAN-Schnittstelle der pfSense)

Dein Kommentar klopft mir tatsächlich gerade ein paar Schuppen hinter den Ohren hervor.

Aber - was wäre denn die korrekte Strategie? Ich habe keinen Bock, das VPN immer von Hand ein- und auszuschalten - abhängig davon, ob ich in meinem WLAN bin.

Gruß,
Jörg

Edit: Das VPN funktioniert perfekt! Es geht somit tatsächlich "nur" noch um die Vorgehensweise bzw. das Bedürfnis, das VPN nicht jedes Mal "von Hand" umschalten zu müssen :-)

@Bob-Dig said in nmap zeigt closed Ports am WAN - wie kommt das zustande?:

Möglicherweise gibt es ja doch eine Freigabe, vielleicht unter NAT 1:1.

Kann ich ausschließen, des Rätsels Lösung ist tatsächlich die Annahme von nmap das Ports geschlossen sind.

Das kann ohne weitere Daten keiner wissen. Conn_refused kann alles mögliche sein.

Frage ist eher, was gibt die "fritz.example.domain" aus dem Internet für einen Antwort und was gibt sie bei dir auf der pfSense und auf deinen Clients für eine Antwort. Das klingt eher nach DNS Fehler.

Factory Reset ist keine Neuinstallation. Gerade wenn im Filesystem was korrumpiert wurde, kann sich das trotzdem weiter halten. Darum sicherheitshalber USB Stick ran, Installation starten, vor Installation Recover XML machen - dann sollte auch die Konfiguration übernommen werden (natürlich Backup parat haben) - und dann Neuinstallation mit Auto (ZFS) und gut. Dann weiß man wie es ausschaut.

Moin, nach langem Probieren konnte ich nun das Problem lösen. Es lag daran, dass der OpenVPN-Access-Server nur (in den Standardeinstellungen) mit SHA1 läuft, nicht mit SHA 256. Das ist zwar nicht die sicherste Alternative, aber für diesen Zweck total ausreichend. Und es funktioniert! Noch schnell die Routen der jeweiligen Netze in den OpenVPN-Access-Server eingetragen und es klappt. Beide Seiten können sich anpingen!

Vielen Dank für alle Tipps und Anregungen.
Tom

Ich habe nun meine Konfiguration auf folgende Einstellung geändert:

bb37f9fa-dbac-41ca-b16a-aac46085cae5-grafik.png

Das scheint notwendig zu sein, da die Telekom für die IP-Telefonie in Zukunft nur noch DNS-SRV/NAPTR zulässt und nicht mehr die Registrierung über den Port 5060/5061 direkt per UDP oder TLS.

@Rico
Einen herzlichen Dank!!!
Das war die Lösung, jetzt kann ich die Firewallregeln so konfigurieren wie benötigt

Wie gesagt, ich bin nach verschiedenen Anleitungen vorgegangen, denn die VLANS auf der PFSense anzulegen führte dazu, dass ich keine Daten zwischen den VLANS transferieren konnte - zumindest keine Megabyte. Bei kb war schluss.

Ist erst mal bei den Akten das Thema bis ich mal wieder Zeit habe.

Danke

Bekannt ist mir momentan neben den neueren Mainboards bzw. erste Router Hersteller:
Zotac Barbones: (Zotac Barbones)
Gigabyte Nuc's (https://www.gigabyte.com/Mini-PcBarebone)
NAS Hersteller (https://www.qnap.com/solution/2.5g/de-de/)
Wifi Enterprise (Beispiel Cisco Meraki: https://meraki.cisco.com/wp-content/uploads/2020/05/meraki_datasheet_MR45.pdf)

Generell gibts ja bereits einige PCIe und USB Adapter für 2,5Gbit und auch 5Gbit

Habe nun die beiden 10Gb Ports in pfSense gebridget. Da ich auch noch die letzte mit dem Host "geteilte" 1Gb-NIC (LAN in pfSense) komplett in die Sense gelegt habe, ist mir deren Konfiguration Hops gegangen... Und ich habe wieder bei Null angefangen. Schmerzhaft, aber ich ahnte es bereits.

Mit der Bridge erreiche ich ca. 600 MB/s, dann ist Schluss.
Clipboard01.png

Auch sind alle drei Rechner sowohl mit einem 1Gb Switch verbunden, welcher widerrum mit der pfSense verbunden ist, als auch per 10Gbit mit der pfSense. Es gibt also jeweils zwei Gateways an den WinDosen, welche aber beide an die pfSense führen und bis jetzt gibt es keine Probleme. 🤞

Sehr gern :)

@mreczio
Hallo!

IPSec 🙁

Du musst auch IPSec mitteilen, dass es den Traffic zwischen dem OpenVPN Client und dem LAN B routen soll.

Wie sonst auch, geht das über die Phase 2.
Also wenn noch nicht geschehen, musst du auf der pfSense B eine Phase 2 hinzufügen:
Local: 192.168.3.0/24
Remote: 192.168.200.0/24

Und auf der pfSense A eine Phase 2 mit vertauschten Netzen natürlich.

In der OpenVPN konfiguration ist das LAN B 192.168.3.0/24 zu den "IPv4 Local Network/s" hinzuzufügen, damit der Client die Route gepusht bekommt.

Die Firewall-Regeln an den beteiligten Interface müssen den Zugriff natürlich auch erlauben.
Dann sollte die Sache laufen.

Hallo zusammen,

ich habe eine sehr ähnliche Umgebung. Bei mir lief bisher
Internet --> ipfire --> haproxy --> nextcloud

Nun habe ich die ipfire durch eine pfsense ersetzt (der Rest ist so geblieben, wie er ist) und kann nun Nextcloud Talk nicht mehr nutzen. Die hier genannten Ports hatte ich als NAT-Regel (mit zugehörigen Firewall-Regeln) in der pfsense eingetragen und aktiviert, aber leider keine Änderung.

Ich bin daher händeringend auf der Suche nach einem Lösungsvorschlag. Wo kann ich suchen? Wo kann ich noch was probieren?

Da ich erst seit wenigen Wochen die pfsense im Einsatz habe, fehlt mir leider eine breite Basis zur Administration des Systems.

Vielen Dank im Voraus für Eure Hilfe. VG, Jörg.

@bitboy0 said in Open-VPN auf APU zu langsam.:

Gibt es eine APU-Platine die schnell genug ist für stabile 100+MBits S2S mit OpenVPN?

Wenn du die pcEngines APU meinst - nein. Es gibt nur EINE APU Platine. Mehr haben sie nicht. Alle anderen Varianten mit Zahlen ist die gleiche Hardware. Egal ob APU2, APU3 oder APU4 es ist immer der gleiche dusselige steinalte AMD Jaguar da drauf. Die haben nix Neueres.

Wenn du generell APU meinst im Sinne von CPU+GPU als SOC: da gibts einige die das locker packen. Ist aber natürlich eine Finanzfrage :)

Ah, jetzt erst gelesen (blind, sorry), das 19" APU Gehäuse etc. - also nein, die PCEngines APUs sind einfach zu schwach.

3 NICs sind heute weniger Problem. Wenn aber das Ziel wirklich 100%ig ist, dass ihr 100Mbps Durchsatz encrypted auf nem VPN Tunnel wollt (und die andere Seite das auch bringt/kann! - bringt ja nix, wenn die Gegenseite zu lahm ist), dann wäre das der Punkt, den man als SOC suchen müsste. C2000 ist alt und würde ich nicht mehr empfehlen, wobei da die großen IMHO auch schon auf 100Mbps locker gekommen sind. Ansonsten sind C3000er auf jeden Fall problemlos in der Lage das zu stemmen. Also C3558 oder C3758 o.ä. - je nachdem was man sonst noch einsetzen möchte. Evtl. gehts aber auch kleiner wenn wirklich nur VPN der Knackpunkt ist. Aber wie gesagt, dann muss auch die Gegenstelle mitziehen. Wenn die bspw. eh nur 25 oder 50 schafft, kann man da andere Maßstäbe ansetzen :)