Messages

- Installation der aktuellen Version mit UFS.

Warum will man das heute noch? Es gibt dafür keinen Grund, auch nicht in einer VM.

Laut ChatGPT vermutliche Ursache: Ich hatte bei meinen Versuchen in dem bei der Installation automatisch angelegten WAN_DHCP Gateway die IP der Fritzbox eingetragen.

Ist das Interface als DHCP-Client konfiguriert, bekommt es die Gateway-IP vom DHCP und konfiguriert es automatisch.
Dass die Fritzbox das Gateway ist, ist ja in deinem Fall okay.

Ein Fehler der oft passiert und für Kommunikationsprobleme sorgt, ist ein Gateway auf den internen Interfaces einzutragen. Da darf nichts eingetragen werden.

OPNsense auf Geräte

- kein DHCP
Ich habe Kea DHCP mit einem Pool für das VLAN eingerichtet, bekam aber keine IP in meinem Client. Manuelle IP-Vergabe auf dem Client hat funktioniert. Als Ursache stellte sich heraus, daß ich (vermutlich beim Durchgehen des Wizard) den dnsmasq DHCP-Server gestartet haben muß.

Ähnliches ist mir auch schon passiert. Da war es allerdings der ISC DHCP, der gelaufen ist und den KEA Start verhinderte.

Tipp: System: Diagnostics: Services zeigt, welche Services laufen. Die rasche Kenntnis, dass ein Service nicht läuft, hilft schon mal weiter. Das System-Log sollte dann mehr dazu verraten.

- Kein Zugriff auf die Admin-Oberfläche nach Erstellung der "Standard"-Regeln
Nachdem soweit alles lief, wollte ich für das VLAN-Interface die Regeln erstellen, die ich für grundlegend halte (von unten nach oben):
1. any-Regel, um ins Internet zu kommen
2. rfc1918-Regel (block), um die anzulegenden weiteren VLANs abzuschotten
3. pass-Regel vom VLAN-Netz auf "This Firewall"
(4. pass-Regel für das Fritz-Netz war unproblematisch deshalb in Klammern)

Was ich wirklich nervig fand war, daß 3. so nicht funktioniert hat. Erst einmal war ich schon irritiert, daß innerhalb desselben Netzes (vom Client auf 192.168.99.5 zur OPNsense auf 192.168.99.1) überhaupt die block-Regel greift aber ok. Doch die pass-Regel unter 3. hat weder mit "This Firewall" noch mit 192.168.99.0/24 als Destination funktioniert.

Die Reihenfolge der Regel ist entscheidend. Die Regeln werden von oben nach unten abgearbeitet, trifft eine zu, wird sie angewandt.
Für das zutreffen sind verantwortlich: Interface, Richtung, Protokoll, IP-Version, Qull-IP u. -Port, Ziel-IP u. -Port.

D.h. wenn du RFC 1918 blockieren möchtest, muss diese Regel oberhalb der allow-any stehen.
Zugriff auf die FW sowie auch andere lokale Ressourcen musst du per Regel oberhalb der Block-RFC1918 erlauben, da diese sonst jeglichen Zugriff schon blockiert.

Toll dass du es so rasch beheben konntest.

Wünsche dann noch gutes Gelingen für deine weiteren Vorhaben mit OPNsense!

Es gibt da bekannte Probleme mit VLANs auf Realtek Schnittstellen auf OPNsense (bzw. FreeBSD allgemein). Dazu kann ich aber nichts Genaueres sagen. Ich hab diese immer gemieden.
Im Forum gibt es aber einige Threads dazu. Vielleicht trifft das hier zu.

Ich glaube gelesen zu haben, dass ein spezieller Treiber verfügbar ist, der Probleme behebt.

Zum Testen verwende ich aktuell nur einen kleinen UGREEN webmanaged Switch. Dort habe ich leider nur eingeschränkte Konfigurationsmöglichkeiten:

Entweder kann ich einen Port als Tagged-Port konfigurieren, wenn die Port Art auf Trunk steht.
Oder eine PVID setzen, wenn der Port auf Zugriff steht.

Dann macht er das wahrscheinlich automatisch.

Zum Testen lass mal den Switch weg und verbinde den Rechner direkt mit OPNsense. In der Netzwerkkonfiguration des Rechners musst du dann das VLAN einstellen.

Hallo,

Port 4: Access-Port, PVID 50 (PC angeschlossen)

muss abgesehen davon nicht das VLAN auf dem Port als untagged definiert werden?

PVID sorgt normalerweise nur dafür, dass eingehende Pakete getaggt werden, was auch nötig, aber eben nur die halbe Miete ist.

You only have the following in PSK setting:
Local Identifier    Here I use my WAN IP.
Remote Identifier    Here I use a Distinguished name (same as used in legacy Distinguished name and is a xxx.yyy.zz domain name)
Pre-Shared Key      Our joint and unique PSK as set in both ends.
Type                PSK

There is really no "Id" to specify here apart from Local and Remote identifier.

The ID settings in question are in the local and remote authentication settings. ID is short for identifier.

In the local specify the same string as the local identifier in the PSK.
And in the remote the same as remote identifier.

There is nothing in any NAT section apart from this:

So yes, this is the 25.x series section. "Firewall: NAT: Source NAT" is only available in newer versions.

So in your case you should see automatically generated rules on the Firewall: NAT: Outbound page, presumed automatic or hybrid rule generation is enabled. If you change this setting ensure to hit the save button.

If there is nothing, also check the gateway settings in System: Gateways: Configuration.
The WAN gateway should be displayed there. Push the Edit button and ensure that "Upstream Gateway" is checked.

- Phase 2 traffic selector: 0.0.0.0/0 === 0.0.0.0/0

What's the sense of having 0.0.0.0/0 for both sites?

Normally local and remote network should not overlap to function properly.

[Reqid = <blank>]

And is using the exact IP/PSK and similar in my IPSec legacy working totally fine and is up
and could reach network on the other side of IPSec.

For testing the new connection you have to disable the legacy, however.

I'm a little puzzled about the Local and Remote Authentication screens.

The are the authentication settings.
In local you define, how your server authenticates on the remote site.
And in remote you define, how the remote site has to authenticate on your server.

I think, it's necessary to state a local and a remote identifier in the pre-shared key settings. And then use the same in the local and remote settings of the connection. This is the only way, IPSec can select the proper PSK in case, you've multiple.
This means, you will have to enter the respective ID from the PSK in the authentication settings.

Reqid = <blank>    This one I am not sure if needs to be populated with anything if not using manual certificates ?

Recent versions set a unique requid automatically, as I've read. This didn't work in the past, however. So I've stated a unique one (above of 10) for each tunnel.

ESP proposals = default

You should remove the check at default and select a proper for your needs here. The same is true for the phase 1.
According to your screenshot of the legacy settings, you need aes256-sha256-modp1024[DH2].

In Legcay IPSec you are manually defining "My identifier" and "Peer identifier"
where in my legacy setting I could not find that setting !?

You mean in the new connections?
As mention, you have to state in the PSK  and authentication settings.

Ps. I have using OpnSense for many years and pfSense (before they stagnated and I moved to much better OpnSense and never looked back. :-)

Me too. :-)

Ok, so I have put NAT back on Automatic, there was/is no automatic rules at the bottom of that page.

Do you have a WAN rule in Firewall: NAT: Source NAT instead?

I've disabled NAT and it all still seems the same.

Disabling NAT is a bad idea at all. This disables the outbound NAT, which might be required to access anything on the WAN side from behind.

Check if the default route is set properly:
System: Routes: Status

The default route should point to the internal IP of the upstream router.

Also check the outbound NAT, if you didn't set up the new source NAT yet.
Firewall: NAT: Outbound
Either automatic or hybrid mode should be enabled and down under automatic rules, you should find rules on WAN for your LAN subnet.

If you have source NAT rules configured, recheck them.

Also ensure, that didn't state a gateway in the LAN interface settings.

For nat and routing purposes you need to assign an interface to the respective OpenVPN instance.

To do so, go to Interfaces: Assignments. At "Assign a new interface" select ovpnc1 and state a description like remoteX.
Open the interface settings and enable it.

Then you can specify the interface in an SNAT rule and it gives you a specific alias for the interface address for the translation.

I tried to give constructive infos and recommendations though.

Again: Natting on your site is no option to solve this.

You can translate (nat) the remote subnet into something else, but this must be done on the remote site.

With overlapping subnets locally and in the IPSec policy, routing is not going to work at all.

You can redirect the traffic to the desired gateway with a policy-routing rule for direction out on the WAN.

Don't forget to add a proper outbound /source NAT rule. As far as I know, this has to be added to the WAN, but with the translation address of the real outgoing interface.