Hallo zusammen,
ich experimentiere gerade mit OPNsense und habe dabei folgendes Setup:
Lokale statische IP: 97.228.212.23
Remote statische IP: 91.36.170.12
SA (Phase 2):
Lokales Subnetz: 72.257.145.168/29
Remotes Subnetz: 117.8.130.224/27
Der Tunnel selbst baut sauber auf – also alles soweit prima.
Ziel:
Ich möchte NAT so einstellen, dass die folgenden Verbindungen funktionieren:
172.17.54.124 <-> 72.257.145.169
172.17.54.125 <-> 72.257.145.170
Aktuelle Situation:
Ich habe momentan ein One-to-One NAT konfiguriert.
Im Log sehe ich, dass z. B. der Ping von 172.17.54.124 tatsächlich in den IPsec-Tunnel geht.
Die Bytes Out bleiben jedoch auf 0, als ob nichts rausgeht.
Eingehend kommen Pakete rein, landen aber irgendwie auf dem WAN-Port, anstatt korrekt im Tunnel verarbeitet zu werden.
809_WAN 2024-10-23T15:26:16 117.8.130.226:55060 72.257.145.169:3300 tcp let out anything from firewall host itself
IPsec 2024-10-23T15:26:16 117.8.130.226:55060 72.257.145.169:3300 tcp Zugriff Cloud auf Systeme
809_WAN 2024-10-23T15:26:00 117.8.130.226:56495 72.257.145.169:3300 tcp let out anything from firewall host itself
IPsec 2024-10-23T15:26:00 117.8.130.226:56495 72.257.145.169:3300 tcp Zugriff Cloud auf Systeme
Warum willst du da was NATen? Natürlich kannst du öffentliche IP-Adressen genau so in die Phase-2-SAs stopfen wie RFC 1918 ... hab ich produktiv im Einsatz, weshalb auch nicht? :)
ich muss ja auf jedenfall irgendwie die öffentlichen ip´s die ich im tunnel habe auf die internen ip´s naten.
und so ist es zumindest bei cisco.
Ein No-NAT für Anfragen an die öffentliche IP machen - da Sie sonst ans WAN geschickt werden.
Bei der Opnsense bin ich hier hier eben nicht sicher.
Ich dachte, du willst zwei Netze mit öffentlichen IPs mit einem Tunnel verbinden. Die privaten hatte ich übersehen.
Dafür brauchst du auf der Seite, wo die liegen, manuelle SPDs. Reicht das als Hinweis?
wenn ich ehrlich bin nicht.
warum setzt er die SPD nicht automatisch - wenn ich sie als Remote-Subnet angebe.
Er sagt mir sogar im tcpdump auf enc0 dass er die Pakete in den Tunnel sendet:
listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 262144 bytes
14:08:49.744037 (authentic,confidential): SPI 0x1f1f993b: IP 72.257.145.170 > 117.8.130.239: ICMP echo request, id 4592, seq 1, length 64
14:08:50.749661 (authentic,confidential): SPI 0x1f1f993b: IP 72.257.145.170 > 117.8.130.239: ICMP echo request, id 4592, seq 2, length 64
14:08:51.773709 (authentic,confidential): SPI 0x1f1f993b: IP 72.257.145.170 > 117.8.130.239: ICMP echo request, id 4592, seq 3, length 64
14:08:52.797698 (authentic,confidential): SPI 0x1f1f993b: IP 72.257.145.170 > 117.8.130.239: ICMP echo request, id 4592, seq 4, length 64
con3: #11, ESTABLISHED, IKEv2, bafa69882c7eaba3_i* 5b4ab0273b05dd4c_r
local '97.228.212.23' @ 97.228.212.23[500]
remote '91.36.170.12' @ 91.36.170.12[500]
AES_CBC-256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/ECP_521
established 7110s ago, rekeying in 6641s
con3: #81, reqid 11, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_512_256/ECP_521
installed 1099s ago, rekeying in 2063s, expires in 2501s
in cd279ffd, 5616 bytes, 108 packets, 37s ago
out 1f1f9c6b, 0 bytes, 0 packets
local 72.257.145.169/29
remote 117.8.130.224/27
root@AERUMTEC-RZ-SENSE01:~ # tcpdump -i enc0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 262144 bytes
16:02:18.654099 (authentic,confidential): SPI 0x1f1f9c6b: IP 72.257.145.169 > 117.8.130.239: ICMP echo request, id 52826, seq 1, length 64
16:02:19.683743 (authentic,confidential): SPI 0x1f1f9c6b: IP 72.257.145.169 > 117.8.130.239: ICMP echo request, id 52826, seq 2, length 64
16:02:20.707801 (authentic,confidential): SPI 0x1f1f9c6b: IP 72.257.145.169 > 117.8.130.239: ICMP echo request, id 52826, seq 3, length 64
16:02:21.731696 (authentic,confidential): SPI 0x1f1f9c6b: IP 72.257.145.169 > 117.8.130.239: ICMP echo request, id 52826, seq 4, length 64
16:02:22.755705 (authentic,confidential): SPI 0x1f1f9c6b: IP 72.257.145.169 > 117.8.130.239: ICMP echo request, id 52826, seq 5, length 64
Du brauchst auf der Seite mit dem privaten Netz eine manuelle SPD, weil Policy vor NAT greift. Deshalb gehen die Pakete falsch rum.
Ich hab an einer Stelle folgende Phase 2 mit einem Kunden:
Local: 192.168.180.0/24
Remote: 192.168.254.0/24
Zusätzlich habe ich noch:
Local: 192.168.181.0/24
Dafür trage ich eine manuelle SPD 192.168.181.0/24 <> 192.168.254.0/24 ein mit derselben ReqID wie der "Child" Eintrag in der normalen SA.
Und dann ein 1:1 NAT 192.168.180.0/24 <> 192.168.181.0/24.
So fluppt es hier. Hoffe, das hilft.
schade irgendwie klappt es "noch nicht"
ich habe die "VPN: IPsec: Security Policy Database"
Angelegt - in meinem Fall auf dei ReqID "11"
11 172.17.54.0/24 -> 117.8.130.224/27
11 117.8.130.224/27 -> 172.17.54.0/24
bringt leider auch nicht den erwünschten erfolg.
Die opnsense hat irgendwie ein Problem mit den public IP´s in der Phase2.
Ob die IPs public oder private sind, ist wurst. Irgendwie passen da SPDs und NAT noch nicht zusammen.
@Monviech, kannst du mal reingucken?
@btotherunner kannst du mal die Tabelle mit den installed SPDs aus dem UI posten?
anbei die screenshots:
anbei das log
Ich habe heute nochmals danach geschaut und komme einfach nicht drauf - was ich anpassen muss.
Die Pakete kommen über den IPSec Tunnel an.
Werden genattet - landen dann beim Server.
Der Server antworet
werden wieder genattet - und dann aber geblockt?
Es gibt zum testen eine any any allow regel.
Warum werden die Anfragen geblockt?
Anbei ein Sreenshot.
Auf welchem Interface liegt die Regel?
Die Regeln liegt auf dem 754_XXX_SERVER
Liegt das irgendwie dran, dass auf diesem Interface natürlich private Adressen liegen und keine public ip-adressen?
Das weiß ich tatsächlich nicht. Mach doch mal auf IPsec eingehend auch ein allow all.
ich habe nochmal etwas genauer das ganze angeschaut.
Ich hatte noch eine Route zu 117.8.130.239 auf das gateway: 172.17.54.1 (also das firewall interface selbst).
Wenn ich diese raus mache, wird die Antwort auf das WAN-Interface (default GW) gesendet.
Wenn ich es jetzt noch hinbekomme, dass anfragen von 72.257.145.169-> 117.8.130.224/27 auf das ipsec interface geroutet wird.
Müsste es klappen....
Die frage nur wie... ^^
Dafür braucht es die manuelle SPD.
ja so meine Hoffnung.
Entweder ist Sie falsch angelegt oder es klappt einfach nicht.
Ich habe die aktuellen Einstellungen einmal hier angehängt.
hier auch nochmal ein Trace.... und die SPD die passen sollte.
@Patrick M. Hausen wie sollten die SPD´s denn deiner Meinung nach aussehen?
Die automatischen kommen ja aus der SA mit den beiden öffentlichen Prefixen. Unter manual trägst du dann lokal dein privates Netz und remote das öffentliche der Gegenstelle ein.
Hey, danke für deine Antwort.
Aber genau das habe ich doch - aber die ziehen leider nicht.
ich habe die Lösung gerade eben via Zufall herausgefunden.
Ich habe bisher die SPD manuell angelegt - über den Menüpunkt Security Policy Database - Manual
Allerdings habe ich gesehen, dass in der Phase2 einstellung einen unterpunkt "Manual SPD entries" gibt, dort habe ich einfach die interne IP-Range 172.17.54.0/24 eingetragen - und zack läufts....
Angehängt ein Screenshot....