5
PfSense CARP outgoing Problem
Hallo zusammen
ich habe letzte Woche im 5. Anlauf eine pfsense Standardlösung (SG3100 als LAN-2LAN Firewall) durch eine lange vorbereitete HA Lösung
(2*XG7100) ersetzen wollen. Im Vorlauf hatten wir irre Probleme mit den SFPs was wir nun endlich lösen konnten. Bei dem Anlauf lief dann soweit an den Clients alles wie soll (DNS erreichbar, Pakete gehen raus, NTP+DHCP geht) ich kam auf die WebGUI. Es kamen nur keine Pakete vom anderen LAN zurück sprich Funktion nicht mehr gegeben; umgesteckt geht wieder. Gleiche FW Regeln und Aliase und IPs.
Nachdem ich keine Erklärung hatte wieder rückgebaut und nun einen Testaufbau mit einigen Clients gemacht.
Die Clients sehen sich, sehen die beiden Firewalls und deren CARP IP, bekommen die Dienste, aber auf der Firewall sehe ich nur die andere FW und das CARP Interface mit allen Diensten (nmap Plugin). Firewall ist auf den Clients aus und nichts dazwischen außer einem dummen L2 Switch.
ARP Einträge sehe ich keine außer den beiden FW und der CARP IP, sprich arp geht auch auf dem LAN Interface schon nicht, obwohl die Geräte mit mir "reden" (zwischen den Vorort Tests und meinen Analysen dann vom Testplatz aus sind aber Stunden)
Das ganze ging im Testaufbau vor etwa einem Jahr und wurde ausführlich getestet. Dann abgebaut (Ende Testphase) und gewartet bis Umsetzung.
Seither gab es nur:
-Hardwareänderungen (SFPs)
-dann Deviceanpassung (ix1 auf igp1)
-drei OS Updates
-einmal musste die IP Range angepasst werden Das ist aber jeweils nach Anleitung durchgelaufen. Die Gesamtfunktion wurde da aber nie mehr danach geprüft, sprich da muss der Fehler liegen.
Vom Problemfall sieht es aus, als ob nun ein "VLAN/vhid" Bit gesetzt wird beim Egress, Eingang alles OK. VLANs haben wir dort aber nicht im Einsatz oder auch nur konfiguriert. Das CARP Interface ist auf beiden FWs gleich gesetzt (nur durch den skew und Basis IP unterschiedlich).
Failover funktioniert ebenso für die Clients wie soll ohne Ausfall. Ohne Rückwärtige Pakete hilft das aber nichts. Da die Dienste richtig laufen, betrifft es auch nur einen Teil der Pakete.
Mein Gedanke wäre nun das CARP am LAN zu löschen und neu aufzusetzen oder mit tcpdump an dem Interface rumzuspielen. Mal kurz einen Client mit Wireshark ranhängen kann ich auch angehen ist aber deutlich mehr Aufwand. Wichtig ist nur das Ziel (CARP einfach neu aufsetzen und sehen); trotzdem bin ich gehalten den Fehler zu finden, da irgendwie die Pakete verloren gehen (denke nicht das die wirklich aus der pfsense rausgehen).
Gedanken?
Gruß
Sam
ich habe letzte Woche im 5. Anlauf eine pfsense Standardlösung (SG3100 als LAN-2LAN Firewall) durch eine lange vorbereitete HA Lösung
(2*XG7100) ersetzen wollen. Im Vorlauf hatten wir irre Probleme mit den SFPs was wir nun endlich lösen konnten. Bei dem Anlauf lief dann soweit an den Clients alles wie soll (DNS erreichbar, Pakete gehen raus, NTP+DHCP geht) ich kam auf die WebGUI. Es kamen nur keine Pakete vom anderen LAN zurück sprich Funktion nicht mehr gegeben; umgesteckt geht wieder. Gleiche FW Regeln und Aliase und IPs.
Nachdem ich keine Erklärung hatte wieder rückgebaut und nun einen Testaufbau mit einigen Clients gemacht.
Die Clients sehen sich, sehen die beiden Firewalls und deren CARP IP, bekommen die Dienste, aber auf der Firewall sehe ich nur die andere FW und das CARP Interface mit allen Diensten (nmap Plugin). Firewall ist auf den Clients aus und nichts dazwischen außer einem dummen L2 Switch.
ARP Einträge sehe ich keine außer den beiden FW und der CARP IP, sprich arp geht auch auf dem LAN Interface schon nicht, obwohl die Geräte mit mir "reden" (zwischen den Vorort Tests und meinen Analysen dann vom Testplatz aus sind aber Stunden)
Das ganze ging im Testaufbau vor etwa einem Jahr und wurde ausführlich getestet. Dann abgebaut (Ende Testphase) und gewartet bis Umsetzung.
Seither gab es nur:
-Hardwareänderungen (SFPs)
-dann Deviceanpassung (ix1 auf igp1)
-drei OS Updates
-einmal musste die IP Range angepasst werden Das ist aber jeweils nach Anleitung durchgelaufen. Die Gesamtfunktion wurde da aber nie mehr danach geprüft, sprich da muss der Fehler liegen.
Vom Problemfall sieht es aus, als ob nun ein "VLAN/vhid" Bit gesetzt wird beim Egress, Eingang alles OK. VLANs haben wir dort aber nicht im Einsatz oder auch nur konfiguriert. Das CARP Interface ist auf beiden FWs gleich gesetzt (nur durch den skew und Basis IP unterschiedlich).
Failover funktioniert ebenso für die Clients wie soll ohne Ausfall. Ohne Rückwärtige Pakete hilft das aber nichts. Da die Dienste richtig laufen, betrifft es auch nur einen Teil der Pakete.
Mein Gedanke wäre nun das CARP am LAN zu löschen und neu aufzusetzen oder mit tcpdump an dem Interface rumzuspielen. Mal kurz einen Client mit Wireshark ranhängen kann ich auch angehen ist aber deutlich mehr Aufwand. Wichtig ist nur das Ziel (CARP einfach neu aufsetzen und sehen); trotzdem bin ich gehalten den Fehler zu finden, da irgendwie die Pakete verloren gehen (denke nicht das die wirklich aus der pfsense rausgehen).
Gedanken?
Gruß
Sam
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2279376032
Url: https://administrator.de/forum/pfsense-carp-outgoing-problem-2279376032.html
Ausgedruckt am: 31.12.2024 um 04:12 Uhr
5 Kommentare
Neuester Kommentar
Hallo,
- Lass die 7100er im LAN
- Schau im WAN setup nach ob Du dort folgendes nicht angeklickt (gehakt) hast
(siehe Bild)
Allerdings sind bei der 7100 Serie die ix0 und ix1 direkt am SoC angeschlossen
und bei hoher Lasterzeugung kann das ein Vorteil sein! Eigentlich profitieren eher
LAGs davon, aber die Netzwerklast in Eurem LAN kennen wir ja nun auch nicht unbedingt.
SG 7100 Switch overview
BlueKobold
Gedanken?
Nur zwei,....- Lass die 7100er im LAN
- Schau im WAN setup nach ob Du dort folgendes nicht angeklickt (gehakt) hast
(siehe Bild)
Seither gab es nur:
-Hardwareänderungen (SFPs)
Wohl eher nicht.-Hardwareänderungen (SFPs)
-dann Deviceanpassung (ix1 auf igp1)
Der igb(4) Treiber ist einer der besten in pfSense neben dem em Treiber.Allerdings sind bei der 7100 Serie die ix0 und ix1 direkt am SoC angeschlossen
und bei hoher Lasterzeugung kann das ein Vorteil sein! Eigentlich profitieren eher
LAGs davon, aber die Netzwerklast in Eurem LAN kennen wir ja nun auch nicht unbedingt.
SG 7100 Switch overview
-drei OS Updates
Da kann schon das eine oder andere drinnen stecken.-einmal musste die IP Range angepasst werden Das ist aber jeweils nach Anleitung durchgelaufen.
Die Gesamtfunktion wurde da aber nie mehr danach geprüft, sprich da muss der Fehler liegen.
Hier geht auch noch was denke ich!Die Gesamtfunktion wurde da aber nie mehr danach geprüft, sprich da muss der Fehler liegen.
BlueKobold
Vom Problemfall sieht es aus, als ob nun ein "VLAN/vhid" Bit gesetzt wird beim Egress
Da wäre Sniffern oder ein Packet Capture über die Diagnostics in der Tat sinnvoll.Ohne jegliche VLAN Konfig auf den Geräten sollten auch niemals getaggte Frames zu sehen sein.
Denkbar wäre höchstens eine 802.1p Layer 2 Priorisierung die dann eine .1q VLAN ID Prinzip bedingt erzwingt aber das kann man dann nur am Trace sehen.
Hallo BlueKobold und Aqui,
da das Teil als LAN-2-LAN unterwegs ist (10.x auf 192.168.x) ist der Haken natürlich heraussen. Wir haben erst nachträglich die Fehlinfo (8 LAN Ports+getrennte 2*SFP) gesehen, was sich ja zu einem red. Switch ergeben hat, wodurch die 8 Kupfer Ports tot und ungenützt sind. In den vier ersten Versuchen mussten wir viele SFPs (Gigabit LR wäre notwendig gewesen) aussondern als "Geht nicht" und dazu Calls bei Netgate aufgegeben hatten, welche dann mit einem eigenen Eintrag in der Doku mit "aufgrund eines Treiberbugs im Intel 10G Adapters" gehen viele SFP/SFP+ nicht wie soll" erhalten haben (so vor gut einem Jahr). Daher nutzen wir nun die Zusatz 4Port Intel (igb) Karte. Daher der etwas ungewöhnliche Aufbau. Das ist aber unwahrscheinlich das Problem.
Kurz: ich habe am Freitag das CARP_LAN gelöscht (Traces kosten Zeit) und neu angelegt auf beiden Routern und "freie kommunikation" geht wieder sichtbar in beide Richtungen (LAN-Router).
Ein Export der neuen (CARP) Config und Vergleich zeigt keinen Unterschied...
Was noch nicht geht sind Pakete vom LAN zum WAN (beides CARP) (State ist jedesmal "CLOSED:SYN_SENT"). Auf der Gegenseite kommt erstmal gar nichts an.
WAN zu LAN geht.
Vom Gefühl her klingt das verwandt mit dem Originalproblem und klingt nach neu aufsetzen (Nicht zur Strafe, nur zur Übung") was aber nur VorOrt geht da NAC und fehlende Netzhoheit da interveniert.
da das Teil als LAN-2-LAN unterwegs ist (10.x auf 192.168.x) ist der Haken natürlich heraussen. Wir haben erst nachträglich die Fehlinfo (8 LAN Ports+getrennte 2*SFP) gesehen, was sich ja zu einem red. Switch ergeben hat, wodurch die 8 Kupfer Ports tot und ungenützt sind. In den vier ersten Versuchen mussten wir viele SFPs (Gigabit LR wäre notwendig gewesen) aussondern als "Geht nicht" und dazu Calls bei Netgate aufgegeben hatten, welche dann mit einem eigenen Eintrag in der Doku mit "aufgrund eines Treiberbugs im Intel 10G Adapters" gehen viele SFP/SFP+ nicht wie soll" erhalten haben (so vor gut einem Jahr). Daher nutzen wir nun die Zusatz 4Port Intel (igb) Karte. Daher der etwas ungewöhnliche Aufbau. Das ist aber unwahrscheinlich das Problem.
Kurz: ich habe am Freitag das CARP_LAN gelöscht (Traces kosten Zeit) und neu angelegt auf beiden Routern und "freie kommunikation" geht wieder sichtbar in beide Richtungen (LAN-Router).
Ein Export der neuen (CARP) Config und Vergleich zeigt keinen Unterschied...
Was noch nicht geht sind Pakete vom LAN zum WAN (beides CARP) (State ist jedesmal "CLOSED:SYN_SENT"). Auf der Gegenseite kommt erstmal gar nichts an.
WAN zu LAN geht.
Vom Gefühl her klingt das verwandt mit dem Originalproblem und klingt nach neu aufsetzen (Nicht zur Strafe, nur zur Übung") was aber nur VorOrt geht da NAC und fehlende Netzhoheit da interveniert.
Hallo BlueKobold und Aqui,
nach vielem hin und herprobiere (und keinem Fehler auf die Spur kommend) habe ich nun auch den WAN_CARP Konfig entfernt, vorher die NAT Forwardings entfernt, NAT outbound gelöscht, VIP weg; beim BackupRouter überprüft:OK; CARP wieder neu eingestellt, NAT Regeln erstellt, NAT outbound eingestellt; einmal neu gestartet; den "BRuder" überprüft ob er synced und geht wieder.
Vom verhalten muss sich beim NAT outbound was verklemmt haben, da die Pakete ja drüben nicht ankamen; da fand ich aber nichts was der damaligen CARP Anleitung widerspricht. Egal geht!
Danke der Hinweise; leider werde ich nicht fürs Netzwerken bezahlt sondern nur für's Datenretten.... Damit war ein sicher "interessantes" tracen nicht drinnen.
Gruß
Sam
nach vielem hin und herprobiere (und keinem Fehler auf die Spur kommend) habe ich nun auch den WAN_CARP Konfig entfernt, vorher die NAT Forwardings entfernt, NAT outbound gelöscht, VIP weg; beim BackupRouter überprüft:OK; CARP wieder neu eingestellt, NAT Regeln erstellt, NAT outbound eingestellt; einmal neu gestartet; den "BRuder" überprüft ob er synced und geht wieder.
Vom verhalten muss sich beim NAT outbound was verklemmt haben, da die Pakete ja drüben nicht ankamen; da fand ich aber nichts was der damaligen CARP Anleitung widerspricht. Egal geht!
Danke der Hinweise; leider werde ich nicht fürs Netzwerken bezahlt sondern nur für's Datenretten.... Damit war ein sicher "interessantes" tracen nicht drinnen.
Gruß
Sam
👍 👏
