Hallo,
Meine Partnerstelle stellt mir 3 Netze zur Verfügung:
10.ABC.0.0/13
10.DEF.0.0/13
10.GHI.0.0/13
Allerdings definiert er für mich nur die 10.xxx.xxy.68/32
Wenn mein PC hinter der Firewall die IP Adresse 10.xxx.xxy.68 besitzt. Dann wird der Ping über die IPSec Schnittstelle übertragen. Soweit kein problem.
Ändere ich die IP Adresse z.B. auf 10.xxx.xxy.67 ab, so wird der Ping dircht mehr durchgeführt, was ja verständlich ist.
Daher wollte ich über NAT z.B. mit Eins-zu-Eins eine Übersetzung der Quell IP Adresse vornehmen.
Indem ich prüfe ob z.B. die IP 10.ABC.1.22 als Ziel angegeben wurde.
Die Quell IP adresse wird daraufhin auch von 10.xxx.xxy.67 auf 10.xxx.xxy.68 abgeändert. Allerdings will die Firewall das Paket nun aus dem WAN Port senden und nicht über die IPSec Verbindung.
Höchstwarscheinlich liegt es daran, weil ich die Umsetung auf der WAN Schnittstelle durchführe.
Nur wie kann man im OpnSense sagen, dass für eintreffende LAN Pakete erst die Quelladresse geändert werden soll, damit diese dann an IPsec und nicht an den WAN Port übergeben werden.
Und Ja, ich bekomme leider nur die eine IP Adresse von der gegenstelle für mein Netz.
Gruß und Vielen Dank für Infos
Du kannst die IPsec Verbindung auch route-based aufbauen. Dazu "Install policy" deaktivieren.
Nun solltest Du für diese Verbindung ein Interface "assignen" können. Auf diesem kannst Du einen Gateway erstellen und Routen anlegen, sowie NAT betreiben.
Nat geht nicht mit route based, Limitierung von FreeBSD mit strongswan
Quote from: mimugmail on October 23, 2020, 06:29:04 PM
Nat geht nicht mit route based, Limitierung von FreeBSD mit strongswan
Wieder was gelernt :)
Lesestoff :)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474
So wie ich das verstehe ist das verbleidende Problem nun:
QuoteRe-opening bug: It is currently not possible to simultanously have Routed IPsec with NAT and Policy IPsec.
Wenn er aber nur Route based mit NAT machen will, ohne Mix? Oder ist dieser "Fix" bisher nicht in OPNsense angekommen?
Kein Fix, wäre nur tuneable setzen, mehr braucht's nicht
Danke für die Ideengänge. Leider habe ich erst Montag das System parat um die genannten Schlagwörter zu erproben.
Scheinbar sollte ich mein Problem besser beschreiben. Daher habe ich mal eine kleine Skizze gemacht wie ich aktuell zu einem Erfolg gekommen bin, um zumindest mit einem Rechner zu kommunizieren. Siehe im Anhang.
Mein Partner hat mir drei Netzwerksegmente Freigegeben indem sich jeweils mehrere Rechner befinden die für mich freigegebene sind.
Für unser Netz hat er die IP Adresse 10.xxx.xxx.68/32 festgelegt und kein Segment wie z.B. 10.xxx.xxx.0/24
Somit habe ich im Normalfall ja nur die Möglichkeit über einen Rechner mit dem Netz zu kommunizieren. Im Beispiel Bild sieht man wie es aktuell funktioniert.
Wenn ich nun mit opnSense ein Ping auslöse, dann wird dieser nicht via ipSec übertragen sondern geht über das WAN Interface raus. Was ja verständlich ist, denn die Firewall selbst hat ja am LAN Anschluss zum Test die 10.xxx.xxx.254
Änder ich die LAN Adresse der Firewall auf 10.xxx.xxx.68/24 so kann ich mit der FW über einen Ping auslösen welcher dann auch über IPSec raus geht und nicht über WAN.
Trage ich am Rechner nun als Gateway die 10.xxx.xxx.68 win und vergebe den Rechner z.B. die 10.xxx.xxx.67 als IP so kann ich natürlich mit dem Rechner nicht ins IPSec Netz pinnen, da er die Ping Anforderung ins WAN Netz schick, denn in Phase 2 wurde die IP Adresse nicht festgelegt.
So normalerweise haben die Rechner in meinem z.B. Netz 10.yyy.yyy.100 und die Firewall somit 10.yyy.yyy.254. Sie haben also eigentlich nichts mit der Festlegung durch den Partner zu tun.
Mir ist es aktuell egal ob ich für die Rechner und der Firewall 10.xxx.xxx.0 oder 10.yyy.yyy.0 verwende. Da das Netz mit den Rechnern gerade aufgebaut wird. Nur ist eins Fakt. Wir werden mindestens 2 Rechner oder 4 Rechner haben, welche mit den Partnernetzwerk Rechnern kommunizieren wollen.
Ich bin also ganz Ohr für Lösungsansätze.
PS: Mit IPSec beschäftige ich mich erst seit 2-3 Tagen.
PPS: Ich habe die drei Segmente in jeweils 3 Phase2 Blöcke gesteckt, da man das glaube ich so machen muss wenn ich es richtig verstanden habe. Lasse mich aber auch eines besseren belehren, wenn dies zu Problemen mit dem NAT Thema führen soll. Denn irgend etwas habe ich gelesen von NAT vor IPSec ist nicht möglich wenn man mehrere Phase2 Blöcke in 1 Phase1 Block steckt.
Gruß Denis
Wenn ich es richtig verstehe, wird mir Routen wie hier beschrieben:
https://docs.opnsense.org/manual/how-tos/ipsec-s2s-route.html
nicht weiter helfen, da ich als Partner Angabe nur Segmente habe und nicht eine einzelne IP-Adresse, die ich als Gateway definieren könnte. Richtig?
So und aus den letzten beiden Posts von euch werde ich aktuell ohne System nicht schlau.
Bin ich leider ratlos. Ich hab üblicherweise Site-2-Site Verbindungen im Einsatz.
Das sieht mir aus wie eine Remote-Access Verbindung für einen einzelnen Host. Die Frage nach dem fehlenden Remote-Gateway ist wirklich kniffelig.
@mimugmail: Hast Du eine Idee?
Also ich habe nun dieses Thema mal ausprobiert:
Setup a routed IPSec Tunnel
https://docs.opnsense.org/manual/how-tos/ipsec-s2s-route.html
Aber das bringt mich scheiunbar auch nicht weiter, denn hier benötigt man auf beiden Seiten eine Adresse.
Damit man dann ein Gateway mit dem IPSEC1000 interface anlegen kann.
Und da stehe ich wieder mit meinem Problem. Das ich für meine Phase 2 eine IP Adresse habe und auf der anderen Seite nur 3 IP-Segmente.
https://docs.opnsense.org/manual/how-tos/ipsec-s2s-binat.html
outbound NAT statt BINAT, SPD je P2 nicht vergessen, gibt aber eine Limitierung dass es eigentlich nur mit einer P2 möglich ist, einfach mal testen.
https://github.com/opnsense/core/issues/2173
@mimugmail
Vielen recht herzlichen Dank Michael bei mir hat es funktionier.
Folgende Konfiguration habe ich vorgenommen:
###################
Phase 1
ganz normale einstellungen würde ich behaupten
###################
Phase 2 (insgesammt 3 Mal hinzugefügt):
Lokales Netzwerk:
Typ: Netzwerk
Adresse: 10.xxx.xxx.68 /32 (Als Tunnel Adresse)
Entferntes / Partner Netzwerk
Typ: Netzwerk
Adresse: 10.ABC.0.0/13 (Zwei weitere Phasen für die Anderen Segmente 10.DEF.0.0/13 & 10.GHI.0.0/13)
Als Manuelle SPD-Einträge: 10.10.40.0/24 (Indem sich meine Rechner befinden)
###################
Firewall --> NAT --> Ausgehend (Outbound)
Modus:
EN: Hybride Erstellung ausgehender NAT Regeln
(automatisch generierte Regeln werden nach den manuellen Regeln angewandt)
DE: Hybrid outbound NAT rule generation
(automatically generated rules are applied after manual rules)
Insgesammt 3 Roules habe ich hinzugefügt:
----------------
Schnittstelle: IPsec
Quelladresse: 10.10.40.0/24 (Indem sich meine Rechner befinden)
Zieladresse: 10.ABC.0.0/13 (Zwei weitere Manuelle Rules für die Anderen Segmente 10.DEF.0.0/13 & 10.GHI.0.0/13)
Übersetung/Ziel: 10.xxx.xxx.68 /32 (Die Tunnel Adresse)
Ich hatte ein Ähnliches Problem bei nem anderen Kunden. Es kommt wohl auch auf die Gegenseite an ob es mit mehreren P2 klappt. VyOS ging zB nicht.
Ich stand vor kurzem vor einem ähnlichen Problem. Der Partner hat mir via IPSec nur eine Host IP in meinem Netz erlaubt, also weitest gehend ähnlich wie beim Thread Opener. Historisch bedingt, haben wir dann eine VM Installiert, die diese IP bekommt. Kollegen haben sich dann via RDP mit der VM Verbunden um von dort weiter zum Kunden zu gelangen.
Das war mir aber zu doof. Die vom Vorredner genannten NAT Rules hatte ich auch schon drin, funktionierten bei mir aber erst dann, sobald ich die freigegebene IP als virtuelle IP auf mein WAN Interface gelegt habe (und die VM ausgeschaltet war).
Seit dem kann ich frei per Regelwerk steuern, wer zum Kunden darf. Also das nur am Rande, falls noch andere dieses Problem haben.
Quote from: c-mu on October 28, 2020, 08:00:36 AM
Ich stand vor kurzem vor einem ähnlichen Problem. Der Partner hat mir via IPSec nur eine Host IP in meinem Netz erlaubt, also weitest gehend ähnlich wie beim Thread Opener. Historisch bedingt, haben wir dann eine VM Installiert, die diese IP bekommt. Kollegen haben sich dann via RDP mit der VM Verbunden um von dort weiter zum Kunden zu gelangen.
Das war mir aber zu doof. Die vom Vorredner genannten NAT Rules hatte ich auch schon drin, funktionierten bei mir aber erst dann, sobald ich die freigegebene IP als virtuelle IP auf mein WAN Interface gelegt habe (und die VM ausgeschaltet war).
Seit dem kann ich frei per Regelwerk steuern, wer zum Kunden darf. Also das nur am Rande, falls noch andere dieses Problem haben.
Die virtuelle IP auf dem WAN? Das ist ja strange ... auf LAN Seite hätte es noch minimal Sinn ergeben aber auf dem WAN? :o
Ja, weil sämtlicher IPSec traffic das WAN interface nutzt. Ich war auch erstaunt das es dann so geklappt hat.
Wie man es dreht und wendet, landen Outbound Pakete immer in der letzten SA.
Lediglich Inbound Traffic kann über die richtige SA abgefangen werden. Wenn die Gegenseite zulässt, dass auch Pakete über die falsche SPI eingehen, dann funktioniert der Traffic auch outbound, man sieht aber im IPSEC Status unter den SAs, dass der Traffic nur in der letzten unter "Out" gezählt wird.
Ich habe es eben mit der WAN IP Alias Adresse im SNAT getestet. Leider funktioniert es zwischen einer OPNSense (outbound) und einer PFSense / VyOS (inbound) nicht.
Quote from: mimugmail on October 27, 2020, 08:56:18 PM
Ich hatte ein Ähnliches Problem bei nem anderen Kunden. Es kommt wohl auch auf die Gegenseite an ob es mit mehreren P2 klappt. VyOS ging zB nicht.
Auf der Gegenseite befindet sich eine Checkpoint Firewall. Soviel weiß ich zumindest.
Hi,
ich habe einem Kollegen gerade versucht das Ergebnis zu erklären.
Zu 99,9% war dies auch nachvolziebar zu erklären. Nur an einer stelle ist mir das Wording für Outbound unklar.
Unter Firewall --> NAT --> Ausgehend (Outbound) gibte es --> Übersetzung / Ziel (Translation / target)
Warum heist dies Ziel und nicht Quelle? Denn meine Quelladresse (Im Screenshot Beispielhaft. Das Segment (10.123.456.0/24) wird doch in die Adresse 10.111.111.68/32 übersetzt.
Ich denke das ist das gleiche Label wie bei einem Portforwarding und da wäre es dann eben das Ziel.
Verwirrend, ja :)
Also ich hab jetzt ein LAB.
LAN-A --- FW-A --- FW-B --- LAN-B1+LAN-B1
VPN SA ist 10.47.47.1/32 <-> 10.98.2.0/24 + 10.98.22.0/24
LAN-A ist 10.10.10.0/24. Ich hau LAN-A in beide SPDs und mache das Outbound NAT.
FW-A und FW-B sind beide OPNsense. In der Standardkonfiguration geht es nur mit LAN-B1 und wenn ich Tunnel-Isolation aktiviere gehen beide.
Das war jetzt ein Test OHNE irgendeine Virtual IP irgendwo
Sorry wenn ich hier einen alten Thread kapere, aber ich habe aktuell dasselbe Problem wie der OP und komme nicht so recht weiter. Das Problem ist, dass meine NAT-Regel partout nicht greifen will. Ich habe schon probiert die NAT-IP auf das WAN-Interface zu binden, aber das hat auch nicht geholfen. Was aus den bisherigen Posts nicht ganz eindeutig hervorgeht: Funktioniert das jetzt nur mit Route-based IPsec? Muss ich Tunables setzen?
_________________________________________
Zusammengefasste Lösung
_________________________________________
Hallo @Colani1200,
im Anhang findest du die Konfiguration, welche ich damals vorgenommen hatte.
Aufgeteilt in mehrere Posts, da maximal 4 Bilder mit Max. 256KB hochgeladen werden können.
Und ich habe als Modus "Tunnel IPv4" genutzt.
Post TEIL 1
Post TEIL 2
Post TEIL 3
Post TEIL 4