Messages

What is the log output? Something like: no matching peer config found? The ID fields in "Edit local" and "Edit Remote" are part of the strongswan config (/usr/local/etc/swanctl/swanctl.conf)

1st screenshot: local address

is it the address of the wan interface or is it the public ip which differs from the wan interface ip?

premise: firewall rules and port forwarding is correct

Windows client and strongswan server is odd because of windows.

Hint: https://docs.strongswan.org/docs/latest/interop/windowsClients.html

it might be a good idea to test the setup with linux + strongswan or android + strongswan app

Ich verstehe deinen Gedanken beim Aufbau des Netzwerks nicht. Wenn die OPNSense als Gateway/Firewall dienen soll, warum dann nicht ein weiteres Netz wie 192.168.60.0/24 für Clients/Server hinter der OPNSense und OPNSense-WAN ist dann eben im LAN der Sonicwall. Für mich sieht es so aus, dass die Sonicwall, OPNSense, Clients/Server alle in 192.168.6.0/24 hängen und du nur mit dem Gateway rumspielst.



P.S. ich beneide dich, dass du nicht auf die Sonicwall darfst. Ich finde Sonicwall furchtbar.

Es ist nunmal die IP der OPNSense. IKEv2/IPSec ist manchmal etwas Tricky, aber wenn es erstmal läuft, ist es ein Traum.

Das ist wohl wahr :)

Das ist eine sehr interessante Frage, darüber habe ich noch nie wirklich nachgedacht, obwohl ich auch viel vanilla FreeBSD mit pf einsetze und teilweise sehr merkwürdige Sonderfälle habe. Um Aussagen darüber zu treffen, müsste man sich aber die konkrete Implementierung im Kernel angucken. Wenn ich nur mal stumpf spekuliere und behaupte, dass der Durchlauf der Regeln O(n) ist, wäre es gefühlt besser ein "block quick" relativ weit oben zu haben, weil der Durchlauf dann endet. "Default deny" greift ja erst, wenn keine andere Regel zutrifft und dafür müssen alle Regeln geprüft werden.

Oder habe ich da einen Denkfehler?

Wenn ich google, dann wird gesagt, dass irgendwo nicht die feste IP eingetragen werden muss, sondern die WAN-IP der aufbauenden OPNsense. Habe aber nicht durchdrungen wo. Wäre das ein Ansatz?

wie hast du es denn konfiguriert bei der aufbauenden OPNSense?

Die Anfragen werden immer mit "Default deny / state violation rule" geblockt, obwohl alles offen sein müsste.

Auf welcher Seite werden sie denn geblockt?

Habe auf beiden seiten vom internen subnetz zum remote subnetz und retour eine Regel auf dem IPsec Interface

Welche Regeln gibt es denn für das Interface des jeweiligen subnets? Wenn es da evtl. schon geblockt wird, bringen dir die Regeln auf dem IPSec-Interface gar nichts.

Hallo,

I've been using IKEv2 with EAP‑TLS for years (not OPNsense but vanilla FreeBSD with strongswan) and have seen various odd issues, all of them were client issues.

On iOS and other Apple os, these problems are often due to Apple's strict certificate requirements, for example:

- certain certificate extensions must be marked as critical
- client certificates may fail if their lifetime exceeds one or two years (I don't remember, but currently I use 365 days for server and client certs)