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.

Hallo,

evtl hast du das Problem inzwischen schon gelöst. Aber falls nicht und für alle die bei einer Suche darauf stoßen: Nicht selten ist die Ursache der Browser-Cache. Daher einfach mal den Cache des Browsers löschen und Browser neu starten und dann nochmal versuchen. Klingt banal, wird aber oft vergessen.

Ximix

Hallo,

Sehe eventuell:

--pull-filter accept|ignore|reject text

im manual 2.4
https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage

Hallo,

kann es sein du hast das gleiche Problem wie hier:
forum.netgate.com/topic/144621/pfblockerng-und-ie11-ca_dnslb ?

Grüße

Erstmal vielen lieben Dank für deine Mühe diese Wand aus Text zu lesen, dich damit zu befassen und auch noch so umfassend drauf zu antworten. Das was du in Bezug auf NAT geschrieben hast hilft mir schon mal einiges weiter. Ich lass es grad noch so wie ich es zuletzt eingestellt hab, es wird noch selektiv getestet. Das nächste wäre dann an dieser Schraube rumzudrehen oder s.u. .

Log auf der pfSense habe ich mich mit befasst, ist halt nur eine Seite. Das parallel an den Testclients oder über ein MITM Device zu fahren hatte ich noch nicht gemacht, wird aber werden müssen wenn wir die ursächlichen Probleme erkennen wollen. Alles Aufwand, wollte ich vermeiden wenn geht, trägt u.U. nicht zur Lösung bei wenn die Konstellation bleibt wie sie ist, man würde evtl. nur erfahren warum es nicht funktioniert.

An dem Windows Server (kein ISA, auch deswegen und weil alt: Rauswurf) war nichts spezielles eingerichtet. Den hab ich noch da und kann den auch so starten, hab das mehrfach kontrolliert - nichts besonderes gefunden.

Auch wenn mir das die liebste Lösung wäre: wir können dem Kunden und dem TS Dienstleister - der doch einiges größer ist und mit dem TS und der Software darauf deutschlandweit operiert - im Moment schlecht verklingeln dass wir - die wir nachträglich dazugekommen sind - mal eben sagen und vorschreiben wie der VPN Tunnel aufgebaut wird. Da geht erstmal kein Weg rein. Da kommt dann auch der Spruch 'das ging bisher ja auch' und 'andere machen das auch' usw. . Müssen wir wohl absehbar mit leben. Die von dir angesprochene Alternative - die mir sehr gefällt - den Cisco umzukonfigurieren so dass der in eine DMZ kommt - sprich einfach ein anderes LAN Segment und eine weitere Zielroute zuzuweisen - wird für die 'einfach zu aufwändig', hatten wir schon kurz angesprochen, wollen die nicht mal eben so machen. Die Alternative wäre das primäre Netzwerk umzukonfigurieren aber auch das steht im Moment in keinem Verhältnis, da sind wir länger beschäftigt. Da ist sehr viel zu beachten, da laufen an dem einen Standort x Server und xx Diagnosegeräte, wird wohl eher nicht passieren. Wenn sich das Problem weiterhin manifestiert werde ich den Kunden so richtig gut überzeugen müssen (Argument ASA Updates und Pflege, weiss kein Mensch hier) und mit dem Kunden zusammen dem Dienstleister die Pistole auf die Brust setzen dass der die Cisco entspr. umkonfiguriert. Das ist einer der letzten Wege, erfordert Überzeugungsarbeit, wäre aber eine saubere Lösung. Das mit dem Routing der Druckjobs in das Kundennetz lässt sich auch lösen, müssen die an der ASA machen.

Aktuell läuft es zeitweilig unter Beobachtung mit einem Testclient. Falls das dennoch bleibt ist der nächste Schritt mehr Dumps zu erzeugen und damit das Problem einzukreisen sofern es bleibt. Danach läuft es auf Überzeugung des Kunden und Druck auf den TS Dienstleister hinaus.

Danke für deine Hilfe, ich bleibe dran, das Thema ist noch nicht durch weil wir das noch testen lassen.

Grüße