Messages

Ein Trace-Route direkt von den beiden Firerwalls kann dir auch schon weiterhelfen.

Wenn sich das in 26.1 nicht geändert hat, erfordert dies aber eine statische Route für das Remote-Netz auf eine lokale Interface IP. So jedenfalls bei policy-based IPSec. Die IP muss dann auch in der Policy der Remoteseite stehen.

Probably RDP is blocked from outside of its local subnet by the remote server.

Go into its firewall settings and edite the respective rule to allow outside access or add only the VPN subnet to the allowed sourcees.

The guide about road warrior wireguard connection explain how to set the outbound nat rule, my question is: if I route the connections through the wireguard gateway giving to it an higher priority than wan and setting it as "possible default gateway", I still need the nat outbound rule?

I'm wondering, which route you're talking about.
Since you mentioned a road warrior wireguatd, you might route the whole upstream traffic from the clients over the VPN. But these routes are only defined on client side. So the route priority might just secure that upstream traffic is routed to the VPN server.

If so, yes, you need an outbound NAT rule for translating the source IP in upstream packets from VPN clients into the WAN address.

NAT oubound rule is by default enabled only on wan gateway?

Yes, but it only nats upstream traffic from local subnets, but not from VPN subnets.

So you have to enable the hybrid mode and add a rule to WAN for the source of the VPN subnet and specify the WAN address as translation.

Ja. Mit einer Linux Bridge kann ich jedes virtuelle Interface von Gast-VMs wie auch Hardware Interface verbinden, von beiden auch mehrere. Das ist dann einfach eine Layer 2 Verbindung wie ein vSwitch auf dem alles offen ist.

Ich habe aber auf jeder Bridge nur eine Hardware NIC und eine VM NIC. Nur auf der LAN Bridge hat der Host auch eine IP.
Da läuft auch PPPoE wunderbar drüber.

Über eine Linux Bridge.

Habe das vielleicht unglücklich formuliert, aber es ist ja dennoch eine Verbindung.

Passthrough der kompletten Netzwerkkarte ist natürlich auch eine Option.

Hätte ich auch vorgezogen, aber das macht meine Hardware nicht mit. :-(

Ich sehe nicht viel Mehrwert, für jedes VLAN eine eigene virtuelle Netzwerkkarte anzulegen, denn letztlich wird der Datenverkehr für die LANs immer über ein und die selbe Netzwerkverbindung geleitet.

Wenn der Hypervisor die auch ohne ordentlich durchschleift, sollte das auch nicht nötig sein. Aber eventuell muss ihm das erst beigebracht werden.

Ich habe meine OPNsense hier auf KVM virtualisiert und auf dem Netzwerkport zum WLAN AP mit 5 VLANs auch nichts davon am Host eingerichtet, nachdem der nicht mehr damit tun soll, als die Hardware-Schnittstelle mit der VM zu verbinden. Das läuft seit Jahren so ohne Probleme.

Wenn du aber den kompletten Trunk an OPNsense anbindest, musst du auf jeder OPN jedes VLAN samt einer IP einrichten und sicherstellen, dass beide über diese eine Layer 2 Verbindung haben, damit CARP funktioniert.

Die you state a description for your services?
The service widget shows only the description.

Basically this should be doable, I think. However, the ACME client won't be able to draw or renew the certificate for the domain anymore, if it points to a private IP address.
So this doesn't make sense to me at all.

Maybe you should rather consider a strong access password for your services than routing them over the VPN.
Or if you don't need to provide public access to them, but via VPN, use your private PKI and install the CA certificate on all involved devices.

Keep the DNS record in the public DNS, so that Caddy can draw certificated for the domain and just create an access List for the allowed networks (Caddy: Reverse Proxy: Access).
Then edit the responsible handler and select the access list you've created before. So Caddy will limit access to the stated networks in the access list.

For restricting access to local network only, I've created an access list with all RFC 1918 subnets for instance.

As you can read in the OPNsense doc title, you have linked, Strongswan is used for IPSec and the new GUI implements their new terminology.

Going down to Migrating from tunnels to connections they explain, where you can find the settings in the section now, which were former known as phase 1 and phase 2.

Also for beginners it's recommended to display the the help hints in the GUI. And if you are looking for special settings, you have to enable the advanced mode. Then it gives you options to state rekey time and some more.

Why want you define your own proposals? If I open the drop-down list, I can find any combination, I can think of. I'm missing nothing here.

Referre to the Strongswan docs on how it works and how you enable PFS and what the default proposal is: https://docs.strongswan.org/docs/latest/config/rekeying.html#_ipsec_sas

To use PFS, key exchange methods may be added to the proposals for the IPsec SAs e.g.
esp_proposals = aes128-sha256-ecp384-modp3072

I've as well migrated my legacy IPSecs to the new connections. Yes, it took some time of work and diving into the new settings, but now all work again as expected.

- Setting "reply-to" tagging to the appropriate gateway did not help

Not clear, what you did here.

- Interface configuration for that gateway is DHCP

If the interface is configured as DHCP client, the gateway is usually assigned automatically. So nothing to do here.

- Firewall rule is defined on correct interface (and is where I changed the "reply-to tagging setting).

State a unique description for the rule and enable logging. Then try to access your webserver from the internet and check in the firewall live view if the rule is applied.

If it is, but the replies go out to the wrong gateway anyway, you can select the proper gateway at "reply-to" in the advanced features of the corresponding firewall rule to force replies to it.

tcpdump shows connection replies from activity on the second gateway being sent out the first one despite all attempts I've made to direct the traffic correctly.

The "reply-to" tagging is responsible to route replies back to the correct gateway.
This presumes that
- you have the proper gateway stated in WAN interface settings in case manual IP configuration
- and that the firewall rule, which is passing the incoming traffic to the web server, is defined on the incoming interface (no group or floating pass rule must match the traffic).

Note that interface group or floating rules have precedence over interface rules.

In der Firewall Regel ist der Source Port nun auch nicht mehr zu finden?

Dann sollte es ja eigentlich funktionieren, vorausgesetzt, dein Netzwerk ist so simple aufgebaut und konfiguriert, wie wir uns das vorstellen dürfen. Details dazu möchtest du ja nicht bekannt geben.
Die Empfehlung, den Traffic mittels Packet Capture zu analysieren, hatte ich auch schon gegeben.

Wenn da nicht mal mehr als "kein Erfolg" zurückkommt, ist es nicht wirklich möglich, dir weiter zu helfen.

@Patrick
Vielleicht könntest du deinen gewichtigen Einfluss nutzen, dass die OPN GUI dahingehend optimiert, dass Advanced Settings immer angezeigt werden, wenn gesetzt.
Ich hatte mich selbst schon öfter über diesen Umstand geärgert.

Auch so bspw., dass gesetzte Optionen, die nur mit "advanced mode" oben eingeschaltet, angezeigt werden, standardmäßig beim Öffnen nicht sichtbar sind.