Messages

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.

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.