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
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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4173107487
Url: https://administrator.de/contentid/4173107487
Ausgedruckt am: 08.11.2024 um 21:11 Uhr
18 Kommentare
Neuester Kommentar
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!
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 :
Wireguard Allowed-IPs auf der PF1 ergänzen
Firewall Regel auf PF1 zum Markieren von eingehendem Traffic aus dem Wireguard-Interface
Firewall Regel auf PF1 für das leiten der markierten Pakete über das Wireguard Gateway (Policy Routing)
Ist das erledigt kannst du das Outbound-NAT auf PF2 entfernen und das Port-Forwarding der PF2 wird transparent geroutet.
Grüße Uwe
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.
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.
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.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?
Nein. Wenn du von PF2 das LAN hinter PF1 direkt erreichst ist es OK, dann stimmt das.Also: 0.0.0.0/0 auf WG PF2 zusätzlich als static Route?
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.
Ja.
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 😉
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 😉
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.Du kannst ja mal testen was bei dir für Adressen bei einem Capture aufgelistet werden. Die public IPs sind nicht darunter.
Die States spiegeln die eingehende DSTNAT Session ebenfalls einwandfrei wieder.