09.10.2020, aktualisiert am 06.10.2023

7436

OPNsense IPSec Site2Site funktioniert nicht

Guten Tag zusammen,
ich versuche gerade in meiner Testumgebung eine Site2Site mit der OPNsense über IPSec einzurichten und ich kriege es nicht hin und brauche einmal Hilfe

Beide OPNsense sind komplett mit Werkseinstellung neu eingerichtet worden, nach der Anleitung: https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html
Vorweg, die Anleitung ist meiner Meinung nach nicht korrekt. Beim Remote "Netzwerk" steht "Gateway-IP /24" des anderen Netzwerkes drin. Das ist doch falsch? Hier habe ich die Remote "Netz-Adresse /24" eingetragen.

Hm, soweit mal, folgender Aufbau:

1x OPNsense Firewall / 2 interne Netzwerkports opn und opn1
WAN opn: 172.16.0.1 /24, Gateway 172.16.0.254 (geht ins Nirgendwo)
LAN opn1: 192.168.1.0 /24, Gateway 192.168.1.1

1x OPNsense Firewall / 2 interne Netzwerkports opn und opn2
WAN opn: 172.16.0.2 /24, Gateway 172.16.0.254 (geht ins Nirgendwo)
LAN opn2: 192.168.2.0 /24, Gateway 192.168.2.1

Die ganzen Firewall-Regeln sind gesetzt, die Einstellung für Phase 1 und Phase 2 sind identisch (bis auf remote Gateway und remote net natürlich).

Es kommt jedenfalls keine IPSec Verbindung zu stande.

Das ist z.B. ein Log von der 1. OPNsense:

2020-10-09T22:16:22	charon[92649]: 16[IKE] <con1|1> establishing IKE_SA failed, peer not responding
2020-10-09T22:16:22	charon[92649]: 16[IKE] <con1|1> giving up after 5 retransmits
2020-10-09T22:15:06	charon[92649]: 04[NET] error writing to socket: Host is down
2020-10-09T22:15:06	charon[92649]: 16[NET] <con1|1> sending packet: from 172.16.0.1[500] to 172.16.0.2[500] (464 bytes)
2020-10-09T22:15:06	charon[92649]: 16[IKE] <con1|1> retransmit 5 of request with message ID 0
2020-10-09T22:14:24	charon[92649]: 04[NET] error writing to socket: Host is down
2020-10-09T22:14:24	charon[92649]: 08[NET] <con1|1> sending packet: from 172.16.0.1[500] to 172.16.0.2[500] (464 bytes)
2020-10-09T22:14:24	charon[92649]: 08[IKE] <con1|1> retransmit 4 of request with message ID 0
2020-10-09T22:14:01	charon[92649]: 04[NET] error writing to socket: Host is down
2020-10-09T22:14:01	charon[92649]: 08[NET] <con1|1> sending packet: from 172.16.0.1[500] to 172.16.0.2[500] (464 bytes)
2020-10-09T22:14:01	charon[92649]: 08[IKE] <con1|1> retransmit 3 of request with message ID 0
2020-10-09T22:13:48	charon[92649]: 04[NET] error writing to socket: Host is down
2020-10-09T22:13:48	charon[92649]: 08[NET] <con1|1> sending packet: from 172.16.0.1[500] to 172.16.0.2[500] (464 bytes)
2020-10-09T22:13:48	charon[92649]: 08[IKE] <con1|1> retransmit 2 of request with message ID 0
2020-10-09T22:13:41	charon[92649]: 04[NET] error writing to socket: Host is down
2020-10-09T22:13:41	charon[92649]: 08[NET] <con1|1> sending packet: from 172.16.0.1[500] to 172.16.0.2[500] (464 bytes)
2020-10-09T22:13:41	charon[92649]: 08[IKE] <con1|1> retransmit 1 of request with message ID 0
2020-10-09T22:13:37	charon[92649]: 04[NET] error writing to socket: Host is down
2020-10-09T22:13:37	charon[92649]: 08[NET] <con1|1> sending packet: from 172.16.0.1[500] to 172.16.0.2[500] (464 bytes)
2020-10-09T22:13:37	charon[92649]: 08[ENC] <con1|1> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]

Host ist down? Beide Firewalls sind an und haben firewallmäßig Zugriff (denke ich, Regeln laut Anleitung gesetzt).

Erschwerend kommt hinzu, dass ich beide Sample-Configs laut der Anleitung direkt bei meinen beiden OPNsense wiederhergestellt habe und trotzdem keine IPSec Verbindung zu stande kam (und andere Einstellungen konfiguriert waren als in der Anleitung..fail).

Kann mir jemand helfen? Ich vermute, dass ich WAN-seitig Probleme habe, weil ich hier keine verschiedenen Subnetze laut Anleitung habe und ich Subnetting eigentlich nicht wirklich verstehe...hust. (und hiermit besser verstehen will)

Vielen Dank schonmal!

MfG

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 611572

Url: https://administrator.de/forum/opnsense-ipsec-site2site-funktioniert-nicht-611572.html

Ausgedruckt am: 22.12.2024 um 07:12 Uhr

14 Kommentare

Neuester Kommentar

Ich vermute, dass ich WAN-seitig Probleme habe, weil ich hier keine verschiedenen Subnetze laut Anleitung habe und ich Subnetting eigentlich nicht wirklich verstehe...hust. (und hiermit besser verstehen will)

Das ist egal, im sogenannten Back-to-Back-Betrieb funktioniert es genauso wie im Internet.

Hast du einfach mal den dööfsten Test von allen gemacht und von der einen Firewall die WAN-IP der anderen angepingt?

Aber mach dir nichts draus: Ich finde pfSense/OPNsense für den Einsatz mit VPN höchst unschön. Da gibt es andere Lösungen, mit denen man schneller zum Ziel kommt.

Zitat von @tikayevent:

Hast du einfach mal den dööfsten Test von allen gemacht und von der einen Firewall die WAN-IP der anderen angepingt?

Aber mach dir nichts draus: Ich finde pfSense/OPNsense für den Einsatz mit VPN höchst unschön. Da gibt es andere Lösungen, mit denen man schneller zum Ziel kommt.

Ping von der 1. OPNsense

# /sbin/ping -S '172.16.0.1' -c '3' '172.16.0.2' 
PING 172.16.0.2 (172.16.0.2) from 172.16.0.1: 56 data bytes

--- 172.16.0.2 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

# /sbin/ping -S '192.168.1.1' -c '3' '192.168.2.1' 
PING 192.168.2.1 (192.168.2.1) from 192.168.1.1: 56 data bytes

--- 192.168.2.1 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

Ich sehe aber auch im IPSec Status Overview, dass die S2S nicht steht.
Ich finde die OPNsense eigentlich höchst angenehm, nur die Dokumentation ist absolut bescheiden.

Moin!

Biste sicher, dass die grundlegende Netzwerkkonnektivität in deiner (virtuellen?) Testumgebung steht?
Hier verhau ich mich gerne mal...

VG
Buc

und von der einen Firewall die WAN-IP der anderen angepingt?

Das wird nicht klappen, denn die Default Regeln auf dem WAN Port verhindern das. ICMP ist dort natürlich geblockt wie es sich für eine Firewall gehört.
Leider fehlen die Screenshots der WAN Regeln. Könnte sein das hier der Fehler ist, denn "Host down" kann bedeuten das die Gegenstelle nicht erreichbar ist.
Wichtig ist dort das die IPsec Ports von "any" auf die WAN IP Adresse freigeben sind.

UDP 500
UDP 4500
ESP Protokoll, IP Nummer 50

Mehr ist eigentlich nicht zu tun vorausgesetzt die Crypto Credentials stimmen auf beiden Seiten.

Ein Testsetup mit einer pfSense Konfig in der gleichen IP Adressierung hat hier auf Anhieb sofort einen Tunnel aufgebaut sowohl mit IKEv1 als auch mit IKEv2.
Hilfe bei OpenVPN Standortvernetzung zwischen pfSense (Server) und Mikrotik (Client)
PfSense IPsec hub and spoke
Zum Thema Subnetting wie immer lesen und verstehen:
https://de.wikipedia.org/wiki/Netzmaske
https://de.wikipedia.org/wiki/Subnetz

ICMP ist dort natürlich geblockt wie es sich für eine Firewall gehört.

Naja, viele kennen die Eigenheiten von ICMP nicht (bei dir @aqui gehe ich mal davon aus, dass du diese kennst), daher ist diese Konfiguration bescheuert.
Ein nicht erreichbarer Host wird vom vorherigen Router als Host not reachable gemeldet und nicht durch einen Timeout. Ein Timeout zeigt also , dass ein Host da ist, der einfach nicht antworten will oder kann.

Aber zum Glück ist es konfigurierbar.

Das ICMP inbound geblockt ist an "heißen" Interfaces ist aber übliche Firewall Praxis. Host not reachable kommt ja durch entsprechende ICMP Steuerpakete. Kommen die nicht durch die FW, dann gibts halt einen Timeout.
Deshalb ja die Vermutung das es an falschen oder fehlerhaften FW Regeln des TOs am WAN Port liegt.

Aber warten wir mal sein Feedback ab....

Zitat von @aqui:

Leider fehlen die Screenshots der WAN Regeln. Könnte sein das hier der Fehler ist, denn "Host down" kann bedeuten das die Gegenstelle nicht erreichbar ist.
Wichtig ist dort das die IPsec Ports von "any" auf die WAN IP Adresse freigeben sind.

UDP 500
UDP 4500
ESP Protokoll, IP Nummer 50

Danke für die Links und das Testen.
Ich habe jetzt gerade keine Möglichkeit, Screenshots zu posten, das werde ich heute Abend nachholen. Ich habe mich aber ansonsten an den OPNsense guide gehalten und auch die 4 Firewallregeln gesetzt (UDP 500, UDP 4500, ESP und von Subnet zu Subnet, für den "IPSec"-Anschluss / an beiden OPNsense firewalls)

Es ist doch korrekt, dass beide WANs in das gleiche logische "interne" virtualisierte Netz gehören, oder? Das soll ja das WWW simulieren. Ich nutze VirtualBox für meine Testumgebung und habe als Netzwerktyp "internal" gewählt.

MfG

Vermutlich dann ein Bug in der OPNsense Firmware. Ist bei OPNsense nicht selten.
Hast du es testweise mal mit einem pfSense Image versucht ??

Es ist doch korrekt, dass beide WANs in das gleiche logische "interne" virtualisierte Netz gehören, oder?

Keine Ahnung was du mit dem wirren logisch, "intern" und virtualisiert... meinst ?? Das ist völlig unverständlich.
Korrekt ist nur das bei dir in einem sog. "Back to Back" Testaufbau die beiden direkt verbundenen WAN Interface in einem gleichen IP Netzwerk liegen müssen. Das hast du mit dem 172.16.0.0 /24er Netz wo die Firewalls jeweils die .1 und .2 haben auch genau richtig gemacht.
Statt der nicht vorhandenen Gateway IP Adresse hättest du hier besser immer die der gegenüberligenden Firewall genommen aber das ist eher nur kosmetisch. Ansonsten ist alles richtig.
Wie bereits oben schon gesagt hat ein Testaufbau mit 2 pfSense Firewalls mit exakt deinem IP Setup hier sofort einen funktionierenden VPN Tunnel aufgebaut sowohl mit IKEv1 als auch mit IKEv2.
Einen stimmigeren Beiweis dafür das deine IP Adressierung damit richtig ist kann es doch dann nicht geben, oder ?!

Ich nutze VirtualBox für meine Testumgebung und habe als Netzwerktyp "internal" gewählt.

Wenn beide WAN Ports in diesem "internal" Segment liegen ist das OK und richtig.
Du kannst ja, um ganz sicher zu gehen, am WAN Port eine Source: ANY Regel auf die Destination: WAN_IP_address einrichten so das jeglicher Traffic auf die WAN IP Adresse erlaubt ist.
Ist erstmal dann ein unsicheres "Scheunentor" aber zum testen ja erstmal OK und damit sind die WAN IPs über das Diagnostics Menü und der dortigen Ping Funktion gegenseitig pingbar und so kannst du die gegenseitige Connectivity wasserdicht checken.

Hm, ich verstehs nicht, wo das Problem ist (vermutlich vorm Bildschirm *hust*).

Wenn ich die WAN Ports für any öffne, kann ich die jeweils andere OPNsense auch anpingen.

Hier noch die versprochenen Screens:
Opnsense 1:

Opnsense 2:

Ich werde in den nächsten Tagen mal pfsense testen. Danke!

MfG

Hier noch die versprochenen Screens:

Wenn du die "+" Zeichen beim Einbinden der Bilder auch an die richtige Stelle klicken würdest, dann würden wir hier deine Screenshots auch im richtigen Kontext zur Beschreibung sehen können !

FAQs lesen hilft wirklich !
P.S.:
Kann man übrigens immer nachträglich mit dem "Bearbeiten" Knopf (rechts unter "Mehr") noch korrigieren.

Deinen Fehler sieht man übrigens sofort und auf dem ersten Blick. Völlig unverständlich warum du sowas übersehen kannst...?! Mit deiner Vermutung "...das Problem ist (vermutlich vorm Bildschirm *hust*)." hast du das schon sehr gut erkannt.
Deine Filter Regeln sind natürlich völliger Quatsch. Sieh dir den Unsinn doch selber mal an.
Das IPsec Interface ist das interne VPN Netz ! Es ist doch völlig sinnfrei dort die Ports für aus dem Internet eingehende IPsec Frames zu konfigurieren !
Wenn, dann gehören diese Regeln auf den WAN Port !! Von dort kommen doch die IPsec Frames zur Firewall rein, folglich müssen dort doch die Regeln hin.
Auf den IPsec Port kann erstmal eine any zu any Regel zum Testen.
Vermutlich hast du das an der 2ten Firewall auch falsch gemacht und musst es dort auch anpassen ?!
Ändere das, dann klappt das auch sofort.

Zitat von @aqui:

Wenn du die "+" Zeichen beim Einbinden der Bilder auch an die richtige Stelle klicken würdest, dann würden wir hier deine Screenshots auch im richtigen Kontext zur Beschreibung sehen können !

FAQs lesen hilft wirklich !

Das erste Forum, wo man tatsächlich die FAQs lesen muss. Habs bearbeitet.

Zitat von @aqui:
Deinen Fehler sieht man übrigens sofort und auf dem ersten Blick. Völlig unverständlich warum du sowas übersehen kannst...?! Mit deiner Vermutung "...das Problem ist (vermutlich vorm Bildschirm *hust*)." hast du das schon sehr gut erkannt.
Deine Filter Regeln sind natürlich völliger Quatsch. Sieh dir den Unsinn doch selber mal an.
Das IPsec Interface ist das interne VPN Netz ! Es ist doch völlig sinnfrei dort die Ports für aus dem Internet eingehende IPsec Frames zu konfigurieren !
Wenn, dann gehören diese Regeln auf den WAN Port !! Von dort kommen doch die IPsec Frames zur Firewall rein, folglich müssen dort doch die Regeln hin.
Auf den IPsec Port kann erstmal eine any zu any Regel zum Testen.
Vermutlich hast du das an der 2ten Firewall auch falsch gemacht und musst es dort auch anpassen ?!

Ja, die Regeln habe ich tatächlich falsch gesetzt. Ich habe sie gestern noch auf den jeweiligen WAN-Port geklont, hat leider auch nicht zum Erfolg geführt, eine Verbindung kommt trotzdem nicht zu stande :/

Danke
MfG

Das erste Forum, wo man tatsächlich die FAQs lesen muss.

Müssen muss man gar nix !

Es hilft nur anderen beim besseren Verstehen deines Anliegens...

eine Verbindung kommt trotzdem nicht zu stande

Ist ja zu befürchten das du da schon wieder einen Fehler gemacht hast ?! Es wäre also hilfreich die neuen Regeln einmal zu posten ?!
Was zum Troubleshooting immer wichtig ist und du wieder nicht geschickt hast ist das IPsec VPN Log von beiden Seiten ! WAS steht dort wenn ein Tunnelaufbau initiiert wird ???

Hier nochmals für dich als Leitlinie der einfache Test mit 2 mal pfSense

Testsetup:

Setup pfSense-1:

IPsec Phase 1 und Phase 2:

FW Regel IPsec Interface (pfSense-2 identisch):

Tunnel aufgebaut und OK !:

Setup pfSense-2:

IPsec Phase 1 und Phase 2:

FW RegelWAN Interface (pfSense-1 identisch):

Tunnel aufgebaut und OK !:

Ping Check Client 2 auf Client 1:

C:\Users\User>ipconfig

Windows-IP-Konfiguration

Ethernet-Adapter LAN-Verbindung:

   IPv4-Adresse  . . . . . . . . . . : 172.17.1.50
   Subnetzmaske  . . . . . . . . . . : 255.255.255.128
   Standardgateway . . . . . . . . . : 172.17.1.1


C:\Users\User>ping -n 3 -l 512 192.168.1.1

Ping wird ausgeführt für 192.168.1.1 mit 512 Bytes Daten:
Antwort von 192.168.1.1: Bytes=512 Zeit=2ms TTL=63
Antwort von 192.168.1.1: Bytes=512 Zeit=2ms TTL=63
Antwort von 192.168.1.1: Bytes=512 Zeit=3ms TTL=63

Ping-Statistik für 192.168.1.1:
    Pakete: Gesendet = 3, Empfangen = 3, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 2ms, Maximum = 3ms, Mittelwert = 2ms

C:\Users\User>ping -n 3 -l 512 192.168.1.101

Ping wird ausgeführt für 192.168.1.101 mit 512 Bytes Daten:
Antwort von 192.168.1.101: Bytes=512 Zeit=4ms TTL=62
Antwort von 192.168.1.101: Bytes=512 Zeit=4ms TTL=62
Antwort von 192.168.1.101: Bytes=512 Zeit=4ms TTL=62

Ping-Statistik für 192.168.1.101:
    Pakete: Gesendet = 3, Empfangen = 3, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 4ms, Maximum = 4ms, Mittelwert = 4ms 

Fazit:
Works as designed und funktioniert fehlerlos auf Anhieb !!

Hi aqui
ich melde mich erst jetzt, da ich erst heute dazu gekommen bin.
Vielen Dank für deine Hilfe!

Ich habe nun mit wenigen Schritten erfolgreich die Site2Site aufbauen können...hat sofort funktioniert!
Krass, ich hätte nicht gedacht, dass das so einfach ist. Und ich würg mir da mit OPNsense einen ab.

Ping hat auch funktioniert:

PING 192.168.1.1 (192.168.1.1) from 192.168.2.1: 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.358 ms

--- 192.168.1.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.358/0.358/0.358/0.000 ms

Ich habe pfSense vor Ewigkeiten zuletzt genutzt und bin dann wegen netgate zu OPNsense gewechselt. Ich muss diesen Schritt nochmal ernsthaft hinterfragen.

Ich werde die Konfiguration jetzt nochmal exakt so mit der OPNsense nachbauen und dann werde ich sehen, ob es einfach nicht geht oder wie oder was.

Vielen Dank jedenfalls, Problem ist gelöst!

MfG

Edit: Hm, yes. It appears to be working flawlessly.

Keine Ahnung, was ich da falsch gemacht habe...kann es echt daran liegen, dass ich die FW-Regeln für den IPSec Aufbau sowohl auf dem IPSec Interface als auch dem WAN Interface hatte? Habe im Zuge des "Neuversuchens" natürlich alles sauber konfiguriert und dann hat es ebenfalls einfach funktioniert...
Öhm, ich gehe mal in die Ecke und schaue die Wand an und überlege mir, was ich falsch gemacht habe :D

Danke nochmal.

MfG

Ich muss diesen Schritt nochmal ernsthaft hinterfragen.

Das solltest du wirklich !!

dass ich die FW-Regeln für den IPSec Aufbau sowohl auf dem IPSec Interface als auch dem WAN Interface hatte?

Das ist sehr gut möglich weil das ja vollkommen falsch ist.
Das IPsec Interface ist quasi sowas wie ein internes Interface das nur den internen Traffic bedient. Also der Tunnel selber. Das WAN Interfaces "sieht" ja nur den IPsec Traffic an sich aber nicht was er intern transportiert, denn das ist ja logischerweise verschlüsselt. Letzteres "sieht" nur das IPsec Interface.
Genau deshalb gibt es diese Trennung das du den internen VPN Traffic ggf. auch mit einem Regelwerk belegen kannst.
Die beiden Regelwerke für die Interface sind aber logischerweise natürlich völlig verschieden !
Hier hast du wohl einen gehörigen Denkfehler begangen... ?!

ich gehe mal in die Ecke und schaue die Wand an und überlege mir, was ich falsch gemacht habe

Musst du nicht ! Sieh es immer positiv: Aus Fehlern lernt man !!

gelöst Frage Netzwerke Router, Routing

Mehr von support-m

Outlook App via VPNsupport-m - 6 Kommentare

Office 2021 ProPlus Aktivierung Terminalserver 2022support-m - 17 Kommentare

Internetverkehr aufzeichnen OPNsensesupport-m - 13 Kommentare

Frage zu OpenVPN Protokolleintragsupport-m - 8 Kommentare

Heiß diskutiert