Soooo, ich konnte mein Problem doch lösen. Es lag am NAT. Ich habe jetzt ein NOT NAT eingerichtet und auf der FRITZ Box ein Routing. Nun geht alles :-) Kann geschlossen werden Grüße PFsense_User2019

@hec said in pfBlockerNG - GeoIP blocking funktioniert nicht: Ich verstehe nicht was es bringen soll das Internet in eine Insel zu verwandeln. Das Internet hört an der deutschen Grenze nicht auf. Vollkommen deiner Meinung. Ich teste nur gerne immer wieder mal was aus. Es war unter anderem ein Test, die Zugriffe durch den pfBlockerNG auf Deutschland zu beschränken. Immerhin ist es ja eine der Funktionen des Blockers.

Weil meine tatsächlich erreichbaren Werte eher dem entsprechen, was ohne AES NI zu schaffen ist. Mit AES NI geht der Benchmark ja eher Richtung 1 Gbit/s.

Es wird auf jedem Gerät, das nicht die pfSense als Standardgateway hat und via OpenVPN der pfSense erreicht werden soll eine statische Route für das VPN Tunnel-Netz auf die pfSense benötigt. Ansonsten würde das Zeilgerät die Antwortpakete immer zum Standardgateway schicken und diese kämen nie zum VPN Client zurück. Auf die FB trifft das vermutlich zu. Diese ist ein Router und hat ein Default Gateway irgendwo beim Provider. Aber Wurscht, Outbound NAT ist hier wohl auch okay. Wenn der Zugriff dahin ohnehin nur für mich selbst erlaubt ist, hätte ich es auch damit gelöst. Grüße

@johndo Super und Danke für deine Anleitung!

Hey, vielen Dank für die Hinweise. Die Floating-Rules waren Schuld. Nach dem Umbau klappt es jetzt. Vielen herzlichen Dank! Grüße

Hallo, danke für die Rückmeldung. Doch kann eine NAT-Regel nur ein Workaround für Verbindungsprobleme in einer Site-to-site Konfiguration sein, nicht die Lösung. Die Lösung liegt in den richtigen Routen und Firewall-Regeln. NAT hat gewisse Nachteile. Wenn diese in deinem Fall hinnehmbar sind, ist die Sache natürlich auch okay. Grüße

Er hat sich tatsächlich kurz aus dem Urlaub gemeldet ... den soll er genießen! Muss ich halt etwas warten, bis er erholt wieder hier am Start ist.

Hi, bitte diesen Thread ebenfalls als nicht SPAM deklarieren -> https://forum.netgate.com/topic/145367/howto-openvpn-server-f%C3%BCr-clients Danke!

Floating Regeln wären der Vollständigkeit halber auch noch zu erwähnen. Ist hier eine Regel eingerichtet, die eines der beiden Interfaces ausgewählt hat, würde sie auch angewandt werden. Ich denke aber nicht, dass das bei dir zutrifft. Ein Interface in einer Floating-Regel wählt man ja nicht unbewusst aus.

Sie bieten Dir kein Modem an, das musst Du selbst kaufen. IPv6 hast Du natürlich nur, wenn Du Dualstack hast schalten lassen.

@JeGr ich habe dich im Chat angesprochen. Würde dich gerne Mal engagieren... Wäre schön, wenn du Mal über die Adresse dort Kontakt aufnehmen könntest.

@JeGr said in HAProxy redirect neue Domain gleiche Struktur: %[req.uri] Dann kommt leider eine Fehlermeldung: [ALERT] 205/123827 (79381) : parsing [/var/etc/haproxy_test/haproxy.cfg:81] : error detected in frontend 'NachOpenVPN_HTTPS' while parsing 'http-request redirect' rule : failed to parse sample expression <req.uri> : unknown fetch method 'req.uri'. [ALERT] 205/123827 (79381) : Error(s) found in configuration file : /var/etc/haproxy_test/haproxy.cfg

@viragomann said in OpenVPN 2.Zugang: Regeln, die am OpenVPN-Reiter definiert sind, werden auf allen OpenVPN-Instanzen, Server wie Clients, angewandt. Eine Differenzierung ist in diesem Fall nicht möglich. Da beide TAP Interfaces aber in anderen Adressbereichen liegen müssen (anders funktioniert das Routing ja nicht), ist es an der Stelle oftmals irrelevant, denn man kann die Regeln an Hand der Source (Netz Server A, Netz Server B) definieren und auseinanderhalten ;) Dass der Reiter OpenVPN ein Gruppeninterface mit allen OVPN Servern/Clients ist, ist aber völlig richtig und sobald man Clients definiert bietet sich die Trennung dann an. Trotzdem ist die einzelne Regelerstellung auf Grund der unterschiedlichen Source Adressen problemlos möglich. :) @Pippin said in OpenVPN 2.Zugang: Richtig JeGR, ein client kann aber selbst eine route setzen, hangt aber von server seitige routen ab ob der client irgedwo gelangen kann, also normales routing trifft zu, wem erzähle ich das :). Darum immer abschotten mittels firewall und persönlich weise ich immer einen interface zu. Interface zuweisen oder nicht ist wie beschrieben Ansichtssache, spätestens bei vielen unterschiedlichen Site2Site Verbindungen bietet es sich sicher an. Bei 2-3 Clients/Tunneln ist das aber noch sehr überschaubar. Sicher kann ich auch auf dem Client an IP und Routing herumspielen. Warum auch nicht. Aber das heißt lange nicht, dass der Server auf der anderen Seite da mitspielt. Wie beschrieben - ich garantiere da sicherlich für nichts, aber von meinem bisherigen Beobachtungen würde das der entsprechende OVPN Service auf dem Port/Interface schlicht ablehnen weil er nichts mit anzufangen weiß. Könnte man sicher bei OpenVPN Upstream mal als Frage stellen/aufmachen. Praktisch habe ich das aber noch nie gesehen, dass sich das jemand zurechtbasteln konnte :)

Danke. Ich habe die XML editiert und das backup eingespielt. Lief sofort.