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?

Du musst natürlich noch den TCP Port auf der Sense freigeben. 😉

Hallo,

darauf muss man erst mal kommen.
Aber plausibel, im Routing unterscheidet sich Windows von iOS oder Linux, aber dass es versucht, einen VPN Tunnel über denselben Tunnel zu schicken...
🙄

exactly how did you solve this problem?
I have the same problem

Unser IaaS Provider hat aus Sicherheitsgründen die Guest-VLAN-Funktion ausgeschaltet, da sonst das Risiko besteht, das wir auch VLANs anderer Kunden an unsere VMs hängen könnten. Ist zumindest die Argumentation des IaaS Providers.

Kein Thema, aber dann ist das auch genauso wie man es im Normalfall mit MultiWAN aufsetzen würde. Das scheint also zu passen :)

@tobiasp said in pfSense OpenVPN Client falsche IP:

Ich würde mich nie auf die Stufe mit dem jenigen stellern der es von Anfangan gelernt hat, jedoch sorge ich dafür das was ich nicht weiß eben am Ende lerne. :)

Das ist gar nicht der entscheidende Punkt ;) Ich habe einige Kunden, deren IT'ler sich nicht unbedingt wahnsinnig gut auskennen. Geht heute auch gar nicht - aber die haken nach. Stellen Fragen. Und merken im Gespräch (hoffentlich) dass ich ihnen keinen Bären aufbinde und mit ihnen zusammen was suche, was auf sie passt. Ohne sie arm zu machen. Wenn ich aber ein Angebot 5x verändern/nachbessern soll, weil jemand nicht versteht, warum er vllt. NBD Support brauchen könnte wenn sein ganzes Geschäftsmodell daran hängt, dass das Internet erreichbar ist. Und er ggü. anderen Lösungen noch Geld spart, dann fehlt mir für die "Unlogik" einfach jegliches Verständnis. Dafür haben wir nun aber auch letztes und dieses Jahr schon einige Kunden von den verschiedensten anderen Lösungen "befreit". Forefront TMG z.B. (gruselig) oder Sophos, Watchguard, Juniper, Cisco. Läuft nicht immer 100% glatt, weil viele andere "Namen" dann ihre eigenen Speziallösungen haben, die dann nicht mehr gehen (VPN Clients bspw.) aber meistens finden wir zusammen eine gute wenn nicht bessere Lösung. Jetzt aber genug OT :D