1:1 Nat geht nicht
-
Hallo,
ich habe folgendes Problem:
Ich muss einen Rechner aus dem LAN mit einem Dienst der über ein Routed IPSEC-VPN verbunden ist verbinden.
Dafür muss sich der Rechner aus dem LAN mit einer anderen IP dort melden, die in keinem IP-Bereich irgendeiner Schnittstelle ist.
Ich habe dafür eine virtuelle IP auf der LAN-Schnittstelle eingerichtet und ein 1:1 NAT für die LAN-Adresse, aber trotzdem kommt er immer mit der LAN-Adresse und ein NAT scheint nicht statt zu finden.
Was mache ich falsch?Grüße
-
@wschmidt said in 1:1 Nat geht nicht:
Ich habe dafür eine virtuelle IP auf der LAN-Schnittstelle eingerichtet und ein 1:1 NAT für die LAN-Adresse, aber trotzdem kommt er immer mit der LAN-Adresse und ein NAT scheint nicht statt zu finden.
Das LAN ist da nicht das richtige Interface. Die virtuell IP musst du dem IPSec Interface zuweisen. Ggf. musst du erst das IPSec Interface aktivieren, falls noch nicht gemacht.
Die NAT 1:1 Regel muss dann ebenfalls auf dieses Interface, die interne IP ist dann die echte des Rechners.Ich weiß aber nicht, ob das überhaupt mit routed IPSec (schon) funktioniert. Das lässt auch die pfSense Doku auch noch offen.
-
@viragomann Vielen Dank schon mal.
Es scheint genau hier das Problem zu liegen.
Ich hatte natürlich versucht die virtuelle IP auf das Tunnel-Interface zu legen, aber das ging nicht.
Die Meldung war, dass die IP nicht in der Range des Interfaces liegen würde, der Tunnel hat jedoch auch nur eine Single-IP-Adress. -
Die Meldung war, dass die IP nicht in der Range des Interfaces liegen würde
Bei der NAT-Regel, oder?
Wenn du aber erst die virtuelle IP, die dein Rechner bekommen soll, als IP Alias dem IPSec Interface zuweist, solltest du diese in der NAT-Regel verwenden können. -
@viragomann Ich kann die virtuelle IP nicht dem IPSec-Interface zuordnen. Es scheitert schon daran.
-
@wschmidt
Hast du der IPSec Instanz erst ein Interface zugewiesen und aktiviert? Nicht das vorgegebene verwenden.Ich kenne das bei IPSec VTI nur aus der Theorie, demnach sollte das aber möglich sein.
Falls nicht, ist der Fehler IPSerc-eigen, sonst kann man einem Interface jede beliebige IP als virtuelle hinzufügen.Ansonsten wäre eine P2 keine Option? Damit wäre dein Vorhaben umsetzbar.
-
@viragomann Danke noch mal für die Mühe.
Die Parameter, wie ich das VPN aufzubauen habe, sind leider vorgegeben und eigentlich ist das Ganze für eine Cisco gedacht.
Ich muss IPSec VTI benutzen und ich muss den angegebenen IP-Bereich benutzen, der aber nunmal nicht in inserem Netz liegt.
Die Cisco-Beispielkonfiguration natted dann eben auch die Server auf diesen IP-Bereich, aber irgendwie kann ich keine virtuelle IP dem VPN-Interface zuordnen, auch keine andere Schnittstelle.
In der VTI-Doku von Netgate steht denn auch "There are also known issues with NAT, notably that NAT to the interface address works but 1:1 NAT or NAT to an alternate address does not work."
Ich denke, es wird einfach so nicht funktionieren. -
@wschmidt Du brauchst im Normalfall KEINE IP anzulegen. Das ist unnötig. Deine Gegenstelle redet mit dir / bzw. du mir der Gegenstelle über eine ausgedachte IP i.i.i.i
Dein lokales Gerät hat a.a.a.a, die Remote Seite hat b.b.b.X/Y. Bei einem Routed IPSec müsstest du ja eine Route für b.b.b.X/y bei dir haben, die auf das IPSec Interface bzw. Peer zeigt. Dann genügt es eigentlich, wenn du ein 1:1 NAT anlegst
- Interface: Routed_IPsec (also das geroutete IPsec Interface dass der pfSense zugewiesen ist). Nicht das generelle IPSec, da das eine Gruppe ist
- External IP: i.i.i.i (deine imaginary IP die dein Gerät laut Gegenüber haben soll)
- Internal IP: a.a.a.a also dein Gerät
- Destination: theoretisch kann das bei any bleiben, dann wird das Gerät immer übersetzt. Soll ja aber nur für das VPN sein, daher wäre es hier sinnvoll das Remote Netz anzugeben, also sowas wie b.b.b.X/Y (bspw. 10.20.30.0/24 was auch immer die Gegenseite nutzt).
Speichern und Anwenden.
Dann mal auf dem Routed_IPsec Interface eine Filterregel anlegen, die Traffic an a.a.a.a erlaubt. Wichtig: Traffic nach a.a.a.a nicht i.i.i.i, da NAT VOR Regeln ausgeführt wird. Diese Regel dann mal Loggen lassen (oder testweise eine allow any Regel mit erlaubtem Logging draufwerfen) und ins Log sehen was passiert, wenn die Gegenseite die i.i.i.i aufruft.
Wichtig ist aber wie @viragomann sagt: Das IPSec VTI Interface muss über "Interfaces / Assignment" zugewiesen werden. Wenn unklar, einfach nen Blick in die Doku werfen, das wird dort explizit erwähnt.
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/routed-vti.html#ipsec-interface-assignment
Cheers
-
@jegr said in 1:1 Nat geht nicht:
@wschmidt Du brauchst im Normalfall KEINE IP anzulegen. Das ist unnötig. Deine Gegenstelle redet mit dir / bzw. du mir der Gegenstelle über eine ausgedachte IP i.i.i.i
Dein lokales Gerät hat a.a.a.a, die Remote Seite hat b.b.b.X/Y. Bei einem Routed IPSec müsstest du ja eine Route für b.b.b.X/y bei dir haben, die auf das IPSec Interface bzw. Peer zeigt.
Also, zum Verständnis. Ich habe einen funktionierenden P1-Tunnel und einen VTI-P2-Tunnel, mit einem Transfernetz, wo meine pfSense EINE IP hat und das Remotegerät, vermutlich ein Cisco, auch eine IP hat.
Im Status läuft der Tunnel.
Dann habe ich ein neues Interface hinzugefügt und das IPSec VTI Interdace ausgewählt.
Danach konnte ich die Remote-IP anpingen.Dann genügt es eigentlich, wenn du ein 1:1 NAT anlegst
- Interface: Routed_IPsec (also das geroutete IPsec Interface dass der pfSense zugewiesen ist). Nicht das generelle IPSec, da das eine Gruppe ist
So und genau hier habe ich ein Problem. Er bietet mir das Interface gar nicht an.
Nur LAN, WAN und IPSEC
Das Interface ist aber aktiviert und er hat auch ein Gateway erzeugt und wie gesagt, kann ich die Remote-IP anpingen.
Ich kann aber bei der NAT-Konfiguration, egal welche, die Schnittstelle nicht zuweisen.
Auch gibt es bei den Firewall-Rules nur den Reiter IPSEC, aber nicht die Schnittstelle.
Ich habe auf der pfSense auch noch einen anderen IPSEC-Tunnel, mit Policybased P2.Der rest war mir soweit klar, aber ich kann das Interface einfach nicht sehen, obwohl das Routing dadurch funktioniert. Ich kann sogar einen Rechner auf der anderen Seite anpingen.
-
@wschmidt said in 1:1 Nat geht nicht:
Also, zum Verständnis. Ich habe einen funktionierenden P1-Tunnel und einen VTI-P2-Tunnel, mit einem Transfernetz, wo meine pfSense EINE IP hat und das Remotegerät, vermutlich ein Cisco, auch eine IP hat.
Genau, bei VTI recht geläufig, dass man ein /30 hat und die beiden IPs (lokal/remote) dann die Gateways der Verbindung und zum Routen sind.
Dann habe ich ein neues Interface hinzugefügt und das IPSec VTI Interdace ausgewählt.
Exakt. Müsste ipsecXXXX von der Art des "Interfaces" sein.
Danach konnte ich die Remote-IP anpingen.
Top!
Nur LAN, WAN und IPSEC
Nimm hier mal IPsec.
Auch gibt es bei den Firewall-Rules nur den Reiter IPSEC, aber nicht die Schnittstelle.
Da auch mal IPsec nutzen. Ich vermute das kommt hier daher, dass im Gegensatz zu OVPN bei IPSec des Interface stabil weiterhin "enc0" bleibt und sich nur in den Phase2 IDs/VTIs unterscheidet, aber alles auf dem gleichen virtuellen Interface ankommt. Daher also einfach alles bei IPsec mit entsprechen angepasstem Source definieren, das sollte dann eigentlich laufen.
-
@jegr OK Moment, Kommando zurück ;)
Ich glaube es könnte sein, dass wir hier/du da in ein Problem von Upstream läufst, was mir gerade gar nicht mehr auf der Agenda war. Soweit ich mich entsinne gibt es da in der VTI Implementierung von Upstream FreeBSD einen Bug/Problem, dass bei VTI die Reply-To function des Paketfilters nicht mehr greift. Es gab da mal gerüchteweise einen Workaround, der von FreeBSD angegeben wurde, der griff aber IMHO nur dann sauber, wenn ihr NUR IPsec VTIs habt, danach lief kein Phasenbasiertes IPsec mehr.
Wenn ihr also NUR VTIs habt, wäre es ggf. eine Möglichkeit, ansonsten denke ich, wird das NAT wohl nicht funktionieren :( da das im Filter+Kernel+IPsec selbst steckt und upstream gefixt werden müsste.
Einzige Möglichkeit wäre dann der Gegenstelle ggf. zu sagen, dass ihr kein VTI machen könnt und ihr statt dessen IPsec mit Phase2 (klassisch) machen wollt - darin kann dann direkt in der P2 geNATtet werden. Wenn die Gegenstelle VTI kann, dann sollten die eigentlich auch keine Schmerzen mit nem P2/ESP Tunnel haben wenn man es ihnen freundlich nahebringt.
Cheers
\jens -
@jegr Erst noch mal danke für die Mühe.
tatsächlich habe ich es von Anfang an so gemacht, wie du beschrieben hast und es hat einfach nichts funktioniert.
Ich habe danach alles Mögliche und Unmögliche probiert, aber ohne Erfolg.
Ich hatte auch schon einen "klassischen" P2-Tunnel aufgebaut, wo sich die gegenstelle geweigert hat diesen abzunehmen (obwohl es funktioniert hat).
Das klassische IPSec benutzen wir aber noch für eine Standortanbindung und kann ich auch nicht so ohne weiteres Ändern.
Aktuell probiere ich, dass der Server bereits mit der geforderten IP-Adresse bei der pfSense ankommt.
Entweder über ein zweites Interface oder das eine andere pfSense das NAT macht und dann weiter routed.
Naja, mal sehen, was funktionieren wird.
