Messages

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)