VPN via IPv6

dtrunk90

Benutzer
Mitglied seit
09. Mai 2020
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
Hallo zusammen,

da mein ISP mir nur eine öffentliche IPv6 gibt, ich für eine IPv4 Adresse keine 5€ mtl. latzen möchte und damit VPN über FRITZ!Box ausgeschlossen ist versuche ich es über meinen NAS. Immerhin möchte ich nur diesen von außen zugänglich machen.

Nun habe ich mir diese beiden Anleitungen gegeben und durchgeführt:
https://macandegg.de/forum/#/discussion/97/fritzbox-konfiguration-ipv6-einschalten
https://macandegg.de/forum/#/discussion/87/openvpn-mit-ipv6-ipv4-auf-synology-nas-einrichten

Leider bekomme ich aber immernoch keine Verbindung mit meinem Android und OpenVPN Connect App hin.

Zur Hard- und Software:
Router: AVM FRITZ!Box 7430
NAS: Synology DS918+ mit aktuellstem DSM (7.1-42661 Update 2)

Es folgen Screenshots der relevanten Konfigurationen.

FRITZ!Box:
Bildschirmfoto vom 2022-06-29 22-20-48.pngBildschirmfoto vom 2022-06-29 22-25-42.png
Anmerkung: Hatte auch bereits versucht den UDP-Port manuell freizugeben, aber die Verbindung klappte dennoch nicht.

DSM:
Bildschirmfoto vom 2022-06-29 22-26-40.pngBildschirmfoto vom 2022-06-29 22-26-54.pngBildschirmfoto vom 2022-06-29 22-27-47.pngBildschirmfoto vom 2022-06-29 22-28-22.pngBildschirmfoto vom 2022-06-29 22-41-00.png

Die exportierte Konfigurationsdatei enthielt seltsamerweise `remote YOUR_SERVER_IP ...` anstelle meiner DDNS-Adresse. Das hatte ich auch schon versucht manuell vor dem Import beim Client zu ändern. Aber auch das hat nichts gebracht.

Was habe ich übersehen?

LG
Danny.
 

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.137
Punkte für Reaktionen
898
Punkte
424
Ipv6 server Modus brauchst du nur wenn du innerhalb des VPN Transfer Netz ipv6 nutzen willst. Brauchst also eher nicht.

Auf LAN 1 solltest du den Haken bei Standard Gateway setzen.

Firewall sollte ports für openvpn freigeben, nicht für ipsec.
Und der VPN Schnittstelle ebenfalls dem IP Kreis des Tunnelnetzes der Zugriff auf DSM oder andere gewünschte Dienste erlaubt werden.
Besser die Regeln bei den Schnittstellen und die Liste 'Alle Schnittstellen' einfach leer lassen, auch wenn die Syno Automatik dort immer ihre Einträge machen will.
Oder mal zum Test die Firewall vorübergehend deaktivieren.

Der Konfiguration Export enthält immer nur einen Dummy Eintrag. Den muss man immer auf seine IP oder Domain umschreiben vor dem Import.
nslookup für die Domain zeigt auf die ipv6 der NAS?

Portfreigabe in der Fritzbox für den UDP Port von openvpn?
nur weil die selbstständige Freigabe erlaubt ist macht die DS das nicht ohne zugehörige Einstellung (Routerkonfig). Aber die Freigabe von Hand ist immer zu bevorzugen, und die selbstständige Freigabe zu deaktivieren.
Dann weiß man was Sache ist und keine Automatik öffnet Tore die nicht gewünscht sind.

Der vpn Client kann auch ein log ausspucken das weiter hilft zu sehen wo es hängt.


Falls die 7430 irgendwann mal Firmware 7.5 bekommt, bekommt sie vermutlich auch wireguard und kann dann VPN mit ipv6.
 
  • Like
Reaktionen: tschaefer

dtrunk90

Benutzer
Mitglied seit
09. Mai 2020
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
  • IPv6 Servermodus deaktiviert
  • Clients den Server-LAN-Zugriff erlauben (ich vermute das meintest du mit "der VPN Schnittstelle ebenfalls dem IP Kreis des Tunnelnetzes der Zugriff auf DSM oder andere gewünschte Dienste erlauben"?) möchte ich nicht, da ich nur Zugriff auf das NAS selbst erlauben möchte. Laut der von mir verlinkten Anleitung steht nämlich:
Wenn man nun per VPN Server nicht nur auf die Synology selbst sondern auch auf andere Geräte in Eurem Netzwerk zugreifen soll, so setzt einen Haken bei "Clients den Server-LAN-Zugriff erlauben".
Bildschirmfoto vom 2022-06-30 08-48-42.png

  • LAN 1 hat bei IPv4 und IPv6 nun den Haken bei Standard-Gateway
Bildschirmfoto vom 2022-06-30 08-47-13.pngBildschirmfoto vom 2022-06-30 08-47-24.png

  • In der Firewall habe ich nun den gleichen Port wie in OpenVPN angegeben freigegeben
  • Habe die Firewall auch testweise mal vorübergehend deaktiviert, ohne Erfolg
Bildschirmfoto vom 2022-06-30 08-49-10.png

  • In der Konfiguration habe ich YOUR_SERVER_IP mit meiner DDNS ersetzt

  • Port für OpenVPN ist nun für IPv4 und IPv6 manuell in der FRITZ!Box freigegeben
Bildschirmfoto vom 2022-06-30 08-49-46.png

  • nslookup zeigt wohl auf IPv4 und IPv6 (gibt 2 Einträge):
Code:
Server:        127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:    ...
Address: XX.XXX.XX.XXX
Name:    ...
Address: XXXX:XXX:XXXX:XXXX:XXX:XXXX:XXXX:XXXX

VPN Client log:
Code:
09:06:09.607 -- ----- OpenVPN Start -----

09:06:09.608 -- EVENT: CORE_THREAD_ACTIVE

09:06:09.614 -- OpenVPN core 3.git::d3f8b18b:Release android arm64 64-bit PT_PROXY

09:06:09.616 -- Frame=512/2048/512 mssfix-ctrl=1250

09:06:09.626 -- UNUSED OPTIONS
1 [tls-client]
3 [pull]
5 [script-security] [2]

09:06:09.630 -- EVENT: RESOLVE

09:06:09.697 -- Contacting XX.XXX.XX.XXX:XXXXX via UDP

09:06:09.699 -- EVENT: WAIT

09:06:09.706 -- Connecting to [XXXXXXXXXXXXXXXXXXXX]:XXXXX (XX.XXX.XX.XXX) via UDPv4

09:06:19.629 -- Server poll timeout, trying next remote entry...

09:06:19.641 -- EVENT: RECONNECTING

09:06:19.652 -- EVENT: RESOLVE

09:06:19.666 -- Contacting [XXXX:XXX:XXXX:XXXX:211:32ff:fec5:2e1f]:XXXXX via UDP

09:06:19.669 -- EVENT: WAIT

09:06:19.684 -- Connecting to [XXXXXXXXXXXXXXXXXXXX]:XXXXX (XXXX:XXX:XXXX:XXXX:211:32ff:fec5:2e1f) via UDPv6

09:06:29.637 -- Server poll timeout, trying next remote entry...

09:06:29.646 -- EVENT: RECONNECTING

09:06:29.660 -- EVENT: RESOLVE

09:06:29.669 -- Contacting XX.XXX.XX.XXX:XXXXX via UDP

09:06:29.671 -- EVENT: WAIT

09:06:29.680 -- Connecting to [XXXXXXXXXXXXXXXXXXXX]:XXXXX (XX.XXX.XX.XXX) via UDPv4

09:06:39.645 -- Server poll timeout, trying next remote entry...

09:06:39.648 -- EVENT: RECONNECTING

09:06:39.653 -- EVENT: RESOLVE

09:06:39.666 -- Contacting XX.XXX.XX.XXX:XXXXX via UDP

09:06:39.667 -- EVENT: WAIT

09:06:39.675 -- Connecting to [XXXXXXXXXXXXXXXXXXXX]:XXXXX (XX.XXX.XX.XXX) via UDPv4

09:06:49.653 -- Server poll timeout, trying next remote entry...

09:06:49.657 -- EVENT: RECONNECTING

09:06:49.665 -- EVENT: RESOLVE

09:06:49.674 -- Contacting [XXXX:XXX:XXXX:XXXX:211:32ff:fec5:2e1f]:XXXXX via UDP

09:06:49.676 -- EVENT: WAIT

09:06:49.688 -- Connecting to [XXXXXXXXXXXXXXXXXXXX]:XXXXX (XXXX:XXX:XXXX:XXXX:211:32ff:fec5:2e1f) via UDPv6

09:06:59.660 -- Server poll timeout, trying next remote entry...

09:06:59.667 -- EVENT: RECONNECTING

09:06:59.682 -- EVENT: RESOLVE

09:06:59.693 -- Contacting [XXXX:XXX:XXXX:XXXX:211:32ff:fec5:2e1f]:XXXXX via UDP

09:06:59.695 -- EVENT: WAIT

09:06:59.702 -- Connecting to [XXXXXXXXXXXXXXXXXXXX]:XXXXX (XXXX:XXX:XXXX:XXXX:211:32ff:fec5:2e1f) via UDPv6

09:07:09.632 -- EVENT: CONNECTION_TIMEOUT

09:07:09.645 -- EVENT: DISCONNECTED

09:07:09.646 -- Tunnel bytes per CPU second: 0

09:07:09.647 -- ----- OpenVPN Stop -----

EDIT: Nmap gibt mir allerdings die Info, dass der Port nicht offen ist:
Code:
$ nmap -p 49999 XXXXXXXX.XXXXXXXX.XX
Starting Nmap 7.80 ( https://nmap.org ) at 2022-06-30 10:42 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.05 seconds
$ nmap -p 49999 -Pn XXXXXXXX.XXXXXXXX.XX
Starting Nmap 7.80 ( https://nmap.org ) at 2022-06-30 10:42 CEST
Nmap scan report for XXXXXXXX.XXXXXXXX.XX (XX.XXX.XX.XXX)
Host is up.
Other addresses for XXXXXXXX.XXXXXXXX.XX (not scanned): XXXX:XXX:XXXX:XXXX:211:32ff:fec5:2e1f
rDNS record for XX.XXX.XX.XXX: aftr-XX-XXX-XX-XXX.XXXXXXXXXXXXXXXXX.de

PORT      STATE    SERVICE
49999/tcp filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 2.44 seconds
 
Zuletzt bearbeitet:

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.308
Punkte für Reaktionen
2.867
Punkte
423
Die IPv6 des NAS endet wohl auf :2e20, der Client spricht aber :2e1f an, vermutlich die IPv6 der Fritzbox?
Portweiterleitung gibt es bei IPv6 nicht mehr, nur noch Portfreigaben (Firewall). Da musst du umdenken. Der Client muss also die IPv6 der DS ansprechen.
Wie/Wo aktualisierst du denn dein DDNS? Der DDNS-Client auf der DS macht m.W. nur IPv4.

Eine einfache Methode geht mit MyFritz. MyFritz aktivieren, dann in der FB eine MyFritz-Freigabe statt einer normalen Portfreigabe machen. Dann wird auch die IPv6 der DS über <NameDerDS>.<MyFritzID>.myfritz.net DNS-auflösbar.

Edit: Ich würde aber eher auf Wireguard in der aktuellen 7.39er-Beta oder der kommen 7.50 setzen.
 
  • Like
Reaktionen: tschaefer

dtrunk90

Benutzer
Mitglied seit
09. Mai 2020
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
Ich habe via nmap auch mal direkt die IPv6 auf den Port getestet (sowohl die IPv6 der FRITZ!Box als auch die IPv6 der DS). Beides steht auf "STATE filtered". Da scheint also etwas Anderes zuvor Probleme zu machen. Die Portfreigabe sieht meines Erachtens nach korrekt aus. DDNS auf der DS kann auch IPv6 (siehe Screenshot). Und dort steht auch für LAN 1 die mit Endung :2e1f drin.

Die MyFRITZ-Methode brauche ich ja zwecks Port-Problemen nicht erst ausprobieren...

Und auf FRITZ!OS 7.50 zu warten löst mein Problem ja nicht. Wer weiß wann und ob mein Router die neue Firmware bekommen wird.
 

Anhänge

  • Bildschirmfoto vom 2022-06-30 10-56-38.png
    Bildschirmfoto vom 2022-06-30 10-56-38.png
    60,1 KB · Aufrufe: 20
Zuletzt bearbeitet von einem Moderator:

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.308
Punkte für Reaktionen
2.867
Punkte
423
Aber deine Portweiterleitung geht auf :2e20
1656579887975.png

DDNS auf der DS kann auch IPv6 (siehe Screenshot)
Ja, sieht so aus, aber funktioniert es auch (s. nslookup -q=aaaa <name>.synology.me)? Bei mir wurde im DNS bei Synology immer nur die IPv4 gesetzt.
 

dtrunk90

Benutzer
Mitglied seit
09. Mai 2020
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
Habe nmap falsch ausgeführt und auf TCP, nicht UDP gescannt. Der Port ist also mit der DDNS-Adresse offen:
Code:
# nmap -sU -p U:XXXXX XXXXXX.synology.me
Starting Nmap 7.80 ( https://nmap.org ) at 2022-06-30 11:12 CEST
Nmap scan report for XXXXXX.synology.me (82.135.87.232)
Host is up (0.017s latency).
Other addresses for XXXXXX.synology.me (not scanned): XXXX:XXX:XXXX:XXXX:211:32ff:fec5:2e1f
rDNS record for XX.XXX.XX.XXX: aftr-XX-XXX-XX-XXX.XXXXXXXXXXXXX.de

PORT      STATE         SERVICE
XXXXX/udp open|filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 0.44 seconds

nslookup zeigt wie oben bereits erwähnt 2 Einträge. Einen für IPv4 und einen für IPv6. Mit -q=aaaa Parameter bekomme ich nur die IPv6 Adresse zurück, die auf :2e1f endet.
 

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.308
Punkte für Reaktionen
2.867
Punkte
423
Da steht aber bei der IPv6 "not scanned". Das Ergebnis ist wohl das für IPv4.
Prüf mal deine Portfreigabe.
 

dtrunk90

Benutzer
Mitglied seit
09. Mai 2020
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
Code:
# nmap -sU -p U:XXXXX -6 XXXX:XXX:XXXX:XXXX:211:32ff:fec5:2e1f
Starting Nmap 7.80 ( https://nmap.org ) at 2022-06-30 11:25 CEST
Nmap scan report for XXXX:XXX:XXXX:XXXX:211:32ff:fec5:2e1f
Host is up (0.00054s latency).

PORT      STATE         SERVICE
XXXXX/udp open|filtered unknown
MAC Address: XX:XX:XX:XX:XX:XX (Synology Incorporated)

Nmap done: 1 IP address (1 host up) scanned in 0.48 seconds
 

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.308
Punkte für Reaktionen
2.867
Punkte
423
Du testest hoffentlich nicht von intern :rolleyes:
 

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.137
Punkte für Reaktionen
898
Punkte
424
Mich stört immer noch die 2e20 (Fritzbox sagt dies für das NAS) vs 2e1f (dynDNS?).

Kannst mal die IPv6 auf der Schnittstelle von dhcp-PD auf automatisch umstellen?
PD braucht die DS eigentlich nur, wenn sie selbst als "Router" noch Subnetze an nachfolgende Geräte verteilen muss.

Server-LAN Zugriff habe ich nicht erwähnt und brauchst du auch nicht wenn du nicht willst. Ich bezog mich rein auf die Firewall und dass der Zugriff aus dem 10.8.0.x Netz (in dem die verbundenen VPN Clients hängen) erlaubt ist.

Ansonsten kannst auch mal mit lokaler IPv6 probieren ala fe80::211:32ff:fec5:2e20 oder welche dir die DS direkt für ihre Schnittstelle dann anzeigt.
Dann wüsste man mal, ob der VPN Server antwortet.
 

dtrunk90

Benutzer
Mitglied seit
09. Mai 2020
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
Du testest hoffentlich nicht von intern :rolleyes:
Daran hatte ich tatsächlich nicht gedacht. Habe es mal mit Smartphone-Hotspot via Laptop probiert. So bin ich außerhalb. Tatsächlich bekomme ich dann für nmap Anfrage über DDNS für den UDP-Port das Ergebnis für IPv4 mit STATE open|filtered und direkt mit der IPv6-Adresse bekomme ich STATE filtered. Also nicht open.
Mich stört immer noch die 2e20 (Fritzbox sagt dies für das NAS) vs 2e1f (dynDNS?).

Kannst mal die IPv6 auf der Schnittstelle von dhcp-PD auf automatisch umstellen?
PD braucht die DS eigentlich nur, wenn sie selbst als "Router" noch Subnetze an nachfolgende Geräte verteilen muss.

Server-LAN Zugriff habe ich nicht erwähnt und brauchst du auch nicht wenn du nicht willst. Ich bezog mich rein auf die Firewall und dass der Zugriff aus dem 10.8.0.x Netz (in dem die verbundenen VPN Clients hängen) erlaubt ist.

Ansonsten kannst auch mal mit lokaler IPv6 probieren ala fe80::211:32ff:fec5:2e20 oder welche dir die DS direkt für ihre Schnittstelle dann anzeigt.
Dann wüsste man mal, ob der VPN Server antwortet.
Ja, die 2e20 vs 2e1f irritiert mich auch. Die öffentliche IPv6 endet laut FRITZ!Box mit c730 - ist also wieder eine völlig Andere.
DS sagt mir die IPv6 von LAN 1 endet mit 2e1f (siehe Screenshot). Wenn ich das als remote in der ovpn config angebe klappt auch dann die Verbindung intern nicht.
Client log:
Code:
12:11:52.808 -- ----- OpenVPN Start -----

12:11:52.809 -- EVENT: CORE_THREAD_ACTIVE

12:11:52.812 -- OpenVPN core 3.git::d3f8b18b:Release android arm64 64-bit PT_PROXY

12:11:52.816 -- Frame=512/2048/512 mssfix-ctrl=1250

12:11:52.817 -- UNUSED OPTIONS
1 [tls-client]
3 [pull]
5 [script-security] [2]

12:11:52.818 -- EVENT: RESOLVE

12:11:52.823 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:11:52.824 -- EVENT: WAIT

12:11:52.831 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:11:52.832 -- Client terminated, restarting in 2000 ms...

12:11:54.833 -- EVENT: RECONNECTING

12:11:54.846 -- EVENT: RESOLVE

12:11:54.851 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:11:54.853 -- EVENT: WAIT

12:11:54.857 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:11:54.858 -- Client terminated, restarting in 2000 ms...

12:11:56.839 -- EVENT: RECONNECTING

12:11:56.844 -- EVENT: RESOLVE

12:11:56.847 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:11:56.849 -- EVENT: WAIT

12:11:56.853 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:11:56.854 -- Client terminated, restarting in 2000 ms...

12:11:58.845 -- EVENT: RECONNECTING

12:11:58.849 -- EVENT: RESOLVE

12:11:58.852 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:11:58.853 -- EVENT: WAIT

12:11:58.856 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:11:58.858 -- Client terminated, restarting in 2000 ms...

12:12:00.858 -- EVENT: RECONNECTING

12:12:00.866 -- EVENT: RESOLVE

12:12:00.872 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:00.874 -- EVENT: WAIT

12:12:00.877 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:00.878 -- Client terminated, restarting in 2000 ms...

12:12:02.869 -- EVENT: RECONNECTING

12:12:02.877 -- EVENT: RESOLVE

12:12:02.883 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:02.885 -- EVENT: WAIT

12:12:02.887 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:02.888 -- Client terminated, restarting in 2000 ms...

12:12:04.885 -- EVENT: RECONNECTING

12:12:04.889 -- EVENT: RESOLVE

12:12:04.895 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:04.899 -- EVENT: WAIT

12:12:04.905 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:04.907 -- Client terminated, restarting in 2000 ms...

12:12:06.900 -- EVENT: RECONNECTING

12:12:06.905 -- EVENT: RESOLVE

12:12:06.908 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:06.909 -- EVENT: WAIT

12:12:06.915 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:06.917 -- Client terminated, restarting in 2000 ms...

12:12:08.918 -- EVENT: RECONNECTING

12:12:08.929 -- EVENT: RESOLVE

12:12:08.934 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:08.936 -- EVENT: WAIT

12:12:08.942 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:08.943 -- Client terminated, restarting in 2000 ms...

12:12:10.934 -- EVENT: RECONNECTING

12:12:10.938 -- EVENT: RESOLVE

12:12:10.957 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:10.958 -- EVENT: WAIT

12:12:10.962 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:10.963 -- Client terminated, restarting in 2000 ms...

12:12:12.960 -- EVENT: RECONNECTING

12:12:12.964 -- EVENT: RESOLVE

12:12:12.970 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:12.971 -- EVENT: WAIT

12:12:12.974 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:12.975 -- Client terminated, restarting in 2000 ms...

12:12:14.965 -- EVENT: RECONNECTING

12:12:14.971 -- EVENT: RESOLVE

12:12:14.975 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:14.977 -- EVENT: WAIT

12:12:14.981 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:14.982 -- Client terminated, restarting in 2000 ms...

12:12:16.973 -- EVENT: RECONNECTING

12:12:16.982 -- EVENT: RESOLVE

12:12:16.988 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:16.990 -- EVENT: WAIT

12:12:16.995 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:16.997 -- Client terminated, restarting in 2000 ms...

12:12:18.982 -- EVENT: RECONNECTING

12:12:18.995 -- EVENT: RESOLVE

12:12:19.002 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:19.003 -- EVENT: WAIT

12:12:19.007 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:19.008 -- Client terminated, restarting in 2000 ms...

12:12:20.992 -- EVENT: RECONNECTING

12:12:20.997 -- EVENT: RESOLVE

12:12:21.000 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:21.001 -- EVENT: WAIT

12:12:21.005 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:21.006 -- Client terminated, restarting in 2000 ms...

12:12:23.000 -- EVENT: RECONNECTING

12:12:23.005 -- EVENT: RESOLVE

12:12:23.009 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:23.010 -- EVENT: WAIT

12:12:23.014 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:23.015 -- Client terminated, restarting in 2000 ms...

12:12:25.008 -- EVENT: RECONNECTING

12:12:25.012 -- EVENT: RESOLVE

12:12:25.018 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:25.020 -- EVENT: WAIT

12:12:25.026 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:25.028 -- Client terminated, restarting in 2000 ms...

12:12:27.016 -- EVENT: RECONNECTING

12:12:27.023 -- EVENT: RESOLVE

12:12:27.030 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:27.031 -- EVENT: WAIT

12:12:27.035 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:27.036 -- Client terminated, restarting in 2000 ms...

12:12:29.026 -- EVENT: RECONNECTING

12:12:29.033 -- EVENT: RESOLVE

12:12:29.036 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:29.037 -- EVENT: WAIT

12:12:29.040 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:29.041 -- Client terminated, restarting in 2000 ms...

12:12:31.036 -- EVENT: RECONNECTING

12:12:31.039 -- EVENT: RESOLVE

12:12:31.042 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:31.043 -- EVENT: WAIT

12:12:31.047 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:31.048 -- Client terminated, restarting in 2000 ms...

12:12:33.043 -- EVENT: RECONNECTING

12:12:33.047 -- EVENT: RESOLVE

12:12:33.051 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:33.054 -- EVENT: WAIT

12:12:33.056 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:33.058 -- Client terminated, restarting in 2000 ms...

12:12:35.054 -- EVENT: RECONNECTING

12:12:35.060 -- EVENT: RESOLVE

12:12:35.064 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:35.065 -- EVENT: WAIT

12:12:35.069 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:35.070 -- Client terminated, restarting in 2000 ms...

12:12:37.064 -- EVENT: RECONNECTING

12:12:37.068 -- EVENT: RESOLVE

12:12:37.071 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:37.073 -- EVENT: WAIT

12:12:37.077 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:37.078 -- Client terminated, restarting in 2000 ms...

12:12:39.073 -- EVENT: RECONNECTING

12:12:39.077 -- EVENT: RESOLVE

12:12:39.081 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:39.083 -- EVENT: WAIT

12:12:39.087 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:39.088 -- Client terminated, restarting in 2000 ms...

12:12:41.081 -- EVENT: RECONNECTING

12:12:41.085 -- EVENT: RESOLVE

12:12:41.088 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:41.089 -- EVENT: WAIT

12:12:41.098 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:41.100 -- Client terminated, restarting in 2000 ms...

12:12:43.097 -- EVENT: RECONNECTING

12:12:43.104 -- EVENT: RESOLVE

12:12:43.110 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:43.114 -- EVENT: WAIT

12:12:43.119 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:43.121 -- Client terminated, restarting in 2000 ms...

12:12:45.111 -- EVENT: RECONNECTING

12:12:45.115 -- EVENT: RESOLVE

12:12:45.119 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:45.120 -- EVENT: WAIT

12:12:45.124 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:45.126 -- Client terminated, restarting in 2000 ms...

12:12:47.118 -- EVENT: RECONNECTING

12:12:47.123 -- EVENT: RESOLVE

12:12:47.128 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:47.130 -- EVENT: WAIT

12:12:47.134 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:47.135 -- Client terminated, restarting in 2000 ms...

12:12:49.126 -- EVENT: RECONNECTING

12:12:49.134 -- EVENT: RESOLVE

12:12:49.142 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:49.144 -- EVENT: WAIT

12:12:49.151 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:49.154 -- Client terminated, restarting in 2000 ms...

12:12:51.144 -- EVENT: RECONNECTING

12:12:51.154 -- EVENT: RESOLVE

12:12:51.161 -- Contacting [fe80::211:32ff:fec5:2e1f]:XXXXX via UDP

12:12:51.163 -- EVENT: WAIT

12:12:51.168 -- Transport Error: UDP connect error on 'fe80::211:32ff:fec5:2e1f:XXXXX' ([fe80::211:32ff:fec5:2e1f]:XXXXX): Invalid argument

12:12:51.169 -- Client terminated, restarting in 2000 ms...

12:12:52.819 -- EVENT: CONNECTION_TIMEOUT

12:12:52.835 -- EVENT: DISCONNECTED

12:12:52.836 -- Tunnel bytes per CPU second: 0

12:12:52.837 -- ----- OpenVPN Stop -----
 

Anhänge

  • Bildschirmfoto vom 2022-06-30 12-12-50.png
    Bildschirmfoto vom 2022-06-30 12-12-50.png
    24,5 KB · Aufrufe: 7

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.308
Punkte für Reaktionen
2.867
Punkte
423
fe80::-Adressen sind Link-Local-Adressen. Die gehen eh nur intern. Öffentliche beginnen i.d.R mit 2001:...
Jetzt wirf halt mal deine Portfreigaben weg und setze sie neu, da muss ...::2e1f stehen.
 

dtrunk90

Benutzer
Mitglied seit
09. Mai 2020
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
Ja, habe manuell 2e1f angegeben. Nun steht auch extern bei nmap -sU -p U:XXXXX -6 XXXXXX.synology.me für die IPv6 open|filtered. Die Portfreigabe scheint also nun schonmal zu klappen.

EDIT: Die VPN-Verbindung klappt aber weiterhin nicht. Auch intern nicht.

Die Fehlermeldung ist nun aber eine andere. Client Log:
Code:
12:45:33.708 -- ----- OpenVPN Start -----

12:45:33.710 -- EVENT: CORE_THREAD_ACTIVE

12:45:33.715 -- OpenVPN core 3.git::d3f8b18b:Release android arm64 64-bit PT_PROXY

12:45:33.716 -- Frame=512/2048/512 mssfix-ctrl=1250

12:45:33.722 -- UNUSED OPTIONS
1 [tls-client]
3 [pull]
5 [script-security] [2]

12:45:33.724 -- EVENT: RESOLVE

12:45:33.779 -- Contacting XX.XXX.XX.XXX:XXXXX via UDP

12:45:33.781 -- EVENT: WAIT

12:45:33.788 -- Connecting to [XXXXXXX.synology.me]:XXXXX (XX.XXX.XX.XXX) via UDPv4

12:45:43.724 -- Server poll timeout, trying next remote entry...

12:45:43.726 -- EVENT: RECONNECTING

12:45:43.730 -- EVENT: RESOLVE

12:45:43.737 -- Contacting XX.XXX.XX.XXX:XXXXX via UDP

12:45:43.738 -- EVENT: WAIT

12:45:43.742 -- Connecting to [XXXXXXX.synology.me]:XXXXX (XX.XXX.XX.XXX) via UDPv4

12:45:53.729 -- Server poll timeout, trying next remote entry...

12:45:53.731 -- EVENT: RECONNECTING

12:45:53.735 -- EVENT: RESOLVE

12:45:53.749 -- Contacting XX.XXX.XX.XXX:XXXXX via UDP

12:45:53.751 -- EVENT: WAIT

12:45:53.755 -- Connecting to [XXXXXXX.synology.me]:XXXXX (XX.XXX.XX.XXX) via UDPv4

12:46:03.735 -- Server poll timeout, trying next remote entry...

12:46:03.737 -- EVENT: RECONNECTING

12:46:03.744 -- EVENT: RESOLVE

12:46:03.748 -- Contacting [XXXX:XXX:XXXX:XXXX:211:32ff:fec5:2e1f]:XXXXX via UDP

12:46:03.749 -- EVENT: WAIT

12:46:03.752 -- Connecting to [XXXXXXX.synology.me]:XXXXX (XXXX:XXX:XXXX:XXXX:211:32ff:fec5:2e1f) via UDPv6

12:46:03.831 -- EVENT: CONNECTING

12:46:03.839 -- Tunnel Options:V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-client

12:46:03.842 -- Creds: Username/Password

12:46:03.845 -- Peer Info:
IV_VER=3.git::d3f8b18b:Release
IV_PLAT=android
IV_NCP=2
IV_TCPNL=1
IV_PROTO=30
IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
IV_LZO_STUB=1
IV_COMP_STUB=1
IV_COMP_STUBv2=1
IV_GUI_VER=net.openvpn.connect.android_3.2.7-7957
IV_SSO=webauth,openurl


12:46:03.898 -- VERIFY OK: depth=2, /C=US/O=Internet Security Research Group/CN=ISRG Root X1, signature: RSA-SHA256

12:46:03.902 -- VERIFY OK: depth=1, /C=US/O=Let's Encrypt/CN=R3, signature: RSA-SHA256

12:46:03.904 -- VERIFY OK: depth=0, /CN=XXXXXXX.synology.me, signature: RSA-SHA256

12:46:03.906 -- VERIFY FAIL -- verify-x509-name failed

12:46:03.907 -- Transport Error: OpenSSLContext::SSL::read_cleartext: BIO_read failed, cap=2576 status=-1: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

12:46:03.909 -- EVENT: CERT_VERIFY_FAIL info='OpenSSLContext::SSL::read_cleartext: BIO_read failed, cap=2576 status=-1: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed'

12:46:03.915 -- EVENT: DISCONNECTED

12:46:03.915 -- Tunnel bytes per CPU second: 0

12:46:03.916 -- ----- OpenVPN Stop -----

Das Zertifikat ist aber gültig:
Bildschirmfoto vom 2022-06-30 12-50-02.png

Oder ist hier mein Zertifikat in Android gemeint? Bekomme nämlich vor dem Verbinden diese Meldung:
Screenshot_20220630-125149_Trebuchet.png

EDIT2: Mit deaktiviertem "CN des Servers überprüfen" klappt die VPN-Verbindung nun komplett (auch extern). Ich dachte die Option sei Sicherheitsrelevant, daher hatte ich sie aktiviert.
 
Zuletzt bearbeitet von einem Moderator:

dtrunk90

Benutzer
Mitglied seit
09. Mai 2020
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
Jetzt muss ich nur noch irgendwie herausfinden wie ich auf meine Samba- und/oder NFS-Shares zugreifen kann. Mit der 192.168.178.20 (LAN 1) IP komme ich nicht drauf. Ne Idee?

EDIT: Mit 10.8.0.1 hat es geklappt.
 
Zuletzt bearbeitet:

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.308
Punkte für Reaktionen
2.867
Punkte
423
Ich habe keine Ahnung, ob dein Tunnel nun auch IPv4 tunnelt.
Wenn \\192.168.18.20\Share nicht geht, probier's mal mit \\xxx.synology.me\Share oder mit \\2a02-8e50-ce3-daa0-d17d-b6f-b2c0-81c4.ipv6-literal.net\Share (also der IPv6-IP der DS mit - statt : und hinten .ipv6-literal.net dran). Letzteres ist die IPv6-Schreibweise für \\<IPv4>\Share

Edit: Ah, ok, hab dein Edit erst jetzt gesehen.
 
Zuletzt bearbeitet:


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat