18
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
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: 4173107487
Url: https://administrator.de/forum/routing-zwischen-zwei-pfsense-nutzung-von-public-ip-4173107487.html
Ausgedruckt am: 22.12.2024 um 01:12 Uhr
18 Kommentare
Neuester Kommentar
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!
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!
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
2Zitat von @colinardo:
Servus Spirit,
du kannst das wie im oben verlinkten Beitrag schon geschrieben auch ohne doppeltes NAT machen. Dazu brauchst du nur 3 Dinge:
Das sieht dann in der Praxis so aus :
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:
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
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.
Irgend eine Kleinigkeit scheint noch zu fehlen oder ist in meinem Setup anders. Ohne die Outbound NAT Rule funktioniert es so noch nicht.
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.
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.
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.
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?
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.
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.
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.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.
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.
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 😉
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.
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.
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.
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.
👍 Immer gerne.
Beim DSTNAT ändert sich eingehend nur die Zieladresse , die Quelladresse bleibt intern immer die gleiche (externe IP des Zugriffsclients)!
Beim DSTNAT ändert sich eingehend nur die Zieladresse , die Quelladresse bleibt intern immer die gleiche (externe IP des Zugriffsclients)!
Zitat von @colinardo:
👍 Immer gerne.
Beim DSTNAT ändert sich eingehend nur die Zieladresse , die Quelladresse bleibt intern immer die gleiche (externe IP des Zugriffsclients)!
👍 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.
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.
Ja, es passt schon. Wir reden zwar etwas an einander vorbei, aber die Sessions mit public IP werden mir nur im "promiscuous mode" angezeigt.
Wie gesagt, es funktioniert jetzt alles. Danke nochmal.
Wie gesagt, es funktioniert jetzt alles. Danke nochmal.
