Hallo,
ich nutze Wireguard mit einem eigenen Netz 10.10.10.0/24 und Mappe das mit 1:1 NAT auf 192.168.1.0/24.
Erwartet hätte ich, das mit dem NATting z.B. die IP 10.10.10.2 auf die 192.168.1.2 gesetzt wird. Stattdessen wird sie auf 192.168.1.0 umgesetzt.
Ist das so normal ?
So sieht die Regel aus:
Firewall: NAT: One-to-One
Interface: IPsec
Type: NAT
External Network: 192.168.1.0/24
Source: 10.10.10.0/24
Destination: 10.20.0.0/24
Viele Grüße,
atom
Was genau ist dein Ziel, und wie immer bitte einen Netzwerk plan. Solltest du schon was konfiguriert haben, bitte Screenshots deiner konfiguration
Gesendet von iPad mit Tapatalk Pro
Das Ziel ist, das ein User, der sich über Wireguard eingewählt hat, durch einen VPN-Tunnel Server auf der anderen Seite erreichen kann. Das funktioniert auch soweit.
Ich würde nur gerne verstehen wollen, warum beim Natting dafür das letzte Oktett nicht gleich bleibt sondern .0 wird.
Beispiel:
Der User bekommt im WG-Netz die IP 10.10.10.2. Die sollte nach dem Natting zu 192.168.1.2 werden, wird aber zu 192.168.1.0
Die entsprechende Regel sieht so aus:
pfctl -s nat | grep 192.168.1.0
nat on enc0 inet from 10.10.10.0/24 to 10.20.0.0/24 -> 192.168.1.0/24
Quote from: atom on November 12, 2020, 04:21:15 PM
Das Ziel ist, das ein User, der sich über Wireguard eingewählt hat, durch einen VPN-Tunnel Server auf der anderen Seite erreichen kann. Das funktioniert auch soweit.
Ich würde nur gerne verstehen wollen, warum beim Natting dafür das letzte Oktett nicht gleich bleibt sondern .0 wird.
Beispiel:
Der User bekommt im WG-Netz die IP 10.10.10.2. Die sollte nach dem Natting zu 192.168.1.2 werden, wird aber zu 192.168.1.0
Die entsprechende Regel sieht so aus:
pfctl -s nat | grep 192.168.1.0
nat on enc0 inet from 10.10.10.0/24 to 10.20.0.0/24 -> 192.168.1.0/24
Also mein Verständnis von 1:1 NAT ist, dass Du
eine externe IP auf
eine interne IP mappst.
Du müsstest also für jede ext IP ein Mapping auf eine int. IP machen.
Habe ich gerade mal ausprobiert und nur 10.10.10.2 auf 192.168.1.2 genattet.
nat on enc0 inet from 10.10.10.2 to 10.20.0.2 -> 192.168.1.2
Das natting funktioniert so leider nicht. Die Quelladresse wird nicht umgesetzt, sondern bleibt 10.10.10.2.
Vielleicht weil die Phase 2 des VPN-Tunnels mit /24 nicht mehr zum Natting mit /32 passt ?
Was denn jetzt? WireGuard oder IPsec?
Poste doch bitte mal einen grafischen Netzwerkplan, damit wir verstehen von wo nach wo jetzt Daten fließen sollen und wo das 1:1 stattfinden soll.
Beides. :)
Ich gehe Remote zu Site 1 mit Wireguard. Das WG-Netz ist ein eigenes Netz, dass nur für die Einwahl genutzt wird. Dann muss ich per NAT auf ein lokales Netz in site 1, welches durch einen Tunnel zu site 2 geht (policy based).
Site 1 Client Wireguard 10.10.10.2 im 10.10.10.0/24
1:1 NAT zu 192.168.1.0/24
IPsec Tunnel 192.168.1.0/24 + manual SPD 10.10.10.0/24 zu Site 2
Site 2 IPsec Tunnel 10.20.0.0/24
Da muss ich leider passen. Ich meine was von Problemen bei der Kombination von IPsec und NAT gehört zu haben.
Ich hatte zuerst den VPN-Tunnel route-based und hatte Schwierigkeiten mit dem Routing durch weitere policy-based Tunnel (die auf beiden Seiten vom route-based Tunnel sind). Das läuft jetzt eigentlich alles sauber.
Nur das Natting für die Remote-Einwahl klappt nur so halb, weil eine .2-Host-Adresse auf eine .0-Netz-Adresse gemappt wird.
Du kannst doch dein VPN auch ohne das NAT Mapping nutzen, ich greife ja bei mir und in der Firma einfach auf die ip´s/Dienste ohne ein Mapping.Hatte ich nicht auch schon nach einem grafische3n netzwerkplan gefragt.
Bitte alle VPŃs, wan(s) und netze eintragen, nicht das irgendwann im text kommt, ach da ist ja noch ein netz oder ein VPN.
Bitte alle Infos die zur Lösung beitragen können.
Gesendet von iPad mit Tapatalk Pro
Wie könnte ich denn VPN auch ohne NAT nutzen ?
Quote from: atom on November 13, 2020, 07:42:31 AM
Wie könnte ich denn VPN auch ohne NAT nutzen ?
Hast Du Zugriff auf den IPsec Endpunkt an Site 2? Dann würde ich das WireGuard Netz einfach mit einer weiteren P2 bekannt machen.
Bei diesem Tunnel hätte ich Zugriff auf die Gegenseite und könnte das so machen.
Aber von dieser OPNsense gehen auch IPsec-Verbindungen (policy-based) zu Kundennetzen, wo ich keinen Zugriff habe.
Und ich hätte das gerne einheitlich.
Ganz anderer Ansatz: warum willst Du per 1:1 NAT auf irgendwelche IPs SNAT machen, die gar nicht auf der OPNsense sind? Wie soll das funktionieren?
Wenn Du auf Route based umstellst, kannst Du die IPsec Verbindung einem Interface zuweisen. Dann könntest Du dort Outbound NAT machen mit Quell-IP von der OPNsense (aus einem Netz, was der Gegenseite bekannt ist). Ich meine aber gehört zu haben, dass es da gerade irgendwelche Probleme mit Route-based und NAT gibt. Ich habe das bisher nie gebraucht, da ich immer Zugriff auf beide Seiten habe oder zumindest mit der Gegenseite sprechen kann, um meine Netze dort bekannt zu machen.
Ich meinte verstanden zu haben, dass das der einzige Weg ist, um weitere lokale Netze mit einer Gegenseite zu verbinden, wenn man kein Zugriff auf den Router hat.
Route-Based hatte ich zuerst konfiguriert. Das funktionierte auch zwischen meinen beiden Standorten ganz wunderbar. Nur das weiterrouten des Verkehrs über policy-based Tunnel zu den Kunden hat dann nicht mehr funktioniert.
Ich habe eine Lösung gefunden:
Firewall: NAT: Outbound
Source address: 10.10.10.0/24
Destination address: 10.20.0.0/24
Translation / target:192.168.1.0/24
Pool Options: Bitmask
Damit wird das Netz sauber umgesetzt und das letzte Oktett bleibt ein gültige Host-Adresse und wird keine Netz-Adresse.
Auf welchem Interface ist diese Regel?
Auf dem IPsec interface.
Gibt's denn schon einen Plan oder Idee, ab wann das auch deutlich smarter über einen Route-Based Tunnel intern zusammen mit Policy-Based-Tunnel zu Kunden funktionieren könnte ?