Messages

Moin!

Grundsätzlich würde ich sagen: Bei Deiner gegebenen Aufgabenstellung ist meiner Meinung nach die Lancom-Variante in den 16 Standorten die günstigste Variante. Allerdings ist der Lancom R884VA bereits "End-of-Sale". Und das "End-of-Life"-Datum steht auch bereits fest: Oktober 2028, also in nur 3 Jahren. Die neueren Lancom-Geräte scheinen aber alle max. 2 ISDN-Ports zu haben. Wenn ihr also mit max. 4 Sprachkanälen auskommen würdet, wäre ein neueres Modell hinsichtlich der Firmware-Unterstützung möglicherweise sinnvoller.

Mit den Lancom Routern kann man relativ problemlos IPSEC-Verbindungen zu einer OPNsense aufbauen, sowohl IKEv2 also auch das alte IKEv1 laufen.
Die Authentifizierung mit Preshared-Key läuft in aller Regel problemlos. Bei lokaler und entfernter Identität würde ich jeweils eine Mailadresse eintragen (also FQUN).
Eine Authentifizierung mit Zertifikaten ist ebenfalls machbar. Allerdings muss man bei der Erstellung der Zertifikate SEHR genau aufpassen, welche Daten (DNS-Name, IP, Mailadresse) man in die SAN-Felder ausfüllt. Hier ist meiner Erfahrung nach StrongSwan beim Plausibilitätscheck im Verbindungsaufbau SEHR pingelig. Meine Erfahrung: Es ist viel Frickelei, irgendwann geht es und man weiß nicht wirklich, warum.
Pre-Shared-Key ist dagegen deutlich einfacherer, aber tendenziell auch etwas unsicherer.

Zum Mikrotik:
Kann es sein, dass Du im LAN zwei DHCP-Server gleichzeitig betreibst? Der Mikrotik hat anscheinend eine IP-Adresse aus deinem LAN (192.168.1.x), aber Du schreibst etwas von DHCP und dem Default-IP-Bereich eines Mikrotik (192.168.88.x). Zwei DHCPs würden auch eine Menge Probleme erklären...

Die Ping-Zeiten über LAN sehen vernünftig aus. Die eingangs beschriebenen Probleme scheinen dann ihre Ursache im WLAN zu haben. Checke mal alle Accesspoints ab, ob sie alle die gleiche SSID aussenden und die gleiche Verschlüsselung nutzen. Da es lauter verschiedene Hersteller sind: Vielleicht hilft es auch, wenn du alle bis auf einen Accesspoint abschaltest und dann testest. Dann sukzessive den zweiten einschalten und wieder testen...
Beim WLAN ist es auch wichtig, dass sich die WLAN-Kanäle nicht überlappen. Bei 2,4 GHz und 20 MHz Kanalbandbreite gibt es nur 3 überlappungsfreie Kanäle (1,6 und 11). Bei 5 GHz ist es noch deutlich komplizierter, wegen mehr möglicher Kanalbandbreiten (20,40,80,160MHz) und ggf. noch DFS (ich weiß auch nicht, wie es sich damit in Norwegen verhält. Hier musst Du aufpassen, am besten stellst du in allen Accesspoints dein Land als ein. Die Geräte sollten dann die Regulatorien einhalten).

Code Select Expand

dnslookup www.heise.de
dnslookup v1.11.1
2025/08/27 19:56:34 [fatal] Cannot make the DNS request: exchanging with 127.0.0.1:53 over udp: read udp 127.0.0.1:43432->127.0.0.1:53: read: connection refusedDie Abfrage scheint mir nicht zielführend zu sein. 127.0.0.1 ist der Localhost, im Fall von Termux also ein DNS-Resolver auf deinem Handy. Das hat IMHO wenig mit der OPnsense zu tun. Kann sein, dass der DNS-Resolver deines Handys die OPNsense fragt - sicher ist das aber nicht.

Code Select Expand

~ $ ping 192.168.1.1   #home opnsense
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=73.1 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=10.3 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=55.2 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=5.78 msDeine Ping-Zeiten gehen heftig hin und her, von 5 bis 73 Millisekunden. Du könntest da schon Probleme mit deinem WLAN haben, auch vor dem Hintergrund der von dir beschriebenen Verbindungsprobleme.
Was hast Du denn für Accesspoints? Wie angeschlossen? Bist Du mit 2,4GHz oder 5GHz verbunden? Welche Kanalbandbreiten sind konfiguriert? Hast du eine sinnvolle SSID konfiguriert (nicht, dass alle WLANs inkl. deinem Umfeld sowas wie "Fritzbox" haben)?

Dein Ping durch den Wireguard-Tunnel:

Code Select Expand

~ $ ping 192.168.3.1    #Office opnsense, also über wireguard
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=63 time=52.9 ms
64 bytes from 192.168.3.1: icmp_seq=2 ttl=63 time=11.5 ms
64 bytes from 192.168.3.1: icmp_seq=3 ttl=63 time=55.6 ms55 Millisekunden klingt plausibel, aber was ist das dann mit den 11 Millisekunden dazwischen? Was hast Du für Internetzugänge auf beiden Seiten?

Um WLAN-Probleme auszuschließen, solltest Du deinen Rechner zumindest testweise einmal per Kabel ans LAN anschließen und dann die Ping-Tests wiederholen. Wenn Du auf dem WLAN einiges an Packet Loss hast, ist es schon denkbar, dass die Smartphones "das Internet" nicht finden...

Du schreibst außerdem von unbound, dann von dnsmasq und adguard war auch noch dabei. Versuche am besten, hier einmal Ordnung hineinzubringen: Einen DNS-Resolver, ohne fancy Schnickschnack. Keine Blocklisten, kein DNSSEC, kein DNS-over-TLS,... Dann checken, ob die Namensauflösung über LAN funktioniert. Wenn OK, dann nach und nach die gewünschten Features wieder einschalten und nach jedem Aktivieren erst wieder prüfen, ob immer noch alles funktioniert. Und eventuell dabei auch den DNS-Cache leeren ("ipconfig /flushdns" unter Windows).

Schuss ins Blaue? Für mich klingt die Beschreibung nach DNS-Problem.

Ich würde vom Heimnetzwerk aus versuchen, mich systematisch durchzutesten:
- Ping auf die opnsense @home  ((W)LAN OK?)
- Ping auf 8.8.8.8  (Internet OK?)
- Ping auf opnsense @work   (Wireguard OK?)

Falls da alles OK ist, dann mit dig oder nslookup diverse DNS-Anfragen testen, z.B. nslookup www.heise.de
- Wer antwortet und was wird geantwortet?

Nutzt Du auf der opnsense @home den unbound zur Namensauflösung? Hast Du da ACLs und/oder Blocklisten aktiv? Hast Du ggf. auch eine Weiterleitung im DNS (durch den WG-Tunnel auf deinen Business-DNS) für deine Business-Domain eingetragen, falls vorhanden?

2025-04-22T14:33:15    Informational    charon    12[IKE] <con7|491> authentication of 'subdomain.dyndns.tld' (myself) with pre-shared key   
2025-04-22T14:33:15    Informational    charon    12[IKE] <con7|491> sending cert request for "C=DE, ST=##, L=##########, O=##########, E=mail@domain.tld, CN=CA"   

Der Part von deinem Log auf der OPNsense irritiert mich. Anscheinend wird versucht, eine Authentifizierung mit Zertifikat vorzunehmen. Bei PSK auf der Lancom-Seite ist dies jedoch zum Scheitern verurteilt.

Hast Du schonmal versucht, die Verbindung auf der OPNsense komplett zu löschen und neu anzulegen? Vielleicht ist irgendwo im Hintergrund durch die Testerei Schrott hängen geblieben, der jetzt stört.

Der LANCOM hat zwei andere funktionierende/aktive IPsec Tunnel vorhanden

OK, damit scheidet auch eine Überschreitung der VPN-Lizenz (bei den kleinen Lancoms sind das 5 gleichzeitige Tunnel) aus.

Du sagst dass es bei der Verwendung von PSK anstelle von Zertifikaten weniger relevant ist?

Zertifikate können dahingehend tricky werden, dass man schon bei der Erstellung penibel genau aufpassen muss, welche zusätzlichen Infos man in den SAN-Feldern hinterlegt: FQDN, FQUN, IP-Adressen, ...
Strongswan scheint da recht genau zu prüfen, ob das präsentierte Zertifikat auch wirklich zur angelegten Verbindung passt. Das hat viele Fehlermöglichkeiten und hat mich auch schon die eine oder andere Stunde Debugging gekostet... PSK hingegen nimmt einige zusätzliche Variablen aus dem Spiel und ist speziell bei IPSEC mit Gegenstellen anderer Hersteller da unempfindlicher.

Um es klar zu sagen: Zertifikate sind natürlich sicherer und bei PSK gibt es den einen oder anderen Angriffsvektor, je nach Passwort und IKE-Version/Konfig.

Ich habe die Erfahrung bei vorherigen IPsec Tunnel mit OPNsense/LANCOM/noch ein anderer Hersteller gemacht, dass bei der Authentifizierung ich rumspielen musste mit "FQDN" oder "FQUN" oder "IP Adresse" und es irgendwann mal funktioniert hat.
(ich habe hier leider die Logik noch nicht ganz verstanden)

Ich habe die Erfahrung gemacht, dass man primär auf beiden Seiten für jede Stellschraube exakt die gleichen Werte einstellen muss. Dann klappt es in aller Regel auch. Problem ist natürlich auch die unterschiedliche Benennung. Problematisch sind da die Identitätstypen (meine Empfehlung: FQUN / E-Mail-Adresse, speziell bei Dyndns) und die Einstellungen für PFS (in der Regel DH14, sowohl bei Phase1 als auch bei Phase2). Dann müssen die Hash-Funktionen übereinstimmen (SHA256 oder SHA512). Und AES-256 ist was anderes als AES-256-GCM, also genau prüfen. Ein bisschen Transferleistung ist auch immer nötig, leider.

Auf beiden Seiten ist überall der gleiche PSK eingetragen

Auf der OPNsense wird der PSK nur 1x eingegeben, bei Lancom gibt es den lokalen PSK und den entfernten PSK. Da also 2x das gleiche Passwort rein.

Ansonsten gehen mir die Ideen leider langsam aus.

Moin!

Mich irritiert nach wie vor, dass am Lancom nichts von der OPNsense ankommen soll. Jetzt schreibst Du, dass Du auf beiden Seiten dynamische IPs hast. Kann es sein, dass Du da Internetzugänge mit CGNAT hast, d.h. Deine zugewiesene IPv4 gar nicht direkt von außen erreicht werden kann?

Die Sache mit CGNAT könntest Du hier überprüfen: https://simpleip.de/
Jwewils aufrufen von einem Rechner hinter der OPNsense bzw. hinter dem Lancom.

Da werden Dir deine momentanen IPs (v4 und ggf. v6) angezeigt, wie sie im Internet gesehen werden. Speziell bei IPv4 kannst Du überprüfen, ob die IP-Adresse identisch zu der ist, welche das WAN-Interface der OPNsense bzw. des Lancoms hat.

Wenn das gegeben ist, sollte prinzipiell ein Verbindungsaufbau über IPSEC auch mit dynamischen IPs auf beiden Seiten machbar sein. Wichtig ist, dass zumindest die Seite, zu der die Verbindung aufgebaut wird, wirklich eine erreichbare IPv4 hat. Notfalls müsste die Richtung des Verbindungs-Aufbaus umgedreht werden.

Beim Identifier neige ich eher zur Mailadresse gegenüber dem FQDN. Bei der Authentifizierung mit Zertifikaten kann die Mailadresse aus dem Identifier in das Zertifikat übernommen werden und ist so eindeutig. Beim FQDN kann ein DNS-Lookup im Fall von Dyndns je nach Timing ggf. noch eine falsche IP zurückliefern. Dann gibt es einen Mismatch zwischen ankommender IP und per DNS zurückgemeldeter IP. Bei der Zertifikats-Authentifizierung habe ich hierbei auch schon Fehler gesehen. Daher der Rückgriff auf die Mailadresse (FQUN). Aber diese Problematik ist bei PSK anstelle von Zertifikaten weniger relevant.

Moin!

Grundsätzlich sieht die Config plausibel aus. Der "Eindeutige Benutzername" hat bei mir eigentlich immer gut funktioniert, das würde ich daher so lassen.

In Deinem charon-Log steht als Port die 4500, das wäre der NAT-T-Port. Hast Du zwischen den Geräten noch ein NAT? Sicherheitshalber kannst Du auf der OPNsense in den Firewall-Regeln für das WAN-Interface die UDP-Ports 500 und 4500 für das Ziel "WAN-IP" freigeben. Außerdem für ESP-Pakete eine Pass-Regel.

Am Lancom würde ich per SSH im Live-Trace den VPN-Verbindungsaufbau beobachten: Per SSH auf dem Lancom anmelden und dann "trace # vpn-status" einschalten. Der gleiche Befehl nochmals eingegeben schaltet das Tracing auch wieder aus.

Notfalls könntest Du noch checken, ob überhaupt Pakete der OPNsense beim Lancom ankommen. Mit "trace # ip-router @ wan.ip.der.opnsense" solltest Du da etwas sehen können.

Das "Ferne Gateway" kann IMHO bei mehreren Verbindungen "0.0.0.0" sein. Die Verbindungen müssen unterschiedliche "Peer Identifier" haben. Die IP-Adresse geht da dann nicht, aber man kann z.B. unterschiedliche E-Mail-Adressen nehmen. Die Mailadresse muss dafür nicht zwingend existieren.

Wie bekomme ich sowas trotzdem ans laufen? Bei der vorher genutzten Bintec war einfach die Hostadresse der Gegenstelle leer und die Verbindungen wurden efolgreich aufgebaut, nur das erlaubt ja die OPNsense nicht...

Man kann die Hostadresse auf der OPNsense auf 0.0.0.0 setzen.

Der Verbindungsaufbau sollte dann vom LTE-Router aus in Richtung OPNsense erfolgen.

Running a WIFI Accesspoint on PC hardware sounds not very energy-efficient for me.
I would buy one or more (depending on the size of the location) real accesspoints (not routers), eg. Ubiquiti and a PoE-and VLAN-capable switch. If you already have a proxmox host you could easily run an Unifi controller.

Same problem here!

I configured https://dsi.ut-capitole.fr/blacklists/download/blacklists.tar.gz as Remote ACL. Testing this URL in the browser works perfectly, but "Download ACL" fails: After downloading no categories are selectable.

I did some further investigation: SSH to opnsense and start the python script on the shell:

Code Select Expand

root@opnsense:~ # python3 /usr/local/opnsense/scripts/proxy/fetchACLs.py
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/urllib3/response.py", line 444, in _error_catcher
    yield
  File "/usr/local/lib/python3.9/site-packages/urllib3/response.py", line 567, in read
    data = self._fp_read(amt) if not fp_closed else b""
  File "/usr/local/lib/python3.9/site-packages/urllib3/response.py", line 533, in _fp_read
    return self._fp.read(amt) if amt is not None else self._fp.read()
  File "/usr/local/lib/python3.9/http/client.py", line 463, in read
    n = self.readinto(b)
  File "/usr/local/lib/python3.9/http/client.py", line 507, in readinto
    n = self.fp.readinto(b)
  File "/usr/local/lib/python3.9/socket.py", line 704, in readinto
    return self._sock.recv_into(b)
  File "/usr/local/lib/python3.9/ssl.py", line 1275, in recv_into
    return self.read(nbytes, buffer)
  File "/usr/local/lib/python3.9/ssl.py", line 1133, in read
    return self._sslobj.read(len, buffer)
socket.timeout: The read operation timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/opnsense/scripts/proxy/fetchACLs.py", line 381, in <module>
    main()
  File "/usr/local/opnsense/scripts/proxy/fetchACLs.py", line 325, in main
    for filename, basefilename, file_ext, line in acl.download():
  File "/usr/local/opnsense/scripts/proxy/fetchACLs.py", line 153, in download
    self.fetch()
  File "/usr/local/opnsense/scripts/proxy/fetchACLs.py", line 88, in fetch
    data = req.raw.read(10240)
  File "/usr/local/lib/python3.9/site-packages/urllib3/response.py", line 593, in read
    raise IncompleteRead(self._fp_bytes_read, self.length_remaining)
  File "/usr/local/lib/python3.9/contextlib.py", line 137, in __exit__
    self.gen.throw(typ, value, traceback)
  File "/usr/local/lib/python3.9/site-packages/urllib3/response.py", line 449, in _error_catcher
    raise ReadTimeoutError(self._pool, None, "Read timed out.")
urllib3.exceptions.ReadTimeoutError: HTTPSConnectionPool(host='dsi.ut-capitole.fr', port=443): Read timed out.


Internet connectivity is VDSL 100 from German Telekom, the script ran several minutes before throwing this error above. Downloading the file in a browser takes only a few seconds (27 MB). So I believe there must be a bug in the Download Remote ACL section...

I also had a look at the internet traffic (tcpdump on WAN, limited to host IP "dst.ut-capitale.fr"). While running the python script there was constantly traffic from that IP. A lot of incoming TCP packets which all got ACKed.

Any ideas?

FYI: Same error here.

Schuss ins Blaue: Hast Du die Tunnelnetze und/oder dein Heimnetz im Webproxy unter "Erlaubte Subnetze" eingetragen?

Ist das womöglich eine Windows Active Directory Domäne? Diese Infrastruktur ist stark DNS-lastig. Unter diesen Bedingungen würde ich den DNS-Dienst auf der Windows-Büchse belassen und den Pihole als Upstream-DNS-Server im Windows-DNS eintragen.