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.

@JeGr said in [solved] Traffic Shaper: LAN seitig mit einem Mix aus physikalischen und VLAN Interfaces: Gern hier verlinken, dann leg ich mir das auf Beobachtung, das interessiert mich auch :) Klar, hier.

@esquire1968-0 said in pfSense als DynDNS Server: Gibt es eine Möglichkeit, die pfSense als DynDNS Server zu verwenden? Inwiefern Server?

Guten Morgen und danke für die Rückmeldung. Wie du erwähnt hast, habe ich ein privates Metz zwischen FB und pfSense. Den Haken auf der WAN-Schnittstelle für das Blocken von privaten Netzen habe ich raus genommen. Daher verstehe ich nicht, warum das nicht durch die FB durch geht. Weitere Portforwarding-Regeln in der FB zur pfSense (z.B. auf das Kunden-NAS) funktionieren einwandfrei. Bei dem LOG für die pfsense hatte ich auf dem WAN-Interface nur den OpenVPN-Port angegeben. Das ist alles, was dort steht. Gruß singer

@tpf said in IPv6-Adressen erneuern?: Korrekt Das ist immer Providerabhängig, bei mir "darf" es wohl dran bzw. habe keine Probleme damit, manche wollen aber nur das Prefix weitergeben und machen das Routing über die fe80 LinkLocal Adressen, das ist dann auch nicht außergewöhnlich :) Dass das WAN seine v6 IP auf Basis seiner MAC erhählt, also keine PE, ist gewünscht, nehme ich an Das ist m.W. die normale/alte Implementation vom RFC dass an Hand der MAC Adresse die ID auswürfelt. Inzwischen gibts aber noch ein neueres RFC was das Generieren anders ohne MAC implementiert, das ist aber IMHO in FreeBSD noch nicht enthalten wenn ich mich recht erinnere. Somit: Ja ist (noch) normal so, sollte sich ggf. zukünftig ändern um Rückschlüsse via MAC zu minimieren. Gruß

@JeGr said in externe IP bei 2 x DSL + LTE Backup: Aber gerade wenn ihr Mail ins Haus sendet, solltet ihr da MX und Mailgateway checken, da reicht das kleinste Ärgernis schon und eure Mails werden zukünftig gerne mal als Spam geflaggt. Leider alles schon gehabt :/ Mails kommen direkt auf unsere per MX hinterlegte IP. Senden geht immer über den Hoster als Relay. Ich hatte das Vergnügen schon mal, eine Domain bzw IP von mehreren DNSBL-Listen und den Listen von Antiviren-Herstellern wieder raus zu bekommen - macht keinen Spaß und ist langwierig. Gemeint ist einfach, dass DynDNS für einen anderen Anwendungsfall konzipiert wurde, weil alleine TTLs Caching von Domainnamen etc. etc. nicht dafür ausgelegt sind einen schnellen und sauberen Failover zu garantieren. Darum gehts mir dabei :) So schnell muss das auch nicht sein. Selbst wenn das 30 Minuten dauern würde, wäre das in Ordnung für uns. Hab das jetzt mehrere Male getestet. Alle von mir getesteten externen DNS-Server lösen den Domainnamen innerhalb weniger Sekunden korrekt auf. Caching ist dann natürlich ne andere Sache.

@DaLeberkasPepi said in Probleme mit PIA VPN: Macht es irgend einen Sinn AES-NI und BSD Crypto zu aktivieren oder ist BSD-Crypto eher nur eine Art Fallback Auswahl? Jein. BSD Cryptodev sollte IMHO inzwischen nicht mehr benötigt werden - soweit ich weiß und ohne Gewähr was zukünftige Versionen angeht. AES-NI zu aktivieren (unter adv. Options) lädt das entsprechende Kernel Modul und AES-NI erscheint in der Auswahl (und auf dem Dashboard unter Crypto). Das Kernelmodul ist aber im Prinzip meist nur nötig, wenn man IPSEC VPNs benutzt. Da OVPN im Userspace läuft, nicht im Kernel, wickelt OVPN das alles über die OpenSSL Bibliothek ab, die selbst Wege hat zu erkennen, ob das System AES unterstützt oder nicht -> daher nichts auswählen. Das ist bislang soweit ich weiß das "schnellste" Setting. Wobei wirklich ins Gewicht fällt das nur, wenn man anfängt Linespeed in höheren Geschwindigkeiten erreichen zu wollen, 100, 200, 300Mbps+ Bei den meisten Einwahl-Geschichten geht es nicht unbedingt um 4h Dauertransfer à 100Mbps Max ;)

(Behelfs-) Lösung: komplette Neuinstallation der pfSense und Suricata läuft nun im Legacy-Blocking Mode, statt Inline-IPS.