Messages

The purpose of a CA in your case is to avoid a MITM attack where *another* server pretends to be your VPN Gateway.
Your client is willingly supplying username and password and by doing so compromises your VPN account.

In other words:
Your OpenVPN client verifies the signature of the server cert to make sure it is talking to the *right* server.
To verify the signature it needs the issueing CA.

If you are concerned about CA expiration, you are free to give it any lifetime you want :)

Have you tried exporting your config under "VPN->OpenVPN->Client Export" using Export Type = File Only ?
This generates a single config file containing "inline" ca+certs, usually this should work with OpenVPN-Connect client.

Das Problem ist aber, dass z. B. Unbound DNS auf A nicht den DNS Server im Netz B erreicht. Für Domain overrides.

Das lässt sich lösen, indem du in der Unbound Konfiguration unter General -> Outgoing Interfaces explizit ein Interface mit IP Adresse "im" Tunnel (in deinem Fall wohl LAN) setzt. Dann sollten die Domain Overrides klappen :)

Wäre das dann ausreichend oder brauchen beide Seiten DynDNS? 
Kriegt man damit ein zuverlässiges Site to Site VPN hin?

Eine Seite (bei OpenVPN die "Server"-Seite) reicht.

Ich würde für den SiteToSite Tunnel allerdings aus Performance Gründen IPSEC (mit beidseitigem DynDNS)  nehmen
https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html
WireGuard scheidet (wie lfirewall1243 schon erklärt hat) aus.

Für das Road-Warrior VPN würde ich einen OpenVPN Server einrichten
https://docs.opnsense.org/manual/how-tos/sslvpn_client.html

The Lifetimes/Timeouts match on each side.

Sometimes with "unstable" tunnels it is a good idea *not* to match them.
Setting the lifetimes of SideA twice the lifetimes of SideB will force SideB to initiate all the re-keying, which in my experience sometimes can lead to more stability.

Might be worth a try :)

According to your attached log file your domain is "home.example.com".
I assume this is not really the case and you have edited the log file for non-disclosure reasons.

CAA records are explained here https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization.
I would check the CAA record of your real domain, you can do this on the OPNsense with

Code Select Expand


host -t CAA myrealdomain.com


and make sure that Let'sEncrypt is allowed to issue certificates by editing the existing CAA record.

> - die Netzwerkmasken für "SEITEA" und "SEITEB" zu Parametern machen, momentan ist's hardgecodet /24
Wäre ich vorsichtig, selbst wenn man das händisch editiert hatten wir schon Kunden, wo wir das mit Fritten machen mussten und bei denen andere Werte (oder mehrere Phase 2 Entries) einfach nicht geklappt haben.

Wenn ich da noch kurz meine eigene Erfahrung beitragen darf:

-  eine abweichende "SEITEA" Netzwerkmaske klappt bei den aktuell knapp 40 von uns angebundenen Fritz!Boxen immer, die verwenden im Moment alle entweder /16 oder /23. Wahrscheinlich sind sie deshalb bei ansonstem gleichen Config-File nicht "editable" :)
Lokal (also Fritz!Box seitig) ist's immer /24, ich hatte auch noch nie die Notwendigkeit, dort etwas anderes zu verwenden.

- mehrere Phase2 Entries hat noch nie geklappt, lässt sich aber OPNSense seitig zumeist durch NAT lösen

Ansonsten bin ich bei @pmhausen und würde VPN mit Fritzen meiden wo es geht. Es ist einfach nicht wirklich absehbar ob das Endresultat wirklich stabil läuft oder nicht. Einer unserer Kunden hat mal freundlicherweise bei AVM nachgehakt warum seine Box partout mit der OPNsense keinen Tunnel aufbauen wollte und hat da sehr "bastelhafte" Hinweise bekommen sowie - durch die Blume - dass der Kram eben (ver)alt(et) ist und niemand das seit langem mal anfassen wollte (oder in Marketing Sprech: Man wollte den alten AVM VPN Server irgendwie abbilden/portieren und seither ist das Produkt etwas stehengeblieben). Dass die Kiste immer noch nix von IKE2 geschweige denn von AES-GCM weiß spricht eigentlich Bände.

Was allgemein die Verwendung von Fritz!Box VPN's angeht, bin ich weniger dogmatisch und sehe die Hauptproblematik nicht in der Stabilität (die laufen bei unseren Kunden richtig gut, deutlich stabiler als die angebundenen BinTec Router) oder der Sicherheit (neuere Fritz!Boxen können AES256 und SHA512, mit gutem PSK ist auch IKEv1 im Aggressive Mode sicher) sondern schlicht und einfach in der erzielbaren Geschwindigkeit.
Mangels CPU Leistung habe ich da mit Fritz!Boxen noch nie mehr als 15Mbit im Tunnel gesehen und das ist für manche Anwendungen einfach zu lahm.

Für die Anbindung lokaler Drucker an Terminalserverlandschaften beispielsweise taugts allemal und ist unschlagbar preiswert und einfach zu realisieren, wenn vor Ort bereits eine Fritz!Box vorhanden ist. Neu anschaffen würde ich für den Zweck keine, da gibts meist bessere Lösungen.

Ein weiterer Showstopper wird zunehmend, dass die ganze Fritz!Box VPN Implementation (im Gegensatz zum Rest der Fritz!Box :) ) nicht IPv6 fähig ist.

Any one any ideas on this ?

Make rule 5 a "pass" rule and do not negate "AllowedList".

Otherwise all clients in "AllowedList" will run into rule 6 and get WAN_PIAGW_IPv4 as gateway for all outbound traffic, which by your description seems to be what is actually happening :)

Sieht gut aus 8)

Ich würde vielleicht noch

- die Netzwerkmasken für "SEITEA" und "SEITEB" zu Parametern machen, momentan ist's hardgecodet /24
- Der Config-Entry "editable = yes;" hat bei mir in der Fritz!Box nie funktioniert. Klappt das bei dir ?

Wo könnte ich ansetzten?

Wenn du die Client-Pings an die 8.8.8.8 auf der WireGuard Schnittstelle der OPNsense rausgehen siehst, muss das Problem wohl am WireGuard Cloud Server 10.1.1.1 liegen.
Ich würde also dort das Routing und die relevanten Firewall-Rules checken.

Ist von deinem CLIENTPC/32 aus zumindest die 10.1.1.1 anpingbar ?

Have you tried to untick "Upstream Gateway" and tick "Far Gateway" (using IP 10.x.x.1) in gateway configuration for all VPN Gateways ?
Have nor tried this, but it might work :)

I'm not really familiar with NextDNS CLI, but if the WireGuard clients can reach your Pi-hole, the firewall rules relevant for DNS are probably OK and not the problem. I would assume, somehow NextDNS CLI maintains an internal accesslist for allowed clients (as other DNS resolvers, namely Unbound do) and your WireGuard clients are not part of this list.

I this is so, there would be two options:

- find that list and edit it in NextDNS CLI configuration
  might have something to do with https://github.com/nextdns/nextdns/wiki/Conditional-Configuration

- use Unbound to forward to NextDNS CLI on the OPNsense and edit the access lists under "Services -> Unbound -> Access List" to include the WireGuard Clients

Anyway, thank you so much for your help so far!

You're welcome :)
Generally speaking I have often found restarting the IPSEC service is a good way to solve strange and otherwise inexplicable IPSEC problems.

Well, I actually have a similar setup with branch offices (your NETWORK_A) connecting to a central OPNSense (your NETWORK_D) via WireGuard and from there to a customer network (your NETWORK_C) with NAT before IPSEC using a single tunnel IP (your VIRTUAL_IP_IN_NETWORK_B).
Works like a charm.

The only difference is, that in my case central OPNsense and branch offices share one IPv4 range 10.x.0.0/16 with branch offices using 10.x.[11-..].0/24 and the central OPNsense using 10.x.1.0/24, so I only have one SPD entry 10.x.0.0/16 in phase2.

When adding a second fictional SPD entry (I tried 192.168.1.1/24) I'm getting the same endpoint configuration as for 10.x.0.0/16 as I should.

So the problem might be the "mysterious" endpoint you are getting for the NETWORK_A SPD entry.
Before thinking about this: Have you tried restarting the IPSEC service ?

The interface is hardcoded in a function filter_core_get_antilockout()

Code Select Expand


    if (!empty($config['interfaces']['lan']['if'])) {
        $lockout_if = 'lan';
    } elseif (!empty($config['interfaces']['opt1']['if'])) {
        $lockout_if = 'opt1';
    } elseif (count(get_configured_interface_with_descr()) == 1 && !empty($config['interfaces']['wan']['if'])) {
        $lockout_if = 'wan';
    } else {
        return array();
    }


It will be "lan", "opt1" and "wan" in that order, "wan" only, if only one interface named "wan" exists.