Messages

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.

If snmp does not help you should analyze the traffic with tcpdump and/or wireshark.

Printer drivers often try to get the status of the printer via SNMP (UDP/161). So you could try to allow this protocol.

Ein Lancom 1783VA hat eine Freescale P1014E CPU, also keine Intel oder ARM Architektur. Dürfte daher nicht machbar sein.

tcpdump und Lancom VPN-Trace wären an dieser Stelle auch meine Empfehlung. Du kannst auch gerne die Lancom Trace-Ausgabe posten, ggf. anonymisiert.