@bordi said in Die Zensur der Regierung umgehen:

Gibt es was ähnliches, oder wurde ähnliches für pfSence schon angedacht / veröffentlicht?

Bei der Vielschichtigkeit des Themas "Zensur der Regierung umgehen" und der politischen Dimension
wäre das nach meiner Meinung viel zu kurz gesprungen.

LG

https://blog.pilif.me/2018/05/22/fiber7-tv-behind-pfsense/

hat bei mir vor einigerzeit direkjt geklappt

In früheren Versionen konnte man die Sense noch als Mailrelay (postfix) nutzen. In den aktuellen Builds wurde das Paket aus sicherheitsrelevanten Aspekten zu Recht entfernt.

Schau mal ob ein Content Filter (squid, pfBlocker) aktiv ist und dort bestimmte Domains/IPs geblockt wurden. Es betrifft ja angeblich nicht alle E-Mails.

Die Anzeige der Rufnummer ist von Anbieter zu Anbieter unterschiedlich und wird in der Fritzbox korrigiert, wenn du dort auch Telekom hinterlegst. Bei "anderm Anbieter" passiert das nicht bzw. du mußt das manuell machen. im ip-phone-forum ist da einiges zu finden.

Gruß
pfadmin

Ja, wir betreiben alles mit den VF Compal CH7466CE. Da wir immer dedizierte Rechner für die FW einsetzen haben wir eine VM Konfiguration nicht getestet. Was wir beobachtet haben, waren Probleme des VF Modems, wenn die MAC des DHCP Clients eine andere war als die des Network Ports auf dem Switch.

Aus meiner Sicht sollte aber die Konfiguration mit VM und dediziertem Port auch funktionieren. Haben es aber nie ausprobiert.

P.S. DSL Modems (wir nehmen DrayTeks Vigor130) läuft über getaggte VLANs problemlos.

@robin223 said in routing zwischen zwei LAN interfaces ?:

Könnten sie mir bitte beschreiben wie ich diese Regeln konfiguriren muss

Also ich würde dringend raten erstmal das pfsense Buch zu lesen. https://www.netgate.com/docs/pfsense/book/

Nabend. Man hat die Möglichkeit per Easy Rule IP-Adressen zu blocken. Einfach unter Status/System Logs/Firewall auf die entsprechende IP-Adresse klicken und zur Blockliste hinzufügen. Die Blockliste wird als Regel WAN Interface gespeichert, wird zusätzlich als Alias gespeichert und dann kann dort auch bearbeitet werden.

Ich glaube ich habs!

Ich hatte den Punkt "Flush all states when a gateway goes down" aktiviert (SystemAdvancedMiscellaneous).
Ich verstehe zwar nicht wieso die States dann geleert werden wenn ich eine Regel ändere, aber an meiner Testbox konnte ich das verhalten nachvollziehen.
Ist der Haken gesetzt werden alle bestehenden Verbindungen gekappt sobald ich Apply anklicke.
Mache ich den Haken raus bleiben die Verbindungen bestehen.

Ich verstehe es zwar nicht, m.E. nach sollte die Einstellung keinen Einfluss auf Regeländerungen haben, aber egal.

Ich werde das Heute Abend bei meiner produktiven Firewall mal ausprobieren und abschließend berichten!

DANKE!

Und Gruß

Ja, so lange der State aktiv ist, ist der Ping auch erlaubt. Wenn du den Ping aber für einige Sekunden beendest, wird die Verbindung geschlossen.

Aktive Verbindungen werden durch Änderungen an Filterregeln nicht beeinträchtigt.
Wenn du das haben möchtest, müsstest du die die Verbindung manuall kappen. Diagnostic > States

@jegr said in zusätzliches Interface kann pingen aber kein TCP traffic:

Ich denke zur wirklichen Diagnose - wenn er die möchte - wären auch sinnvolle Screenshots besser als das Config File, was man auf den ersten Blick so gar nicht einschätzen kann.

Whaaaat? 😱

Sorry, sehe ich anders und wie schon mehrfach erwähnt habe ich aktuell keinen Zugriff mehr auf die Kiste - erst wieder nächstes Jahr. Ich wollte nur das Problem rechtzeitig lösen, da nächstes Jahr die Kiste einfach laufen muß.

Trotzdem danke.
Johannes

Shared Frontend kann gehen, aber wenn der andere Zugriff nicht über 443 sondern 80 läuft, dann braucht es ein entsprechendes Frontend auf diesem Port. Ein zusätzliches dann, denn dann läuft darüber ja kein Offloading.

@lexycode said in Keine DNS Aufösung im LAN:

Nachdem ich DNS Query Forwarding in der DNS Resolver config aktiviert habe löst ping nun auch DNS namen auf.

Das sollte für die LAN Clients keinen Unterschied machen.

Bei mir bekommen die DHCP-Clients die Interface-IP als DNS Server zugewiesen. Auch das ist von der Forwarding-Einstellung unabhängig.

Aber DNS klappt ja jetzt, meinst du?

Ist deine WAN-IP ein öffentliche? Falls nicht, könntest du sie ja hier verraten, könnte helfen.

Was gibt denn ein Traceroute auf einer LAN-VM ins Internet aus?

@gladius War auch gar nicht konkret als Kritik gedacht, sondern eher als Aufklärung, warum das heute durchaus noch die favorisierte Variante sein kann, wenn man mit größeren Strukturen murmeln "darf" 😉

Ist auch nicht wirklich sooo schön, wenn man da bspw. für 20 Außenstellen 20 Tunnel aufbauen und konfigurieren muss, vor allem wenn die dann noch crossover verbunden sind. Aber gerade dadurch - und bei Tunnel Anzahlen von >4 - lohnt sich das oft schon alleine deshalb, um einen Multicore besser auszunutzen. Auch wenn man meistens nicht unbedingt die mega Bandbreiten schaufelt, addiert sich dann doch bei ~20 Links auf einem 4-Kerner die Last pro Kern (5 Tunnel pro Kern) durchaus zusammen. AES-GCM hilft da aber schonmal - wenn man beide Enden kontrolliert und aktuell hält. Inzwischen ist aber auch wieder IPSEC dank routbarem Interface eine veritable Alternative geworden (die wir aber noch testen müssen).

Zusatz: Ich war mal so frei und habe eine grobe Idee formuliert, ob das Acme Package nicht ggf. über scheduled rules solch einen Mechanismus triggern könnte (eine Regel enabled/disablen basierend auf Uhrzeit via Cron ist ja bereits möglich). Eine fest angelegte Regel mit spezifischer ID/Description o.ä. könnte hier dann durchaus auf dem WAN on/off triggerbar sein so dass der Update Prozess vor seinem Start die Regel an- und nach Ausstellung des Zertifikats abschalten könnte. Soweit die Idee, aber klügere Köpfe können da sicher eine bessere Antwort geben :)

@renegade said in DNS (Unbound) löst nicht auf, wenn einer der DNS Server nicht erreichbar ist:

Gemeint war der DNS Server. Aber vermutlich hast Du recht und die DNS Server sind durch deren Cluster "immer erreichbar".

Anycast, also so gut wie. Sollte nicht wie zu Beginn größere Probleme auftreten, sollten beide IPs ähnlich wie die Quad 8 oder Quad 9 Adressen so gut wie immer durch geographisch Nahe Gegenstellen aufgelöst werden.

Steht denn trotz TLS fest, dass die DNS Server IMMER über die Gateways gehen?

TLS hat damit gar nichts zu tun, sondern IP. Wenn du 1.1.1.1 mit GW 1 und 1.0.0.1 mit GW 2 fix in General Settings einträgst, dann werden für diese IPs entsprechende Hostrouten gesetzt. Der Sense ist dann völlig gleichgültig was du mit dem Endpunkt sprichst, es wird jeder Traffic dann hart über GW1 oder 2 geschickt.

Werden zur Auflösung einer IP IMMER beide DNS Server und in meinem Falle beides Gateways zur Auflösung genutzt?

Habe ich noch nicht nachgesehen, aber meines alten Wissens nach war Unbound als Resolver seriell, nicht parallel arbeitend, somit würde er erst 1.1.1.1 dann 1.0.0.1 versuchen, wenn er keine Antwort bekommt. Das könnte aber im Forwarding Modus tatsächlich anders sein, hatte ich aber noch nie explizit nachgesehen.

dass immer DNS #1 und #2 online sein müsse

Nein, das sollte genau nicht der Fall sein. Vor allem nicht wenn #1 dein Default Gateway ist, dann gibt es eigentlich erst recht keinen Grund, warum dann DNS#1 nicht laufen sollte. Das müsste man aber im Einzelfall nachstellen/probieren. Auch der Haken bei Advanced "System Default Gateway Switching" wäre dann ggf. zu überdenken und je nach Fall bei dir zu setzen.

Gruß

Wo ist dann die Firewall-Rule auf dem LAN-Interface? IPV4* to any mit Allow IP options sollte da existieren?