spirit-of-eli
Goto Top

Routing zwischen zwei PfSense - Nutzung von public IP

Moin zusammen,

ich habe zwei PfSense Installationen, jeweils mit einem WAN Zugang.
Im folgenden genannt PF1 und PF2.

PF1: ein normaler Heimanschluss.
PF2: hat eine statische IP.

Beide sind per Wireguard verbunden und das local routing funktioniert ohne Problem.
Tatsächlich kann ich auch z.b. den Traffic eines local Interface auf PF1 über PF2 ins Internet leiten.

Was nicht funktioniert ist eingehendes NAT von PF2 zu einem local Interface auf PF1.
Mein Test bestand darin, auf PF2 das Portforwarding anzulegen. Der Traffic wird auch durch den Tunnel geleitet. Allerdings scheint es Probleme mit den Antwortpaketen zu geben.
Wie gesagt, die normale Kommunikation ausgehend funktioniert. Eingehend bekomme ich den Weg nicht realisiert.

Es werden auch keine Pakete geblockt. darin liegt es definitiv nicht. Ich schätze das, dass Routing fehlerhaft ist.
Oder die PfSense nicht in der Lage ist, ihre NAT Tabelle mit Zielen außerhalb Ihres Netzwerks zu bedienen.

Bekomme ich das nur mit einem GRE Tunnel in den Griff?
Geht dies ausschließlich per 1:1NAT ?
Kann jemand das eigentliche Problem nachvollziehen?

Ich bin mir durchaus im klaren, dass die Formulierung gerade etwas zu wünschen übrig lässt.
Ich arbeite daran.

Gruß
Spirit

Content-Key: 4173107487

Url: https://administrator.de/contentid/4173107487

Printed on: December 4, 2022 at 20:12 o'clock

Mitglied: 4091525239
Solution 4091525239 Oct 06, 2022 at 11:56:30 (UTC)
Goto Top
Member: Spirit-of-Eli
Spirit-of-Eli Oct 06, 2022 updated at 12:16:47 (UTC)
Goto Top
Danke schön, der Anstoß hat gefehlt.
Ich hoffe der Blödsinn bleibt dann nur eine Übergangslösung bei mir. Das ist total grottig mit dem double NAT.

Zusammenfassung:
Source NAT (Outbound) auf der PF2 hat gefehlt. Durch Änderung der Source Adresse auf die IP der PF2 im Wireguard Tunnel werden die Antwortpakete korrekt über den Tunnel zur PF2 rausgeschickt.

##Fail2Ban auf der Ressource ist damit hinfällig. Bzw. blockt natürlich die komplette Kommunikation. Schlägt bei mir zum Glück nie an.

Vielen Dank nochmal!
Member: colinardo
Solution colinardo Oct 06, 2022 updated at 17:04:34 (UTC)
Goto Top
Zitat von @Spirit-of-Eli:

Danke schön, der Anstoß hat gefehlt.
Ich hoffe der Blödsinn bleibt dann nur eine Übergangslösung bei mir. Das ist total grottig mit dem double NAT.

Zusammenfassung:
Source NAT (Outbound) auf der PF2 hat gefehlt. Durch Änderung der Source Adresse auf die IP der PF2 im Wireguard Tunnel werden die Antwortpakete korrekt über den Tunnel zur PF2 rausgeschickt.

##Fail2Ban auf der Ressource ist damit hinfällig. Bzw. blockt natürlich die komplette Kommunikation. Schlägt bei mir zum Glück nie an.

Vielen Dank nochmal!

Servus Spirit,

du kannst das wie im oben verlinkten Beitrag schon geschrieben auch ohne doppeltes NAT machen. Dazu brauchst du nur 3 Dinge:

  • Auf der PF1 musst du die Allowed-IPs um 0.0.0.0/0 ergänzen
  • Auf PF1 eine Firewall Regel auf dem Wireguard-Interface die den eingehenden Traffic von der PF2 mit einem Tag versieht
  • Auf PF1 eine weitere Firewall Regel auf dem LAN-Interface in dem sich das Ziel der Portweiterleitung befindet, welche sich auf das Tag der vorherigen Regel bezieht und das Gateway auf den Wireguard-Tunnel setzt.

Das sieht dann in der Praxis so aus :

back-to-topWireguard Allowed-IPs auf der PF1 ergänzen


screenshot

back-to-topFirewall Regel auf PF1 zum Markieren von eingehendem Traffic aus dem Wireguard-Interface


screenshot

back-to-topFirewall Regel auf PF1 für das leiten der markierten Pakete über das Wireguard Gateway (Policy Routing)


screenshot

Ist das erledigt kannst du das Outbound-NAT auf PF2 entfernen und das Port-Forwarding der PF2 wird transparent geroutet.

Grüße Uwe
Member: Spirit-of-Eli
Spirit-of-Eli Oct 06, 2022 at 17:38:57 (UTC)
Goto Top
Zitat von @colinardo:

Zitat von @Spirit-of-Eli:

Danke schön, der Anstoß hat gefehlt.
Ich hoffe der Blödsinn bleibt dann nur eine Übergangslösung bei mir. Das ist total grottig mit dem double NAT.

Zusammenfassung:
Source NAT (Outbound) auf der PF2 hat gefehlt. Durch Änderung der Source Adresse auf die IP der PF2 im Wireguard Tunnel werden die Antwortpakete korrekt über den Tunnel zur PF2 rausgeschickt.

##Fail2Ban auf der Ressource ist damit hinfällig. Bzw. blockt natürlich die komplette Kommunikation. Schlägt bei mir zum Glück nie an.

Vielen Dank nochmal!

Servus Spirit,

du kannst das wie im oben verlinkten Beitrag schon geschrieben auch ohne doppeltes NAT machen. Dazu brauchst du nur 3 Dinge:

  • Auf der PF1 musst du die Allowed-IPs um 0.0.0.0/0 ergänzen
  • Auf PF1 eine Firewall Regel auf dem Wireguard-Interface die den eingehenden Traffic von der PF2 mit einem Tag versieht
  • Auf PF1 eine weitere Firewall Regel auf dem LAN-Interface in dem sich das Ziel der Portweiterleitung befindet, welche sich auf das Tag der vorherigen Regel bezieht und das Gateway auf den Wireguard-Tunnel setzt.

Das sieht dann in der Praxis so aus :

back-to-topWireguard Allowed-IPs auf der PF1 ergänzen


screenshot

back-to-topFirewall Regel auf PF1 zum Markieren von eingehendem Traffic aus dem Wireguard-Interface


screenshot

back-to-topFirewall Regel auf PF1 für das leiten der markierten Pakete über das Wireguard Gateway (Policy Routing)


screenshot

Ist das erledigt kannst du das Outbound-NAT auf PF2 entfernen und das Port-Forwarding der PF2 wird transparent geroutet.

Grüße Uwe

Danke Uwe! Die Lösung klingt sehr gut und wird sofort getestet.
Damit ist ja dann ein vernünftiges zwei Wege Setup möglich. Ich habe mich vorher noch nicht so eingehend mit den Tags beschäftigt.

Feedback folgt.
Member: Spirit-of-Eli
Spirit-of-Eli Oct 06, 2022 at 18:34:23 (UTC)
Goto Top
Irgend eine Kleinigkeit scheint noch zu fehlen oder ist in meinem Setup anders. Ohne die Outbound NAT Rule funktioniert es so noch nicht.
Member: colinardo
Solution colinardo Oct 06, 2022 updated at 20:02:25 (UTC)
Goto Top
Zitat von @Spirit-of-Eli:

Irgend eine Kleinigkeit scheint noch zu fehlen oder ist in meinem Setup anders. Ohne die Outbound NAT Rule funktioniert es so noch nicht.

Hast du auch die statische Route zum Netz hinter PF1 auf der PF2 gesetzt? Läuft hier ansonsten im Test einwandfrei.
Member: Spirit-of-Eli
Spirit-of-Eli Oct 06, 2022 at 20:10:14 (UTC)
Goto Top
Meinst du die für das Transfernetz? Weil Routing technisch habe ich über Wireguard kein Problem.

Oder muss ich das Pendant zum Peer Eintrag ebenfalls mit einer statischen Route abbilden?

Also: 0.0.0.0/0 auf WG PF2 zusätzlich als static Route?

Denn das WAN Routing per PBR läuft ohne solch ein Eintrag ohne Probleme.
Member: colinardo
Solution colinardo Oct 06, 2022 updated at 20:16:01 (UTC)
Goto Top
Zitat von @Spirit-of-Eli:

Meinst du die für das Transfernetz? Weil Routing technisch habe ich über Wireguard kein Problem.
Nein, das liegt ja direkt an dafür braucht es keine Route.
Oder muss ich das Pendant zum Peer Eintrag ebenfalls mit einer statischen Route abbilden?

Also: 0.0.0.0/0 auf WG PF2 zusätzlich als static Route?
Nein. Wenn du von PF2 das LAN hinter PF1 direkt erreichst ist es OK, dann stimmt das.
Member: Spirit-of-Eli
Spirit-of-Eli Oct 06, 2022 at 20:32:41 (UTC)
Goto Top
Ja, das ist alles der Fall. Dann habe ich das auch richtig verstanden.

Ich tag den Traffic auf PF1 eingehend.
Und für den Rückweg wird der Traffic tagged per PBR in den Tunnel geschoben.
Dennoch funktioniert es noch nicht.

Gibt es eine Option sich den Traffic bei einer statefull Session anzeigen zu lassen?
Sonst muss ich morgen mal einen Trace auf dem LAN interface bei PF1 mitschneiden.
Member: colinardo
Solution colinardo Oct 06, 2022 updated at 20:48:53 (UTC)
Goto Top
Hast du auf der PF2 im Outbound NAT auch das Netz hinter der PF1 als Masquerade am WAN-Port eingetragen? Das muss dort auch rein.
Gibt es eine Option sich den Traffic bei einer statefull Session anzeigen zu lassen?
Nimm Wireshark oder TCPDump oder den Sniffer der pfsense dann siehst du eventuell fehlerhaftes asynchrones Routing.
Member: Spirit-of-Eli
Spirit-of-Eli Oct 06, 2022 at 20:48:44 (UTC)
Goto Top
Zitat von @colinardo:

Hast du auf der PF2 im Outbound NAT auch das Netz hinter der PF1 als Masquerade eingetragen? Das muss dort auch rein.

Meinst du auf PF2 in Richtung WAN. Dafür ist eine Regel angelegt.
Aus dem LAN von PF1 komm ich per PBR über PF2 ins WAN.

Eingehend, von PF2 in den WG Tunnel habe ich die Rule nun deaktiviert.
Ist das der Fehler? Ich habe das so verstanden, dass ich diese Rule nur brauchen wenn ich den Traffic nicht tagge, damit käme alles dann ja mit der Transfer IP von dem WG Tunnel im LAN an.
Member: colinardo
Solution colinardo Oct 06, 2022 updated at 20:56:01 (UTC)
Goto Top
Zitat von @Spirit-of-Eli:
Meinst du auf PF2 in Richtung WAN. Dafür ist eine Regel angelegt.
Ja.
Aus dem LAN von PF1 komm ich per PBR über PF2 ins WAN.
Ok.
Ich habe das so verstanden, dass ich diese Rule nur brauchen wenn ich den Traffic nicht tagge, damit käme alles dann ja mit der Transfer IP von dem WG Tunnel im LAN an.
Richtig.
Verfolge einfach die Pakete im Gedanken wie deren Ziel und Quelladressen nach der Verarbeitung aussehen, dann ist es eigentlich ganz logisch.
Ansonsten poste doch deine FW-Config noch hier, ich schaue dann morgen mal drüber.

Muss jetzt langsam mal nach Hause sonst kriege ich Prügel 😉
Member: Spirit-of-Eli
Spirit-of-Eli Oct 06, 2022 at 20:59:38 (UTC)
Goto Top
Guter Plan. Ich habe heute auch schon einige Stunden auf der Uhr.

Die Funktion mit dem "tagged" Rückweg will noch nicht ganz in meinen Kopf.
Ich mache morgen mal ein paar Bilder und hänge ggf einen Trace an.
Member: Spirit-of-Eli
Spirit-of-Eli Oct 07, 2022 updated at 08:19:07 (UTC)
Goto Top
Ich habe das Problem nun lösen können. Anscheint wurde meine Test IP durch Snort geblockt.
Vielen Dank noch mal für den Tipp!

Was mir allerdings auffällt ist, dass bei einem Packet Capture keine externen IPs aufgelistet werden wenn diese durch NAT in der Session von PF2 angepasst wurden. Wenn ich jetzt auf PF1 auf dem LAN Interface ein Capture starte, sehe ich nur lokale Sessions.
Ist für das Thema hier allerdings nicht kriegsentscheident.
Member: colinardo
colinardo Oct 07, 2022 updated at 08:24:37 (UTC)
Goto Top
👍 Immer gerne.

Beim DSTNAT ändert sich eingehend nur die Zieladresse , die Quelladresse bleibt intern immer die gleiche (externe IP des Zugriffsclients)!
Member: Spirit-of-Eli
Spirit-of-Eli Oct 07, 2022 at 08:26:51 (UTC)
Goto Top
Zitat von @colinardo:

👍 Immer gerne.

Beim DSTNAT ändert sich eingehend nur die Zieladresse , die Quelladresse bleibt intern immer die gleiche (externe IP des Zugriffsclients)!

Du kannst ja mal testen was bei dir für Adressen bei einem Capture aufgelistet werden. Die public IPs sind nicht darunter.
Member: colinardo
colinardo Oct 07, 2022 updated at 08:40:05 (UTC)
Goto Top
Zitat von @Spirit-of-Eli:
Du kannst ja mal testen was bei dir für Adressen bei einem Capture aufgelistet werden. Die public IPs sind nicht darunter.
Habe ich - wie erwartet ändert sich die SRC IP nicht (egal ob an den pfsensen oder direkt am Client), wäre ja auch sonderlich denn dann würde das ganze ja überhaupt nicht funktionieren. Da hast du entweder am falschen Interface gesniffert, oder einen Dienst auf den pfSensen aktiv der mir hier nicht bekannt ist.
Die States spiegeln die eingehende DSTNAT Session ebenfalls einwandfrei wieder.
Member: Spirit-of-Eli
Spirit-of-Eli Oct 07, 2022 at 08:48:55 (UTC)
Goto Top
Ja, es passt schon. Wir reden zwar etwas an einander vorbei, aber die Sessions mit public IP werden mir nur im "promiscuous mode" angezeigt.
unbenannt

Wie gesagt, es funktioniert jetzt alles. Danke nochmal.