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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2279376032
Url: https://administrator.de/contentid/2279376032
Ausgedruckt am: 05.11.2024 um 00:11 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.