Redundanz - Neustart einer Firewall setzt IPSec-Tunnel außer Gefecht

[A Former User]

Hallo zusammen,

ich bin seit kurzem in einer neuen Firma tätig und habe das vorhandene pfSense-Konstrukt übernommen.
Die Firewalls syncen (CARP / pfsync und XMLRPC) sich brav über ein exklusives Interfaces und bei einem Ausfall von Firewall X übernimmt Firewall Y nahtlos, jedoch nimmt das Unheil bei einem Neustart/Ausfall seinen Lauf.

Die IPSec-Tunnel werden zwar in der GUI als "aufgebaut" bzw. "connected" angezeigt, jedoch sehe ich bei den Phasen keine Pakete eingehen… manchmal gehen auch keine Pakete raus.

Ich bin technisch so versiert, dass ich weiß, wie ich an's Debugging rangehe (Logfiles, tcpdump etc.), und ich weiß auch, dass IPSec so gut wie nie rummotzt, außer man vergeigt die Einstellungen.

Die IPSec-Verbindung wird "zwischendurch" geNATet, kann da eventuell der Fehler liegen?
Ein Traceroute auf die IP des Remote Networks leitet mich ins WAN (Router -> DTAG-Backbone), was ja total falsch ist, weil der Tunnel nur IP-Adressen gemäß RFC1918 nutzt.

In der PfSense wird das NAT-Netzwerk laut Routingtable via lo0 geroutet, stimmt das so?

Jemand eine Idee, wo ich hier am besten ansetzen kann?

Vielen Dank und Grüße

[JeGr]

Hmm schwierig. Aber bei aufgebautem Tunnel und Ping von Hinter der pfSense auf ein RemoteNetz via Phase2 sollte nicht übers WAN laufen, das sieht dann eher so aus, als wäre das Netz nicht geroutet und wird dann ans Default GW weitergegeben.

Sind die Tunnel denn alle auf dem CARP Interface konfiguriert? (Phase1)
Kommen sie ggf. hoch wenn du IPSec durchtrittst und neu startest? Oder ggf. den Tunnel spezifisch neu startest?

Gruß Jens

[A Former User]

@JeGr:

Sind die Tunnel denn alle auf dem CARP Interface konfiguriert? (Phase1)
Kommen sie ggf. hoch wenn du IPSec durchtrittst und neu startest? Oder ggf. den Tunnel spezifisch neu startest?

Die PfSense meldet sich mit unserer (statischen) öffentlichen IP-Adresse des Internet-Anschlusses, also nix CARP.
Auch das durchtreten des IPSec-Services oder gar ein neustarten beider Firewalls (nacheinander) bringt keine Besserung und langsam aber sicher, bin ich mit meinem Latein am Ende.

[JeGr]

Die PfSense meldet sich mit unserer (statischen) öffentlichen IP-Adresse des Internet-Anschlusses, also nix CARP.

Warum "nix CARP"? pfSense sollte auch auf dem WAN eine CARP IP haben/sprechen, ansonsten macht das herzlich wenig Sinn bei einem Failover?

[A Former User]

@JeGr:

Warum "nix CARP"? pfSense sollte auch auf dem WAN eine CARP IP haben/sprechen, ansonsten macht das herzlich wenig Sinn bei einem Failover?

Entschuldige die Verwirrung.
Die Redundanz wird lediglich Intern umgesetzt. Sprich Firewall 1 fällt aus, Firewall 2 übernimmt.
Eine WAN-Redundanz ist nicht gegeben. (1x Internetanschluss)

[JeGr]

Eine WAN-Redundanz ist nicht gegeben. (1x Internetanschluss)

Das hat doch mit einem Internet Anschluß ja nichts zu tun. Das WAN sollte/muss genauso redundant sein. Ansonsten könnte die 2. Firewall kaum übernehmen weil sie kein WAN hat. Also muss es sinnvollerweise auch auf fwl2 ein WAN geben mit IP. Und die sollte eben genauso via CARP sicher sein. Es wäre vielleicht langsam an der Zeit, dass du ein wenig mehr über das Netz und den Aufbau an Worten verlierst, sonst geht das hier noch 10x hin und her ohne Ergebnis. Vielleicht mal einfach entweder die Interfaces und die Regeln sowie NAT posten oder eben zeichnen - wir haben dafür extra so coole ASCII Grafiken - ansonsten hilft Gliffy.com oder ähnliches.

Gruß

[A Former User]

Hallo,

entschuldige bitte die Verspätung. :)
Ich hoffe, die angehängten Screenshots helfen dir, das derzeitige Konstrukt zu verstehen.
Die CARP-Einstellungen stammen noch von meinem Vorgänger. Ich kenne mich mit CARP/pfsync noch nicht so gut aus. (Bin aber fleißig am pfSense-Ebook lesen! :) )

Anmerkung:

• der linke "Strang" hängt an der normalen Stromversorgung des Serverschranks.

• der rechte "Strang (fw2 etc.) hängt an einer USV

Generell müsste ich mir aber mal die Zeit nehmen, das Netzwerk neu aufzubauen, und Stolpersteine (Siehe Switch-"Redundanz") aus dem Weg zu räumen.

[JeGr]

Puuuuh :/

Da sind gleich mehrere Dinge so BAD, dass man überlegen sollte, das gleich mal richtig aufzuräumen… Uff

Also allein bei der VIP Liste! Warum zur Hölle:

• Gibt es in DESKTOP zwei IPs, eine mit CARP, eine mit ALIAS die noch dazu eine falsche/andere Subnet Mask trägt!?
• Gibt es zig verschiedene unterschiedliche Mini-Netze auf dem LAN ohne VLAN Trennung nur mit IP auf der pfSense?
• Und warum sind die in totalem Mischmasch mal als CARP und dann als Alias aufgelegt?

Das sieht mir nach einer Konfig aus, die richtig gruselig schief geht/gehen kann wenn mal ein Failover kommt, denn da passt für mein Empfinden so gar nichts zusammen. Allein die Dutzend IPs auf dem LAN - mehrere IP Ranges in der gleichen Broadcast Domain, das macht man heute nicht mehr. No Go! Allein schon wegen DHCP und Co, aber auch weil es mit VLANs so viel einfacher ist, da eine saubere Trennung drinzuhaben.
Zudem denke ich, dass da einige IPs als Alias drin sind, die eigentlich CARP Aliase sein müssten. Da wäre es vielleicht sinnvoll erstmal auseinander zu basteln, was da eigentlich der SOLL Zustand sein sollte und zu schauen, ob das so überhaupt passt. :)

Gruß

[A Former User]

@JeGr:

Da sind gleich mehrere Dinge so BAD, dass man überlegen sollte, das gleich mal richtig aufzuräumen… Uff

Also allein bei der VIP Liste! Warum zur Hölle.

Vielen Lieben Dank, dass du dir die Zeit nimmst und so einen Haufen "Elend" analysierst. :)
Wie gesagt, ist nicht auf meinem Mist gewachsen, wurde da "reingeschubst".

Was in nächster Zeit im Unternehmen ansteht:

• Umstellung auf IP-Anschluss (VDSL-Anschluss inkl SIP-Trunk für VoIP und separaten VDSL-Anschluss für "Internet")

• Beschaffung neuer, leistungsstärkerer Appliances (19")

Da wir die Appliances bald austauschen möchten, würde sich da eventuell eine Virtualisierung lohnen? Die Infrastruktur läuft bereits auf den ESXI-Server, nur die Firewalls stehen noch als "Blech" da.
Falls man diese virtualisiert, müsste ich aber zusätzliche NIC's einbauen, und selbst dann, dürften die Interfaces wohl nicht reichen.
Was hältst du von dem Thema "pfSense virtualisieren" ?

Bezüglich Ideen.
Ich plapper einfach mal drauf los, und zeig mal meinen bisherigen Gedankengang.. eventuell kann man diesen dann mit neuen Appliances verbinden.
Sprich Neue Hardware = neues (sinnvolles) Konstrukt sozusagen. :)

So kompliziert ist unser Unternehmensnetzwerk auch nicht, jedoch wurde da von meinen Vorgängern null dokumentiert und ich muss nun schauen, dass ich da Ordnung reinbekomme.
Ein paar Interfaces, Netze und VLANs können nicht all zu schwierig sein, wenn man das "neu" aufbauen bzw. aufräumen möchte.

Meine ersten Ideen wären:

• Einheitliche Netzgrößen von /24

• Neue VLAN-Vergabe

• Netze in eigene VLANs packen (Segmentierung)

• DHCP nur dort aktivieren, wo nötig (Desktop-Netz)

• Herstellen einer Layer2-Redundanz (Siehe pfsense Book Seite 543)

• OpenVPN-Tunnel zum RZ auf tun umstellen (läuft derzeit noch mit tap)

Interfaces (Nicht alle physikalisch, da nur 6x Ports vorhanden sind):
Vermutlich pack ich LAN, Management und Testing auf ein physikalisches Interface und arbeite dort dann mit VLANs.

• WAN

• LAN

• Management

• Desktop

• Testing

• DMZ

• WLAN

• CARP

Netze:

• WAN-Netz -> 192.168.178.0/24

• LAN-Netz -> 10.254.161.0/24

• Management-Netz -> 10.254.162.0/24

• Desktop-Netz -> 10.254.163.0/24

• Testing-Netz -> 10.254.164.0/24

• DMZ-Netz -> 10.254.165.0/24

• WLAN-Netz -> 10.254.167.0/24

• CARP-Netz -> 172.16.1.0/24

Die jeweiligen CARP-VIP's sind jeweils die niedrigsten IP-Adressen (.1) und für fw1 und fw2 dann jeweils die zweite bzw. dritte IP-Adresse des jeweiligen Netzes.

VLANs:

• WAN -> bekommt kein VLAN, warum auch?

• LAN ->10

• MGMT ->11

• Desktop ->12

• Testing -> 13

• DMZ ->14

• WLAN ->15 (Internes WLAN) / 16 (Gast-WLAN)

• CARP -> Kein VLAN, da dediziertes Interface und Abriegelung durch Firewallregeln

Ich bin mir nicht ganz sicher, ob es sinnvoll ist, das Testing-Netz vom LAN-Netz zu trennen, da dort keine "bösen" Dinge laufen, sondern nur Testsysteme für QA laufen. Was meint ihr?

Auch werde ich zeitnah alle Regeln von Hand durchgehen, notieren welche "überlebensnotwendig" sind und dann entsprechend portieren, damit ich da auch mal einen sauberen Stand hinbekomme.

Die größte Aufgabe dürfte dann die Umkonfiguration der Switches bzw. Port sein.

Wäre das Konstrukt soweit erstmal "stolperfrei" ? :)

Grüße

*nach einem stromlos machen, muss man ab und an erstmal 5 Minuten warten, bis die Kondensatoren leer sind, ansonsten will das Teil nicht starten (Keine Netgate-Appliances / Irgendwelche No-Name-Dinger). Jedes pfSense-Update macht Probleme. Mal funktioniert OpenVPN nicht mehr, mal IPSec… bei meiner pfSense@home funktioniert alles wie geschmiert... komische Dinger. :)

[JeGr]

Vielen Lieben Dank, dass du dir die Zeit nimmst und so einen Haufen "Elend" analysierst. :)

Elend hab ich woanders gesehen, das hier ist einfach … naja hysterisch gewachsen ;)

Wie gesagt, ist nicht auf meinem Mist gewachsen, wurde da "reingeschubst".

Wird man leider nur allzu oft :)

Da wir die Appliances bald austauschen möchten, würde sich da eventuell eine Virtualisierung lohnen? Die Infrastruktur läuft bereits auf den ESXI-Server, nur die Firewalls stehen noch als "Blech" da.

Das hat normalerweise auch seinen Grund ;)

Falls man diese virtualisiert, müsste ich aber zusätzliche NIC's einbauen, und selbst dann, dürften die Interfaces wohl nicht reichen.

Warum das? Die Interfaces sind ja genauso virtuell oder willst du NICs 1:1 durchreichen?

Was hältst du von dem Thema "pfSense virtualisieren" ?

Ich persönlich bin "in production" kein großer Fan davon. Man kanns gerne tun, ich würde es eben aus meiner Sicht nicht empfehlen. Ich hatte den Fall schon zu oft, dass die Virtualisierungsumgebung dann auch nicht so top war und dann fällt dir im dümmsten Fall nicht nur der ganze Cluster aus, sondern auch noch dein kompletter Internet Zugang, weil die Firewall mit abschmiert.
Zudem haben wir dank Meltdown und Spectre jetzt auch schon die ersten Kandidaten und Generation von Lücken, die eben auf Hardware ansetzt aber dummerweise gerade bei Shared- und Cloud/VM Umgebungen richtig böse wird. Und da es in der Vergangenheit auch schon einmal möglich war, aus der VM auszubrechen und zum HV oder zu einer anderen VM zu kommen... wenn man das noch mit Meltdown/Spectre kombiniert und damit aus einer VM den Inhalt einer anderen ausliest wird das unschön.

Wenn man sich angelesen hat, wie die pfSense Supporter die Lücken in Bezug auf ihre Hardware + Software sehen, dann zeigt sich: durch den Use Case und die begrenzte Angriffsfläche ist das eingeschätzte Risiko der Lücken auf der eigenen Hardware eher gering. Läuft der Kram in einer VM auf einem anfälligen Cluster? Puh keine Ahnung... Ist eine Abwägungssache und muss man komplett durchdenken etc. so einfach abzutun ist die Frage auf jeden Fall nicht, was für ein Impact es ggf. haben kann. Sollte ggf. auch jemand entscheiden der eine Ebene über einem sitzt ;) Unsere Entscheidung ist ganz klar Funktionen und Sicherheitsringe nicht zu vermischen. Deshalb physikalische Maschinen.

Meine ersten Ideen wären:
Einheitliche Netzgrößen von /24

Jap, absolut!

Neue VLAN-Vergabe

Und wie. Am besten gleich mit dem Punkt vorher zusammen als Must-Have

Netze in eigene VLANs packen (Segmentierung)

Und den gleich mit dazu packen!

DHCP nur dort aktivieren, wo nötig (Desktop-Netz)

Relativ wenig Impact, aber sicher macht es Sinn Dienste auf das zu beschränken was benötigt wird.

Herstellen einer Layer2-Redundanz (Siehe pfsense Book Seite 543)

Da ich das Buch nicht auswendig kann ;) -> CARP Cluster?

OpenVPN-Tunnel zum RZ auf tun umstellen (läuft derzeit noch mit tap)

Was zur Hölle... warum macht man einen Tunnel in ein DC als Bridge? :o

Die jeweiligen CARP-VIP's sind jeweils die niedrigsten IP-Adressen (.1) und für fw1 und fw2 dann jeweils die zweite bzw. dritte IP-Adresse des jeweiligen Netzes.

Relativ egal, hauptsache ein Standard und den ordentlich durchziehen. Ein alter Chef von mir hat das mal so formuliert: "Die ersten 10 IPs jedes Netzes gehören mir. Finger weg. Sonst Tote :D" Manche wollen es am Ende des Netzes. Egal, aber einheitlich sollte es sein.

LAN-Netz -> 10.254.161.0/24
...
LAN ->10

Würde ich nicht. Wenn du eh alles neu vergibst, dann mach es dir leicht, nimm eine Maske von vorne und vergib als 3. Stelle ein Netz und nutz das als VLAN. Um bei dir zu bleiben:

LAN: 10.254.161.0/24, VLAN 161
DMZ: 10.254.164.0/24, VLAN 164

etc.

Ich weiß noch nicht was bei dir LAN vs. Desktop darstellt und was du in MGMT hast. Da viele Geräte untagged/VLAN 0/VLAN 1 als Default/Management nehmen, würde ich das als Management nutzen und alles andere VLANen (außer der WAN Seite, die nur bei Bedarf). CARP ist eigentlich oft ein direktes Kabel zwischen den Firewalls, manchmal auf nem Switch. Wenn auf Switch - eigenes VLAN. Regel gibts auf CARP eigentlich nicht, da da außer den beiden FWs eh nichts drin sein sollte.

nach einem stromlos machen, muss man ab und an erstmal 5 Minuten warten, bis die Kondensatoren leer sind, ansonsten will das Teil nicht starten
Jedes pfSense-Update macht Probleme. Mal funktioniert OpenVPN nicht mehr, mal IPSec... bei meiner pfSense@home funktioniert alles wie geschmiert... komische Dinger.

Klingt wirklich eher nach "recycleter Hardware" oder seltsamer Einrichtung. Wüsste nicht ob ich davon überhaupt Konfiguration übernehmen würde oder nicht einfach neue ordentliche und vernünftige Kisten und neue Installation und gib ihm. Würde wohl weniger Probleme machen als die verkorkste Konfig mitzunehmen ;)

Gruß

[A Former User]

Und nochmals.
Vielen Lieben Dank für deine Zeit und deinen Hirnschmalz! :)

@JeGr:

Was hältst du von dem Thema "pfSense virtualisieren" ?

[…]

Stimmt.
Wenn mir die Infra um die Ohren fliegt, würd's auch das SAN zerhauen.
SAN "kaputt" = pfsense kaputt.

Mit Blech dürfte ich wohl am besten fahren. :)

@JeGr:

Meine ersten Ideen wären:
Einheitliche Netzgrößen von /24

Jap, absolut!

Check.

@JeGr:

Neue VLAN-Vergabe

Und wie. Am besten gleich mit dem Punkt vorher zusammen als Must-Have

Check.

@JeGr:

Netze in eigene VLANs packen (Segmentierung)

Und den gleich mit dazu packen!

Check.

@JeGr:

DHCP nur dort aktivieren, wo nötig (Desktop-Netz)

Relativ wenig Impact, aber sicher macht es Sinn Dienste auf das zu beschränken was benötigt wird.

Der Sinn hierbei ist eher, dass nur Desktop-Rechner einen DHCP-Lease erhalten.
Server, Switches etc. werden bei uns statisch konfiguriert, weswegen hier kein DHCP benötigt wird.

@JeGr:

Herstellen einer Layer2-Redundanz (Siehe pfsense Book Seite 543)

Da ich das Buch nicht auswendig kann ;) -> CARP Cluster?

Nicht? ;)
Aber Jap, ist das Kapitel bezüglich CARP-Cluster.

@JeGr:

OpenVPN-Tunnel zum RZ auf tun umstellen (läuft derzeit noch mit tap)

Was zur Hölle… warum macht man einen Tunnel in ein DC als Bridge? :o

Frag nicht.. :)

@JeGr:

Die jeweiligen CARP-VIP's sind jeweils die niedrigsten IP-Adressen (.1) und für fw1 und fw2 dann jeweils die zweite bzw. dritte IP-Adresse des jeweiligen Netzes.

Relativ egal, hauptsache ein Standard und den ordentlich durchziehen. Ein alter Chef von mir hat das mal so formuliert: "Die ersten 10 IPs jedes Netzes gehören mir. Finger weg. Sonst Tote :D" Manche wollen es am Ende des Netzes. Egal, aber einheitlich sollte es sein.

Der Spruch des Chef's hört sich gut an, muss ich mir merken. ;)

@JeGr:

LAN-Netz -> 10.254.161.0/24
…
LAN ->10

Würde ich nicht. Wenn du eh alles neu vergibst, dann mach es dir leicht, nimm eine Maske von vorne und vergib als 3. Stelle ein Netz und nutz das als VLAN. Um bei dir zu bleiben:

LAN: 10.254.161.0/24, VLAN 161
DMZ: 10.254.164.0/24, VLAN 164

etc.

Das würde sich aber dann beim WLAN beißen. (Unterscheidung "Intern" und Gast-WLAN)
Intern = Zugriff auf Desktop-Netz und Zugriff aufs Internet.
Gast-WLAN ist meist für "Besucher", die WLAN brauchen, um rudimentäre Dinge damit anstellen zu können (HTTP/HTTPS/IMAP/SMTP), ohne dass sie im gleichen VLAN bzw. Netzwerk wie bspw. die Infrastruktur landen.

@JeGr:

Ich weiß noch nicht was bei dir LAN vs. Desktop darstellt und was du in MGMT hast. Da viele Geräte untagged/VLAN 0/VLAN 1 als Default/Management nehmen, würde ich das als Management nutzen und alles andere VLANen (außer der WAN Seite, die nur bei Bedarf). CARP ist eigentlich oft ein direktes Kabel zwischen den Firewalls, manchmal auf nem Switch. Wenn auf Switch - eigenes VLAN. Regel gibts auf CARP eigentlich nicht, da da außer den beiden FWs eh nichts drin sein sollte.

Die Namen sind eventuell etwas "unglücklich" gewählt.
LAN = Server-Netz (Backup-Server, Storage etc.)
MGMT = Ist an sich ein Netz für Management-Zugänge, sprich nur aus diesem Netz kommst du bspw. auf die GUI der Switches etc.
Desktop = Bürorechner bzw. Drucker

@JeGr:

Klingt wirklich eher nach "recycleter Hardware" oder seltsamer Einrichtung. Wüsste nicht ob ich davon überhaupt Konfiguration übernehmen würde oder nicht einfach neue ordentliche und vernünftige Kisten und neue Installation und gib ihm. Würde wohl weniger Probleme machen als die verkorkste Konfig mitzunehmen ;)

Ich hatte nicht vor, die Konfig zu übernehmen, sondern parallel neue Hardware beschaffen und neue Konfig aufbauen, ohne Import der alten.
Anschließend an einem Wochenende oder Abends mal die "neuen" Firewalls probeweise live-nehmen um zu schauen, wo's noch klemmt etc.

Grüße

[JeGr]

Das würde sich aber dann beim WLAN beißen. (Unterscheidung "Intern" und Gast-WLAN)

Warum? Beides sind für mich unterschiedliche VLANs demzufolge dann auch unterschiedliche IP Ranges. Damit ist es auch möglich, WiFi-LAN im Wunschfall ggf. zu Bridgen oder ordentlich zu routen und auf den WiFi-Guest Interface dann bspw. ein Portal o.ä. aufzuziehen wenn gewünscht.

Die VLAN IDs und IP Ranges waren jetzt nur Demo, aber ich würde das eben über das dritte IP Segment codieren und dann einheitlich machen, dann hat man es im Debugging Fall auch leichter.

Ich hatte nicht vor, die Konfig zu übernehmen, sondern parallel neue Hardware beschaffen und neue Konfig aufbauen, ohne Import der alten.

Guter Plan! Hört sich solide an. Jetzt nur noch runterbrechen in kleinere Häppchen wie Hardware beschaffen, Testaufbau, etc. und loslegen :)