Hilfe bei Netzwerk einrichten
-
Hallo Zusammen
Habe gerade die neue pfsense Version 2.3.2 auf 2 Geräten installierten und jetzt ein paar Fragen ob ich das richtig angegangen bin.Firwall 1:
LAN 192.168.1.2
WAN 172.16.200.1 /28Firewall 2:
LAN 192.168.1.3
WAN 172.16.200.2 /28CARP:
LAN 192.168.1.1
WAN XXX.XXX.XXX.XXX/28Frage 1.
Bei der alten pfsense Firewall habe ich bei den NAT Outbound Regeln immer die WAN Adresse angegeben bei der Translation.
Somit hat z.B. LAN1 immer über eine spezifische WAN Adresse nach außen kommuniziert.
Jetzt habe ich gelesen das bei einer CARP Umgebung dies nicht zu empfehlen ist.
Es soll immer bei Translation die VIP CARP Adresse angeben (192.168.1.1) werden.
Ist das korrekt? Wenn ja, was sind die Probleme wenn ich das nicht mache und wie kann ich definieren das LANXY über eine spezielle WAN Adresse nach außen kommuniziert?
Ich möchte ja nicht das meine Gäste über die selbe Public Adresse nach Aussen kommunizieren wie mein interner Mail Server.Frage 2.
Die Outbound NAT Regel für das pfsync Interface kann gelöscht werden, oder? Ich sehe jedenfalls keinen Nutzen darin.Frage 3.
NTP wird ja nicht über XMLRPC Sync synchronisiert und im Service NTP wird das Interface angegeben und nicht das CARP Interface.
Somit würde NTP down gehen wenn die MASTER Firewall weg ist in einer CARP Umgebung?
Kann ich auf der Slave Firewall ein NTP konfigurieren und bei den Clients z.B. als secondary NTP angeben oder was würdet ihr mir empfehlen?Frage 4.
Bei der neuen Version ist DNS Resolver als Standard definiert und wird eigentlich auch überall empfohlen.
Unter dem DNS Resolver Submenu "Network Interfaces" wird definiert welche Netzwerke Zugriff auf diesen Dienst haben, diese starten danach ihre DNS Abfragen über die pfsense, diese wiederum geht über die DNS die unter General Setup -> DNS Server angegeben wurden, korrekt?
"Outgoing Network Interfaces" bei DNS Resolver gehen nicht über die pfsense sondern direkt zu einem der definierten DNS Server oder wie muss ich das verstehen?Frage 5.
Bei CARP auf dem WAN Interface werden ja seit kurzem keine public IP mehr gebraucht.
Nur die Subnetzmaske in meinem Fall /28 müssen dringend identisch sein?
Der Gateway auf dem WAN Interface ist der Gateway meines Public IP Blocks oder?Frage 6.
Netzwerke wie Gäste LAN würdet ihr Dienste wie NTP, DNS Resolver anbieten? Gibt es hilfreiche Tipps wie man sich gut Schütz mit solchen "Public" Netzwerken?Vielen vielen Dank für eure Hilfe.
Gruss DarkMasta
-
Hallo!
Firwall 1:
LAN 192.168.1.2
WAN 172.16.200.1 /28Firewall 2:
LAN 192.168.1.3
WAN 172.16.200.2 /28CARP:
LAN 192.168.1.1
WAN XXX.XXX.XXX.XXX/28Die Verschleierung der CARP IP lässt vermuten, dass du private IPs für die beiden WAN Interfaces verwenden möchtest, aber nur eine öffentliche für CARP. Ist das so?
Frage 1.
Es soll immer bei Translation die VIP CARP Adresse angeben (192.168.1.1) werden.
Ist das korrekt? Wenn ja, was sind die Probleme wenn ich das nicht mache und wie kann ich definieren das LANXY über eine spezielle WAN Adresse nach außen kommuniziert?Die LAN-Adresse als Translation? Nein.
Für eine Outbound NAT Regel am WAN Interface kann jede von außen erreichbare IP angegeben werden. Typischerweise ist das die WAN CARP IP, muss es aber nicht sein.
Weitere IPs kann man als virtual IPs vom Typ "IP Alias" der WAN CARP IP hinzufügen und dann auch als Translation in der Outbound NAT Regel verwenden.
Selektieren kannst du das Quell-Netz, für die die Regel gelten soll, im Feld Source.Frage 2.
Die Outbound NAT Regel für das pfsync Interface kann gelöscht werden, oder? Ich sehe jedenfalls keinen Nutzen darin.Ich auch nicht. Aber warum wurde überhaupt je eine erstellt? pfSense erstellt automatisch nur Regeln für Interfaces, an welchen ein Gateway definiert ist, ein GW macht aber am Sync-Interface keinen Sinn.
Frage 3.
NTP wird ja nicht über XMLRPC Sync synchronisiert und im Service NTP wird das Interface angegeben und nicht das CARP Interface.CARP ist kein Interface sonder eine IP Adresse. Es wird im NTP Setup das Interface angegeben, an dem die pfSense NTP Anfragen abhört und das tut sie auf jeder IP, die an diesen Interfaces definiert sind, auch auf CARP IPs. Wenn deine Geräte also die CARP abfragen, funktioniert NTP auch im Fall eines Failovers.
Frage 4.
Bei der neuen Version ist DNS Resolver als Standard definiert und wird eigentlich auch überall empfohlen.
Unter dem DNS Resolver Submenu "Network Interfaces" wird definiert welche Netzwerke Zugriff auf diesen Dienst haben, diese starten danach ihre DNS Abfragen über die pfsense, diese wiederum geht über die DNS die unter General Setup -> DNS Server angegeben wurden, korrekt?
"Outgoing Network Interfaces" bei DNS Resolver gehen nicht über die pfsense sondern direkt zu einem der definierten DNS Server oder wie muss ich das verstehen?In den "Network Interfaces" werden jene angegeben, auf welchen der Resolver DNS-Anfragen abhört.
In "Outgoing Network Interfaces" werden die angegeben, an denen die pfSense selbst Anfragen an DNS Server (die unter General Setup genannten) raus schickt. Dies ist bei gewissen Konfigurationen erforderlich, bspw. wenn alles über ein VPN-Gateway geroutet wird.Frage 5.
Bei CARP auf dem WAN Interface werden ja seit kurzem keine public IP mehr gebraucht.
Nur die Subnetzmaske in meinem Fall /28 müssen dringend identisch sein?
Der Gateway auf dem WAN Interface ist der Gateway meines Public IP Blocks oder?Also doch. In diesem Punkt fehlt mir leider die Erfahrung. Ich sehe aber keinen Grund, weswegen die Subnetzmaske der CARP VIP identisch zu dem am Interface nativ definierten sein müsste.
Das Public-Gateway muss erst in System > Routing als Standard-GW eingerichtet werden .Frage 6.
Netzwerke wie Gäste LAN würdet ihr Dienste wie NTP, DNS Resolver anbieten? Gibt es hilfreiche Tipps wie man sich gut Schütz mit solchen "Public" Netzwerken?Diese Dienste sollten ja nicht wirklich anfällig auf Attacken sein. NTP Gästen freizugeben ist wohl ohnehin sinnlos, weil üblicherweise jedes System, abgesehen von Windows-Domän Hosts, öffentliche NTP-Services nutzt.
Schützen kann man sich mit entsprechenden Firewall Regeln. Z.B. für das Gäste-Netz eine Regel erstellen die sämtlichen Zugriff auf RFC 1918 Netzen blockiert. Für die Netze kann man sich einen Alias anlegen. Darüber die Regel für das Erlaubt stellen wie DNS-Zugriff auf die Firewall selbst.Grüße
-
Die Verschleierung der CARP IP lässt vermuten, dass du private IPs für die beiden WAN Interfaces verwenden möchtest, aber nur eine öffentliche für CARP. Ist das so?
Ja genau, ich habe zwar einen /28 Block, möchte aber keine IP für CARP verschwenden.
Die LAN-Adresse als Translation? Nein.
Für eine Outbound NAT Regel am WAN Interface kann jede von außen erreichbare IP angegeben werden.Unter folgendem Link und Menü "Setup Manual Outbound NAT" steht aber eine Notiz von wegen nie eine WAN Adresse angeben oder verstehe ich das falsch?
https://doc.pfsense.org/index.php/Configuring_pfSense_Hardware_Redundancy_(CARP)Typischerweise ist das die WAN CARP IP, muss es aber nicht sein.
Weitere IPs kann man als virtual IPs vom Typ "IP Alias" der WAN CARP IP hinzufügen und dann auch als Translation in der Outbound NAT Regel verwenden.
Selektieren kannst du das Quell-Netz, für die die Regel gelten soll, im Feld Source.Ich habe jetzt alle Netze mit der CAP IP bei Outbound NAT erstellt, hast ja gesagt das wäre auch möglich.
Wie könnte ich jetzt definieren das einige Netzwerke über eine spezielle WAN Adresse nach außen kommunizieren?Ich auch nicht. Aber warum wurde überhaupt je eine erstellt? pfSense erstellt automatisch nur Regeln für Interfaces, an welchen ein Gateway definiert ist, ein GW macht aber am Sync-Interface keinen Sinn.
Ok, speziell…momentan existiert nämlich noch gar kein Gateway und trotzdem erstellt es mir eine Regel wenn ich auf Manual Outbound NAT gehe.
CARP ist kein Interface sonder eine IP Adresse. Es wird im NTP Setup das Interface angegeben, an dem die pfSense NTP Anfragen abhört und das tut sie auf jeder IP, die an diesen Interfaces definiert sind, auch auf CARP IPs. Wenn deine Geräte also die CARP abfragen, funktioniert NTP auch im Fall eines Failovers.
Ja klar, du hast vollkommen Recht…IP und nicht Interface.
Bedeutet aber ich brauche auf jeder Firewall den NTP Dienst, werde ich doch gleich konfigurieren.In den "Network Interfaces" werden jene angegeben, auf welchen der Resolver DNS-Anfragen abhört.
In "Outgoing Network Interfaces" werden die angegeben, an denen die pfSense selbst Anfragen an DNS Server (die unter General Setup genannten) raus schickt. Dies ist bei gewissen Konfigurationen erforderlich, bspw. wenn alles über ein VPN-Gateway geroutet wird.Bei den "Network Interfaces" sind aber auch die CARP IP aufgelistet, muss ich jetzt den Dienst auf die CARP IP starten und unter DHCP Server -> DNS Server die CARP IP angeben?
Du siehst, mich verwirrt das einige Dienste Interface + Carp IP anzeigen und andere wiederum nur die Interfaces.Also doch. In diesem Punkt fehlt mir leider die Erfahrung. Ich sehe aber keinen Grund, weswegen die Subnetzmaske der CARP VIP identisch zu dem am Interface nativ definierten sein müsste.
Das Public-Gateway muss erst in System > Routing als Standard-GW eingerichtet werden .Das die Subnetzmaske die selbe sein muss macht für mich auch keinen Sinn, finde aber kein aktuelle Dokumentation. welche dies bestätigt oder wiederlegt…nur bei der ersten Version von pfsense hat es so viel ich weiss viele Probleme gegeben, wenn das nicht die selbe Subnetzsmakste war.
Hätte jemand mehr Infos für mich?Diese Dienste sollten ja nicht wirklich anfällig auf Attacken sein. NTP Gästen freizugeben ist wohl ohnehin sinnlos, weil üblicherweise jedes System, abgesehen von Windows-Domän Hosts, öffentliche NTP-Services nutzt.
Schützen kann man sich mit entsprechenden Firewall Regeln. Z.B. für das Gäste-Netz eine Regel erstellen die sämtlichen Zugriff auf RFC 1918 Netzen blockiert. Für die Netze kann man sich einen Alias anlegen. Darüber die Regel für das Erlaubt stellen wie DNS-Zugriff auf die Firewall selbst.Im Anhang habe ich dir ein Beispiel eines Guest Netzwerk hinterlegt, was hältst du von dem?
-
Unter folgendem Link und Menü "Setup Manual Outbound NAT" steht aber eine Notiz von wegen nie eine WAN Adresse angeben oder verstehe ich das falsch?
https://doc.pfsense.org/index.php/Configuring_pfSense_Hardware_Redundancy_(CARP)Diese Notiz ist echt etwas unglücklich formuliert. Gemeint ist damit wohl die WAN/Public IP als Source in einer Regel.
Darüber steht aber auch "Select a shared CARP virtual IP address on WAN as the Translation address".Ich habe jetzt alle Netze mit der CAP IP bei Outbound NAT erstellt, hast ja gesagt das wäre auch möglich.
Wie könnte ich jetzt definieren das einige Netzwerke über eine spezielle WAN Adresse nach außen kommunizieren?Hab ich doch bereits geschrieben. Zusätzlich IPs müssen erst in Firewall > Virtual IPs als IP Alias angelegt werden. Als Interface dabei unbedingt die WAN CARP IP angeben. Danach können sie in Outbound NAT Regeln bei Translation ausgewählt werden.
Alternativ kann man zusätzliche IP auch als CARP anlegen, würde ich aber nicht empfehlen, weil das wesentlich mehr Overhead auf der Schnittstelle verursacht.Bei den "Network Interfaces" sind aber auch die CARP IP aufgelistet, muss ich jetzt den Dienst auf die CARP IP starten und unter DHCP Server -> DNS Server die CARP IP angeben?
Wäre auf jeden Fall sinnvoll, weil diese auf nach einem Failover zur Verfügung steht. Die CARP IP muss auch als Gateway in der DHCP Konfig angegeben werden. Und nicht vergessen, dir reale LAN-IP der anderen pfSense in "Failover peer IP" einzutragen.
Das die Subnetzmaske die selbe sein muss macht für mich auch keinen Sinn, finde aber kein aktuelle Dokumentation. welche dies bestätigt oder wiederlegt…nur bei der ersten Version von pfsense hat es so viel ich weiss viele Probleme gegeben, wenn das nicht die selbe Subnetzsmakste war.
Hätte jemand mehr Infos für mich?Habe ich auch gelesen. Dokus sind leider oft veraltet und die Möglichkeit eine CARP-IP in einem anderen Subnetz zu verwenden ist noch relativ jung.
Es ist ja auch kein Problem ein priv. /28er Netz auf WAN zu konfigurieren, du benötigst ohnehin nur 2 Adressen darin.Im Anhang habe ich dir ein Beispiel eines Guest Netzwerk hinterlegt, was hältst du von dem?
Viele Regeln. ;) Ich würde Aliase verwenden und die Zielports darin zusammenfassen, nachdem es eine "Sicherheitsgruppe" ist.
In der 1. Regel erlaubst du alles auf der Interface Adresse, also auch Zugriff auf den WebConfigurator der pfSense(!). Das darf in einem Gastnetz nicht sein.
Erlaube nur, was nötig ist, wie DNS, DHCP (TCP/UDP sollte reichen), und als Ziel die CARP-IP nicht die Schnittstellen-IP.
Ansonsten okay, wenn du diese Dienste benötigst. -
Im Anhang habe ich dir ein Beispiel eines Guest Netzwerk hinterlegt, was hältst du von dem?
Viele Regeln. ;) Ich würde Aliase verwenden und die Zielports darin zusammenfassen, nachdem es eine "Sicherheitsgruppe" ist.
In der 1. Regel erlaubst du alles auf der Interface Adresse, also auch Zugriff auf den WebConfigurator der pfSense(!). Das darf in einem Gastnetz nicht sein.
Erlaube nur, was nötig ist, wie DNS, DHCP (TCP/UDP sollte reichen), und als Ziel die CARP-IP nicht die Schnittstellen-IP.
Ansonsten okay, wenn du diese Dienste benötigst.Vielen Dank für alles, hab jetzt einiges mit deiner Hilfe zum laufen gekriegt, werde die nächsten Tagen noch ausgiebig testen.
Wie meinst du das mit der Sicherheitsgruppe? Normaler Aliase mit den Ports reichen nicht?Also statt PMMGMT Address muss ich dort die CARP Adresse angeben?
Also in der Firewall Rule ->Destination auf "Single Host or Alias" und danach CARP IP eingeben?Danke und Gruss
DarkMasta -
Wie meinst du das mit der Sicherheitsgruppe? Normaler Aliase mit den Ports reichen nicht?
Mit Sicherheitsgruppe meine ich hier keinen technischen Parameter der Firewall, sondern rein dass dies eine Gruppe von Diensten ist, die Geräte im Gastnetz nutzen dürfen (die eigentliche Sicherheitsgruppe), und deshalb zur besseren Übersicht zusammengefasst werden können.
Also statt PMMGMT Address muss ich dort die CARP Adresse angeben?
Also in der Firewall Rule ->Destination auf "Single Host or Alias" und danach CARP IP eingeben?Ja, genau.
Grüße
-
Mit Sicherheitsgruppe meine ich hier keinen technischen Parameter der Firewall, sondern rein dass dies eine Gruppe von Diensten ist, die Geräte im Gastnetz nutzen dürfen (die eigentliche Sicherheitsgruppe), und deshalb zur besseren Übersicht zusammengefasst werden können.
Ahh, habe es gerade umgebaut, sieht viel übersichtlicher aus, danke
Ja, genau.
Kannst du mir erklären warum?
CARP ist ja eine zusätzliche IP auf dem Interface und sollte doch auch angesprochen werden wenn in der Firewall Rule PMMGMT Address steht oder nicht?Gruss
-
In der Firewall Regel spezifizierst du mit "Destination" eine bestimmte Ziel-IP oder ein Ziel-Netz. PMMGMT Address ist die Interface Adresse.
Die Dienste, die auf einem pfSense HA-Cluster laufen sollen aber über die CARP-VIP angesprochen werden. Damit deine Hosts bspw. als DNS-Server die CARP eingetragen haben und diese IP auch bei einem Failover vorfügbar ist, nur antwortet dann eben die Backup FW auf Anfragen.Wenn du PMMGMT Address angeben würdest und du deine Hosts auf diese IP einstellst, funktioniert der Dienst nicht mehr, wenn die Master FW down ist.
Ebenso als Gateway muss die CARP angegeben werden, wenn es per DHCP gepusht wird, dann eben in der DHCP-Konfig.
-
Morgen ist der erste Testbetrieb, bin sehr gespannt ob alles klappt oder ob ich nochmals auf die standalone pfsense wechseln muss. ;D
Was mir noch nicht ganz klar ist ist die Geschichte mit dem Gateway bei einer WAN CARP Geschichte.
Laut Forumeinträgen muss ich unter "System - Routing - Gateway" den WAN Gateway angeben und diesen als Default definieren.
Auf dem WAN Interface selbst wird dieser aber nicht hinterlegt sondern bleibt auf "None".Wie kommuniziert jetzt die einzelnen Interfaces mit dem WAN Interface bzw. wissen welches der Gateway ist?
Unter Outbound NAT ist ja nie der Gateway angegeben sondern nur die öffentliche WAN Adresse.Zusätzlich würde ich noch gerne wissen wie man einen static DHCP Lease löschen kann, es gibt unter Actions nur ein bearbeiten aber kein löschen.
-
Hallo,
das mit den Gateway hast du wohl ganz richtig recherchiert.
Ein Gateway wird nur in Subnetzen benötigt, aus welchen du eine Verbindung in andere Netze haben möchtest. Bei deinem WAN-Netz (das zu dem die beiden WAN-IPs gehören ist das nicht der Fall. Die müssen lediglich miteinander kommunizieren können, das ist Bedingung für CARP.
Die pfSense benötigt grundsätzlich kein Gateway einem bestimmten Interface zugeordnet, viel mehr muss ein Gateway zu einem an einem Interface konfigurierten Subnetz liegen, damit sie weiß, über welches Interface und mit welcher Quell-IP sie mit ihm sprechen kann. Das Subnetz kann auch ein virtuelles sein. In deinem Fall ist es das CARP-WAN-Netz. Das Default Gateway muss also innerhalb dieses Subnetzes liegen, nichts weiter.
"static DHCP Lease"?? Meinst du "Static Mappings" oder normale DHCP Leases?
Static Mappings kannst du natürlich in der DHCP Server Konfig. DHCP Leases in Status > DHCP Leases. -
Hallo
Hat fast alles einwandfrei funktioniert, habe zwar noch ein paar Fehler drin gehabt wie z.B. privat network geblockt auf der WAN Schnittstelle was für das CARP auf der WAN Seite nicht gerade von Vorteil war ;D
Danke für den Tipp mit den Static Mapping.
Ich habe den Static Mapping im DHCP Leases gemacht und war der Meinung das dort auch die Möglichkeit sein sollte für den statischen Eintrag wieder zu löschen.
Konnte ihn aber jetzt über den DHCP Server von dem richtigen Interface entfernen :)Bei mir geht immer nach einer gewissen Zeit das Interface mit der pfsync down.
Ich habe 2x4 Port Intel Netzwerkkarte + 1x2 Port Broadcom onboard bei jeder pfsense installiert.
Folgende Installation ist identisch bei der Backup pfSenseLAGG0: igb0,igb1,igb4,igb5 für die VLANs, bzw. LAN Seite
LAGG1: igb2,igb6 für pfsync
WAN: ohne Lagg (bge0)Das pfsync Interface ist direkt mit einem gekreuztem Kabel an der 2. Firewall angeschlossen.
Logs steht folgendes:Jan 26 14:22:32 php-fpm 53991 /rc.linkup: Hotplug event detected for PFSYNC(opt15) static IP (192.168.100.1 ) Jan 26 14:22:30 check_reload_status Linkup starting lagg1 Jan 26 14:22:30 check_reload_status Linkup starting igb6 Jan 26 14:22:30 kernel lagg1: link state changed to DOWN Jan 26 14:22:30 kernel igb6: link state changed to DOWN
Das Problem hatte ich schon mal mit einer älteren pfsense Version.
Es hilft immer das pfsync Interface abzuschalten und wieder zustarten, danach funktioniert der sync wieder für einige Zeit. -
Das liest sich komisch, hast du lagg1 mit igb2 und 6 erstellt oder nur mit 2? und ist igb6 ein normales interface für pfSync?
-
Sorry
Ich habe eine LAGG mit igb2 und igb6 erstellt.
igb2 gehört zu der Netzwerkkarte 1
igb6 gehört zu der Netzwerkkarte 2
Beide Karten sind in der selben pfsense Firewall.Ich verstehe nicht warum im Log nur steht igb6 down und nimmt danach den ganzen Lagg1 down…die Kommunikation müsste doch über igb2 weitergehen.
Jetzt bin ich nicht ganz sicher ob ich dich richtig verstehe.
igb6 gehört zu einer Lagg und ist somit nicht als Interface aufgeschaltet sondern die Lagg an sich ist das Interface. -
Ich frage nur weil es - eigentlich - nicht wahnsinnig viel Sinn macht das Sync Interface als LAGG zu definieren und da eher Probleme her kommen können als dass es welche löst :)
Zumindest wurde mir das vom Support mal so kommuniziert, dass es nicht wahnsinnig viel Sinn macht das Sync Interface redundant auszulegen. -
Ich frage mich auch nach dem Sinn, das Sync auf ein LAGG zu legen.
Aber grundsätzlich sollte aber igb2 gar nicht down gehen. Zeigt das Log dafür irgendeinen Grund, irgendetwas, das zuvor passiert?
Das Kabel schon getauscht?Die Sache mit den Applegeräten ist ja höchst suspekt. So wie das aussieht, hast du da 5 Geräte und die tauschen andauernd ihre IPs gegenseitig aus???
Habe mit solchen Dingern keine Erfahrung, bin nicht gerade ein begeisterter Fan der Marke, aber in einem Netzwerk sollten sie sich doch vernünftig verhalten. -
Habe 10 Ports und dachte warum nicht so viel redundant halten wie es geht ;D
Aber wenn das offiziell mal vom Support kommuniziert wurde, baue ich den Lagg zurück…Ja Kabel schon getauscht, da ich die selben Probleme hatte mit nicht gekreuzten Netzwerkkabeln.
Im Log steht leider gar nichts, einfach interface down.Ich halte eben auch nicht so viel von Apple Geräten.
Hab das Problem aber entdeckt:
https://doc.pfsense.org/index.php/ARP_moved_log_messagesHab mich noch nicht stark in die Materie eingelesen aber bis jetzt bin ich der Meinung, wer auf diese Idee mit diesem Apple Bonjour sleep proxy gekommen ist sollte man ******.
Lösung ist wohl wirklich das Log anzupassen, obwohl ich eigentlich gerne informiert wäre, wenn andere Probleme in diesem Bereich auftauchen aber kein Apple Gerät der Grund ist.Gruss
-
'Offizieller Support.' ;D
Die Idee hinter dem Bonjour Sleep Proxy ist ja ganz ganz fein, aber die Umsetzung sehe ich als schweren Missbrauch des ARP Protokolls.
-
'Offizieller Support.' ;D
Jup virago :) Die Antwort kam vom offiziellen pfSense Support. Hatten für einen Kunden explizit angefragt, der ALLES redundant auf mehrere Interfaces auflegen wollte. Sync sogar mit LAGG UND zwei Switchen in H Konfiguration dazwischen augenroll
Und da war die Antwort: Nö unnötig, wir machen das auch in den größten Setups mit einem simplen Crosslink auf einem Interface. :) -
Alles klar, das hatte ich wohl überlesen und es so als Scherz verstanden. ;)
Im Pzinzip auch klar, sollte das Sync-Interface tatsächlich mal ausfallen, passiert normalerweise nicht viel. Im schlimmsten aller Fälle würde HA Einheit zufällig in dieser Zeit ein Failover machen und die States verloren gehen.
-
Konnte leider die Firewall noch nicht umbauen um das Problem mit dem pfsync Interface zu testen.
Was mir gestern "erst" aufgefallen ist, dass mein Upload extrem langsam ist.
Habe eine 50/50 Leitung und bekomme höchsten 50/15 hin.CPU Auslastung ist sehr niedrig, habe unter System > Advanced > Network folgende Eingenschaften disabled:
-Disable hardware TCP segmentation offload
-Disable hardware large receive offload
-Disable hardware checksum offloadTraffic Shaping habe ich bis jetzt nie eingerichtet und auf dem WAN interface habe ich auch schon mit den Duplex Eigenschaften herumgetestet, keine Verbesserung.
https://doc.pfsense.org/index.php/Low_Throughput_Troubleshooting
Collisionen oder in/out Errors auf dem WAN Interface habe ich auch keine.
Was mich ein wenig verwirrt ist das der Downloadspeed einwandfrei ist, nur der Upload nicht.
Das kann nicht wirklich eine Interface Fehler sein oder? (Treiber, etc?)Gruss DarkMasta