Messages

Beim Server habe ich beim IPv6-Tunnel gar nichts angegeben (weil ich auch gar nicht wüsste, was ich da eintragen soll). Ist das eventuell der Fehler?

Bei den Tunnel Settings sieht es bei mir so aus:

IPv4 Tunnel Network: 10.0.8.0/24
IPv6 Tunnel Network. ##das Feld ist wie gesagt leer bei mir##

Und die Option "Disable IPv6" habe ich nicht aktiviert, denn laut Beschreibung würde da ja "Don't forward IPv6 traffic" passieren, was ich aber will (sämtlicher Traffic soll durch den VPN-Tunnel umgeleitet werden).

Die Option "Redirect Gateway" wiederum ist bei mir aktiviert, denn "Force all client generated traffic through the tunnel" möchte ich ja wie gesagt.

Also ich hatte zumindest nicht bewusst irgendwo IPv6 angegeben, zumindest nicht bei den OpenVPN-Server-Settings.

Beim LAN- und WAN-Interface habe ich jetzt mal umgestellt auf "None", da stand bei "IPv6 Configuration Type" die Option "Track Interface" (beim LAN-Interface) bzw. "DHCPv6" (beim WAN-Interface).

Jetzt stehen wie gesagt beide auf "None" bei der Option "IPv6 Configuration Type".

Aber eine OpenVPN-Verbindung bekomme ich trotzdem noch nicht hin.

Woher kommt denn die Option "tun-ipv6" beim Server?

Doch wahrscheinlich nur daher, dass man möchte, dass sämtlicher Netzwerk-Verkehr durch den VPN-Tunnel laufen soll?

Der Server läuft auf IPv6? Da kann ich leider nicht weiterhelfen ;-)

Und nun auch noch die Client-Config, die ich exportiert hatte für Viscosity:

dev tun
persist-tun
persist-key
cipher AES-256-CBC
auth SHA512
tls-client
client
resolv-retry infinite
remote ##hier#steht#meine#DynDNS-Adresse## 1194 udp
lport 0
auth-user-pass
remote-cert-tls server
comp-lzo adaptive
passtos

# dont terminate service process on wrong password, ask again
auth-retry interact
# open management channel
management 127.0.0.1 166
# wait for management to explicitly start connection
management-hold
# query management channel for user/pass
management-query-passwords
# disconnect VPN when management program connection is closed
management-signal
# forget password when management disconnects
management-forget-disconnect


<ca>
-----BEGIN CERTIFICATE-----
##hier#steht#ganz#viel##
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
##hier#steht#auch#ganz#viel##
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
##und#hier#auch#natürlich##
-----END PRIVATE KEY-----
</key>
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
##und#auch#hier#noch#etwas##
-----END OpenVPN Static key V1-----
</tls-auth>
key-direction 1

Habe jetzt auch noch mal geschaut, was eigentlich in /var/log/openvpn.log der OPNsense steht - da sehe ich von heute z.B. nur dies hier:

Nov 13 10:14:33 OPNsense openvpn[505]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
Nov 13 10:14:33 OPNsense openvpn[505]: MANAGEMENT: CMD 'status 2'
Nov 13 10:14:33 OPNsense openvpn[505]: MANAGEMENT: Client disconnected
Nov 13 16:33:25 OPNsense openvpn[505]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
Nov 13 16:33:25 OPNsense openvpn[505]: MANAGEMENT: CMD 'status 2'
Nov 13 16:33:25 OPNsense openvpn[505]: MANAGEMENT: Client disconnected

Hatte weiter oben erwähnt, dass ich mich an die Anleitung von Viscosity gehalten habe und das deshalb noch einmal mit UDP auf Port 1194 konfiguriert habe.

Dabei habe ich die Macher von Viscosity übrigens auch auf einen Zahlendreher bei den DNS-Server-Settings Ihrer Anleitung hingewiesen - das war tatsächlich falsch angegeben (nämlich 10.8.0.1 statt 10.0.8.1), ist nun aber korrigiert.

https://www.sparklabs.com/support/kb/article/setting-up-an-openvpn-server-with-opnsense-and-viscosity/

Da ich mir dachte, dass das ein Fehler sein muss, hatte ich es schon entsprechend angepasst bei meinen Settings.

Also: Ja, es soll eigentlich auf dem Standard-UDP-Port 1194 laufen, deshalb habe ich es noch einmal frisch so konfiguriert per Wizard und die Firewall-Regeln wurden ja laut fabian auch korrekt gesetzt.

Aber trotzdem funktioniert es nicht, ich verstehe auch überhaupt nicht, warum ...  :(

(richte OpenVPN ja auch nicht zum ersten mal ein)

So sieht die server1.conf in /var/etc/openvpn der OPNsense aus:

dev ovpns1
verb 3
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
auth SHA512
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local 100.93.0.154
tls-server
server 10.0.8.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/1
username-as-common-name
auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user 'Local Database' 'false' 'server1'" via-env
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'OpenVPN_UDP_1194_Server_certificate_MacOn' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
max-clients 5
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 10.0.8.1"
push "redirect-gateway def1"
client-to-client
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /usr/local/etc/dh-parameters.4096
tls-auth /var/etc/openvpn/server1.tls-auth 0
comp-lzo adaptive
passtos
persist-remote-ip
float
push "route 192.168.1.0 255.255.255.0"

Anbei auch noch mal ein Mitschnitt von em1 (also meiner WAN-Schnittstelle).

https://pastebin.com/raw/6ECJ3a72

Ich kann gern auch mal sämtliche anderen Geräte vom Netz nehmen damit mehr "Ruhe" ist im Netzwerk.

Am Rechner habe ich versucht, den Verbindungsversuch um 16:51 zu starten, nach knapp 45 Sekunden habe ich es dann abgebrochen.

Hilft das eventuell weiter? Ich sehe da leider auch keine einzige Zeile mit "vpn" und auch keine Anfrage von der externen IP 80.187.114.114 ...  :-[

Muss ich den TCPDUMP dann besser mit der Option -vvv laufen lassen, damit da noch detaillierter mitgeschnitten wird?

Danke für jedwede Hilfe!

So, jetzt habe ich noch mal einen TCPDUMP während des OpenVPN-Einwahlversuchs direkt auf der OPNsense laufen lassen.

Allerdings gibt es da gar keine Zeile mit VPN Infos? Und auch die IP des Hotspot (80.187.114.114) ist da gar nicht zu sehen?

https://pastebin.com/raw/BHXb5QtB

TCPDUMP hat automatisch auf em0 geschaut, was bei mir ja das LAN ist.

Vermutlich muss ich aber auf em1 (bei mir WAN) schauen lassen?

Die sind folgendermaßen (wurden beide per Wizard automatisch so erstellt):

WAN

Proto: IPv4 UDP
Source: *
Port: *
Destination: WAN address
Port: 1194 (OpenVPN)
Gateway: *
Schedule: da ist nichts eingetragen
Description: OpenVPN-UDP-1194-Mac-On wizard

OPENVPN

Proto: IPv4 *
Source: *
Port: *
Destination: *
Port: *
Gateway: *
Schedule: da ist nichts eingetragen
Description: OpenVPN-UDP-1194-Mac-On wizard

Das sollte doch eigentlich passen, oder?

Soll ich noch einmal TCPDUMP direkt auf der OPNsense machen beim VPN-Verbindungsversuch?

Kann ich da die Ergebnisse irgendwie sinnvoll eingrenzen? Denn schon nach wenigen Sekunden kommen da ja hundertausende von Zeilen zusammen?

Wäre ja genial wenn das weiterhilft, ich verstehe da nur Bahnhof.  ;)

Oder sollte ich den TCPDUMP auf der OPNsense machen statt auf dem Mac?

[21:25:08.755456 IP 172.20.10.3.57133 > cable-158-181-74-19.cust.telecolumbus.net.openvpn: UDP, length 86]

Anbei ein TCPDUMP während des Verbindungs-Versuchs von Viscosity am Mac (ein paar Zeilen mit vpn sind da dabei, fett markiert):

tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes

##gekürzt

21:25:06.583245 IP 172.20.10.3.57133 > cable-158-181-74-19.cust.telecolumbus.net.open: UDP, length 86
21:25:07.684315 IP 172.20.10.3.mdns > 224.0.0.251.mdns: 0 [1au] PTR (QM)? a.2.d.6.e.2.4.b.d.e.a.c.a.8.c.1.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (119)
21:25:07.684370 IP6 fe80::1c8a:caed:b42e:6d2a.mdns > ff02::fb.mdns: 0 [1au] PTR (QM)? a.2.d.6.e.2.4.b.d.e.a.c.a.8.c.1.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (119)
21:25:08.745530 IP 172.20.10.3.mdns > 224.0.0.251.mdns: 0 [1au] PTR (QU)? c.1.7.b.1.a.e.4.4.9.f.4.1.b.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (119)
21:25:08.745606 IP6 fe80::1c8a:caed:b42e:6d2a.mdns > ff02::fb.mdns: 0 [1au] PTR (QU)? c.1.7.b.1.a.e.4.4.9.f.4.1.b.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (119)
21:25:08.755456 IP 172.20.10.3.57133 > cable-158-181-74-19.cust.telecolumbus.net.openvpn: UDP, length 86
21:25:08.939732 IP 172.20.10.3.57901 > 172.20.10.1.osu-nms: UDP, length 4
21:25:09.021611 IP 172.20.10.1 > 172.20.10.3: ICMP 172.20.10.1 udp port osu-nms unreachable, length 36
21:25:09.445271 IP 172.20.10.3.57901 > 172.20.10.1.osu-nms: UDP, length 4
21:25:09.508227 IP 172.20.10.1 > 172.20.10.3: ICMP 172.20.10.1 udp port osu-nms unreachable, length 36
21:25:09.751363 IP 172.20.10.3.mdns > 224.0.0.251.mdns: 0 [1au] PTR (QM)? c.1.7.b.1.a.e.4.4.9.f.4.1.b.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (119)
21:25:09.751477 IP6 fe80::1c8a:caed:b42e:6d2a.mdns > ff02::fb.mdns: 0 [1au] PTR (QM)? c.1.7.b.1.a.e.4.4.9.f.4.1.b.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (119)
21:25:10.072238 IP outlook.saas.zone.https > 172.20.10.3.60732: Flags [P.], seq 3094060074:3094061215, ack 1434040954, win 411, length 1141
21:25:10.072316 IP 172.20.10.3.60732 > outlook.saas.zone.https: Flags [.], ack 1141, win 8156, length 0
21:25:12.014849 IP 172.20.10.3.57133 > cable-158-181-74-19.cust.telecolumbus.net.openvpn: UDP, length 86
21:25:12.760405 IP 172.20.10.3.mdns > 224.0.0.251.mdns: 0 [1au] PTR (QM)? c.1.7.b.1.a.e.4.4.9.f.4.1.b.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (119)
21:25:12.760513 IP6 fe80::1c8a:caed:b42e:6d2a.mdns > ff02::fb.mdns: 0 [1au] PTR (QM)? c.1.7.b.1.a.e.4.4.9.f.4.1.b.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (119)
21:25:13.635585 IP6 fe80::1c8a:caed:b42e:6d2a.53266 > fe80::10b1:4f94:4ea1:b71c.domain: 52831+ PTR? 251.0.0.224.in-addr.arpa. (42)
21:25:14.291983 IP 172.20.10.3.60736 > 17.248.146.110.https: Flags [P.], seq 1856868942:1856868973, ack 3956518183, win 4096, options [nop,nop,TS val 299530404 ecr 794734760], length 31
21:25:14.292213 IP 172.20.10.3.60735 > 17.248.146.110.https: Flags [P.], seq 2873708679:2873708710, ack 660784590, win 4096, options [nop,nop,TS val 299530404 ecr 794734683], length 31
21:25:14.292922 IP 172.20.10.3.60736 > 17.248.146.110.https: Flags [F.], seq 31, ack 1, win 4096, options [nop,nop,TS val 299530404 ecr 794734760], length 0
21:25:14.292954 IP 172.20.10.3.60735 > 17.248.146.110.https: Flags [F.], seq 31, ack 1, win 4096, options [nop,nop,TS val 299530404 ecr 794734683], length 0
21:25:14.357956 IP 17.248.146.110.https > 172.20.10.3.60736: Flags [.], ack 0, win 972, options [nop,nop,TS val 794783433 ecr 299481950], length 0
21:25:14.357961 IP 17.248.146.110.https > 172.20.10.3.60736: Flags [.], ack 32, win 972, options [nop,nop,TS val 794783433 ecr 299530404], length 0
21:25:14.357963 IP 17.248.146.110.https > 172.20.10.3.60735: Flags [.], ack 0, win 972, options [nop,nop,TS val 794783433 ecr 299481875], length 0
21:25:14.358002 IP 172.20.10.3.60736 > 17.248.146.110.https: Flags [FP.], seq 0:31, ack 1, win 4096, options [nop,nop,TS val 299530470 ecr 794783433], length 31
21:25:14.358028 IP 172.20.10.3.60735 > 17.248.146.110.https: Flags [FP.], seq 0:31, ack 1, win 4096, options [nop,nop,TS val 299530470 ecr 794783433], length 31
21:25:14.363961 IP 17.248.146.110.https > 172.20.10.3.60735: Flags [.], ack 32, win 972, options [nop,nop,TS val 794783433 ecr 299530404], length 0
21:25:14.363965 IP 17.248.146.110.https > 172.20.10.3.60735: Flags [F.], seq 1, ack 32, win 972, options [nop,nop,TS val 794783433 ecr 299530404], length 0
21:25:14.364037 IP 172.20.10.3.60735 > 17.248.146.110.https: Flags [.], ack 2, win 4096, options [nop,nop,TS val 299530475 ecr 794783433], length 0
21:25:14.364147 IP 17.248.146.110.https > 172.20.10.3.60736: Flags [F.], seq 1, ack 32, win 972, options [nop,nop,TS val 794783436 ecr 299530404], length 0
21:25:14.364186 IP 172.20.10.3.60736 > 17.248.146.110.https: Flags [.], ack 2, win 4096, options [nop,nop,TS val 299530475 ecr 794783436], length 0
21:25:14.397893 IP 17.248.146.110.https > 172.20.10.3.60736: Flags [.], ack 32, win 972, options [nop,nop,TS val 794783472 ecr 299530470], length 0
21:25:14.397898 IP 17.248.146.110.https > 172.20.10.3.60735: Flags [.], ack 32, win 972, options [nop,nop,TS val 794783472 ecr 299530470], length 0
21:25:14.615089 IP 172.20.10.3.60741 > a23-199-216-229.deploy.static.akamaitechnologies.com.https: Flags [P.], seq 3562390668:3562390699, ack 4188215041, win 4096, options [nop,nop,TS val 299530724 ecr 1556023635], length 31
21:25:14.615402 IP 172.20.10.3.60741 > a23-199-216-229.deploy.static.akamaitechnologies.com.https: Flags [F.], seq 31, ack 1, win 4096, options [nop,nop,TS val 299530724 ecr 1556023635], length 0
21:25:14.639014 IP6 fe80::1c8a:caed:b42e:6d2a.53266 > fe80::10b1:4f94:4ea1:b71c.domain: 52831+ PTR? 251.0.0.224.in-addr.arpa. (42)
21:25:14.675745 IP a23-199-216-229.deploy.static.akamaitechnologies.com.https > 172.20.10.3.60741: Flags [.], ack 0, win 972, options [nop,nop,TS val 1556072223 ecr 299482327,nop,nop,sack 1 {31:32}], length 0
21:25:14.675787 IP 172.20.10.3.60741 > a23-199-216-229.deploy.static.akamaitechnologies.com.https: Flags [FP.], seq 0:31, ack 1, win 4096, options [nop,nop,TS val 299530784 ecr 1556072223], length 31
21:25:14.682886 IP a23-199-216-229.deploy.static.akamaitechnologies.com.https > 172.20.10.3.60741: Flags [.], ack 32, win 972, options [nop,nop,TS val 1556072231 ecr 299530724], length 0
21:25:14.682890 IP a23-199-216-229.deploy.static.akamaitechnologies.com.https > 172.20.10.3.60741: Flags [P.], seq 1:32, ack 32, win 972, options [nop,nop,TS val 1556072231 ecr 299530724], length 31
21:25:14.682965 IP 172.20.10.3.60741 > a23-199-216-229.deploy.static.akamaitechnologies.com.https: Flags [R], seq 3562390700, win 0, length 0
21:25:14.687786 IP a23-199-216-229.deploy.static.akamaitechnologies.com.https > 172.20.10.3.60741: Flags [R.], seq 32, ack 32, win 972, options [nop,nop,TS val 1556072231 ecr 299530724], length 0
21:25:14.723678 IP a23-199-216-229.deploy.static.akamaitechnologies.com.https > 172.20.10.3.60741: Flags [R], seq 4188215041, win 0, length 0
21:25:15.291897 IP 172.20.10.3.60740 > a23-199-216-229.deploy.static.akamaitechnologies.com.https: Flags [P.], seq 4041680001:4041680032, ack 4163042878, win 4096, options [nop,nop,TS val 299531396 ecr 1556023628], length 31
21:25:15.292165 IP 172.20.10.3.60740 > a23-199-216-229.deploy.static.akamaitechnologies.com.https: Flags [F.], seq 31, ack 1, win 4096, options [nop,nop,TS val 299531396 ecr 1556023628], length 0
21:25:15.342894 IP a23-199-216-229.deploy.static.akamaitechnologies.com.https > 172.20.10.3.60740: Flags [.], ack 0, win 972, options [nop,nop,TS val 1556072893 ecr 299482322,nop,nop,sack 1 {31:32}], length 0
21:25:15.342897 IP a23-199-216-229.deploy.static.akamaitechnologies.com.https > 172.20.10.3.60740: Flags [.], ack 32, win 972, options [nop,nop,TS val 1556072893 ecr 299531396], length 0
21:25:15.342931 IP 172.20.10.3.60740 > a23-199-216-229.deploy.static.akamaitechnologies.com.https: Flags [FP.], seq 0:31, ack 1, win 4096, options [nop,nop,TS val 299531446 ecr 1556072893], length 31
21:25:15.348929 IP a23-199-216-229.deploy.static.akamaitechnologies.com.https > 172.20.10.3.60740: Flags [P.], seq 1:32, ack 32, win 972, options [nop,nop,TS val 1556072893 ecr 299531396], length 31
21:25:15.348933 IP a23-199-216-229.deploy.static.akamaitechnologies.com.https > 172.20.10.3.60740: Flags [R.], seq 32, ack 32, win 972, options [nop,nop,TS val 1556072893 ecr 299531396], length 0
21:25:15.348994 IP 172.20.10.3.60740 > a23-199-216-229.deploy.static.akamaitechnologies.com.https: Flags [R], seq 4041680033, win 0, length 0
21:25:15.392863 IP a23-199-216-229.deploy.static.akamaitechnologies.com.https > 172.20.10.3.60740: Flags [R], seq 4163042878, win 0, length 0
21:25:16.643717 IP 172.20.10.3.53266 > 172.20.10.1.domain: 52831+ PTR? 251.0.0.224.in-addr.arpa. (42)
21:25:17.445030 IP6 fe80::10b1:4f94:4ea1:b71c.domain > fe80::1c8a:caed:b42e:6d2a.53266: 52831 NXDomain* 0/1/0 (99)
21:25:17.445662 IP 172.20.10.1.domain > 172.20.10.3.53266: 52831 NXDomain* 0/1/0 (99)
21:25:17.448528 IP6 fe80::1c8a:caed:b42e:6d2a.60112 > fe80::10b1:4f94:4ea1:b71c.domain: 42756+ PTR? b.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.f.f.ip6.arpa. (90)
21:25:18.451944 IP6 fe80::1c8a:caed:b42e:6d2a.60112 > fe80::10b1:4f94:4ea1:b71c.domain: 42756+ PTR? b.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.f.f.ip6.arpa. (90)
21:25:19.693974 IP6 fe80::1c8a:caed:b42e:6d2a > fe80::10b1:4f94:4ea1:b71c: ICMP6, neighbor solicitation, who has fe80::10b1:4f94:4ea1:b71c, length 32
21:25:19.698813 IP6 fe80::10b1:4f94:4ea1:b71c > fe80::1c8a:caed:b42e:6d2a: ICMP6, neighbor advertisement, tgt is fe80::10b1:4f94:4ea1:b71c, length 24
21:25:20.452144 IP 172.20.10.3.60112 > 172.20.10.1.domain: 42756+ PTR? b.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.f.f.ip6.arpa. (90)
21:25:21.115650 IP 172.20.10.3.57133 > cable-158-181-74-19.cust.telecolumbus.net.openvpn: UDP, length 86
21:25:21.117737 IP6 fe80::10b1:4f94:4ea1:b71c.domain > fe80::1c8a:caed:b42e:6d2a.60112: 42756 NXDomain* 0/1/0 (154)
21:25:21.118345 IP 172.20.10.1.domain > 172.20.10.3.60112: 42756 NXDomain* 0/1/0 (154)
21:25:21.121250 IP6 fe80::1c8a:caed:b42e:6d2a.52356 > fe80::10b1:4f94:4ea1:b71c.domain: 46253+ PTR? 9.6.d.1.e.6.9.7.c.5.3.6.9.b.4.3.e.7.b.f.6.8.1.8.8.9.5.0.1.0.a.2.ip6.arpa. (90)
21:25:21.747071 IP6 fe80::10b1:4f94:4ea1:b71c > fe80::1c8a:caed:b42e:6d2a: ICMP6, neighbor solicitation, who has fe80::1c8a:caed:b42e:6d2a, length 32
21:25:21.747112 IP6 fe80::1c8a:caed:b42e:6d2a > fe80::10b1:4f94:4ea1:b71c: ICMP6, neighbor advertisement, tgt is fe80::1c8a:caed:b42e:6d2a, length 24
21:25:22.122054 IP6 fe80::1c8a:caed:b42e:6d2a.52356 > fe80::10b1:4f94:4ea1:b71c.domain: 46253+ PTR? 9.6.d.1.e.6.9.7.c.5.3.6.9.b.4.3.e.7.b.f.6.8.1.8.8.9.5.0.1.0.a.2.ip6.arpa. (90)
21:25:24.125303 IP 172.20.10.3.52356 > 172.20.10.1.domain: 46253+ PTR? 9.6.d.1.e.6.9.7.c.5.3.6.9.b.4.3.e.7.b.f.6.8.1.8.8.9.5.0.1.0.a.2.ip6.arpa. (90)
21:25:24.827698 IP6 fe80::10b1:4f94:4ea1:b71c.domain > fe80::1c8a:caed:b42e:6d2a.52356: 46253 NXDomain* 0/1/0 (150)
21:25:24.828652 IP 172.20.10.1.domain > 172.20.10.3.52356: 46253 NXDomain* 0/1/0 (150)
21:25:24.831702 IP6 fe80::1c8a:caed:b42e:6d2a.49290 > fe80::10b1:4f94:4ea1:b71c.domain: 29005+ PTR? 1.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.6.0.8.0.1.0.0.4.0.5.4.1.0.0.a.2.ip6.arpa. (90)
21:25:25.340884 IP 172.20.10.3.60734 > outlook.saas.zone.https: Flags [P.], seq 2495036850:2495036935, ack 1677516140, win 8192, length 85
21:25:25.341222 IP 172.20.10.3.60734 > outlook.saas.zone.https: Flags [F.], seq 85, ack 1, win 8192, length 0
21:25:25.402061 IP outlook.saas.zone.https > 172.20.10.3.60734: Flags [.], ack 0, win 586, length 0
21:25:25.402065 IP outlook.saas.zone.https > 172.20.10.3.60734: Flags [.], ack 86, win 586, length 0
21:25:25.402099 IP 172.20.10.3.60734 > outlook.saas.zone.https: Flags [FP.], seq 0:85, ack 1, win 8192, length 85
21:25:25.402372 IP outlook.saas.zone.https > 172.20.10.3.60734: Flags [F.], seq 1, ack 86, win 586, length 0
21:25:25.402418 IP 172.20.10.3.60734 > outlook.saas.zone.https: Flags [.], ack 2, win 8192, length 0
21:25:25.836000 IP6 fe80::1c8a:caed:b42e:6d2a.49290 > fe80::10b1:4f94:4ea1:b71c.domain: 29005+ PTR? 1.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.6.0.8.0.1.0.0.4.0.5.4.1.0.0.a.2.ip6.arpa. (90)
21:25:27.841078 IP 172.20.10.3.49290 > 172.20.10.1.domain: 29005+ PTR? 1.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.6.0.8.0.1.0.0.4.0.5.4.1.0.0.a.2.ip6.arpa. (90)
21:25:28.504085 IP6 fe80::10b1:4f94:4ea1:b71c.domain > fe80::1c8a:caed:b42e:6d2a.49290: 29005 1/0/0 PTR fra15s29-in-x01.1e100.net. (129)
21:25:28.504844 IP 172.20.10.1.domain > 172.20.10.3.49290: 29005 1/0/0 PTR fra15s29-in-x01.1e100.net. (129)
21:25:28.506263 IP6 fe80::1c8a:caed:b42e:6d2a.54937 > fe80::10b1:4f94:4ea1:b71c.domain: 62374+ PTR? 9.6.d.1.e.6.f.f.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.f.f.ip6.arpa. (90)
21:25:29.510785 IP6 fe80::1c8a:caed:b42e:6d2a.54937 > fe80::10b1:4f94:4ea1:b71c.domain: 62374+ PTR? 9.6.d.1.e.6.f.f.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.f.f.ip6.arpa. (90)
21:25:31.514608 IP 172.20.10.3.54937 > 172.20.10.1.domain: 62374+ PTR? 9.6.d.1.e.6.f.f.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.f.f.ip6.arpa. (90)
21:25:32.190453 IP6 fe80::10b1:4f94:4ea1:b71c.domain > fe80::1c8a:caed:b42e:6d2a.54937: 62374 NXDomain* 0/1/0 (154)
21:25:32.191241 IP 172.20.10.1.domain > 172.20.10.3.54937: 62374 NXDomain* 0/1/0 (154)
21:25:32.194359 IP6 fe80::1c8a:caed:b42e:6d2a.60203 > fe80::10b1:4f94:4ea1:b71c.domain: 45585+ PTR? 1.10.20.172.in-addr.arpa. (42)
21:25:33.195859 IP6 fe80::1c8a:caed:b42e:6d2a.60203 > fe80::10b1:4f94:4ea1:b71c.domain: 45585+ PTR? 1.10.20.172.in-addr.arpa. (42)
21:25:34.563322 IP6 fe80::1c8a:caed:b42e:6d2a > fe80::10b1:4f94:4ea1:b71c: ICMP6, neighbor solicitation, who has fe80::10b1:4f94:4ea1:b71c, length 32
21:25:34.574975 IP6 fe80::10b1:4f94:4ea1:b71c > fe80::1c8a:caed:b42e:6d2a: ICMP6, neighbor advertisement, tgt is fe80::10b1:4f94:4ea1:b71c, length 24
21:25:35.198918 IP 172.20.10.3.60203 > 172.20.10.1.domain: 45585+ PTR? 1.10.20.172.in-addr.arpa. (42)
21:25:35.880711 IP6 fe80::10b1:4f94:4ea1:b71c.domain > fe80::1c8a:caed:b42e:6d2a.60203: 45585 NXDomain* 0/1/0 (91)
21:25:35.880716 IP 172.20.10.1.domain > 172.20.10.3.60203: 45585 NXDomain* 0/1/0 (91)
21:25:35.884842 IP6 fe80::1c8a:caed:b42e:6d2a.49499 > fe80::10b1:4f94:4ea1:b71c.domain: 60806+ PTR? 19.74.181.158.in-addr.arpa. (44)
21:25:36.890164 IP6 fe80::1c8a:caed:b42e:6d2a.49499 > fe80::10b1:4f94:4ea1:b71c.domain: 60806+ PTR? 19.74.181.158.in-addr.arpa. (44)
21:25:37.415929 IP6 fe80::10b1:4f94:4ea1:b71c > fe80::1c8a:caed:b42e:6d2a: ICMP6, neighbor solicitation, who has fe80::1c8a:caed:b42e:6d2a, length 32
21:25:37.415969 IP6 fe80::1c8a:caed:b42e:6d2a > fe80::10b1:4f94:4ea1:b71c: ICMP6, neighbor advertisement, tgt is fe80::1c8a:caed:b42e:6d2a, length 24
21:25:37.505190 IP 172.20.10.3.57133 > cable-158-181-74-19.cust.telecolumbus.net.openvpn: UDP, length 86
21:25:38.893797 IP 172.20.10.3.49499 > 172.20.10.1.domain: 60806+ PTR? 19.74.181.158.in-addr.arpa. (44)

## gekürzt

234 packets captured
234 packets received by filter
0 packets dropped by kernel

Ja, das klang jetzt vielleicht etwas hart, war aber nicht so gemeint. Ich bin grundsätzlich sehr begeistert von OPNsense und empfehle das seit Monaten auch immer wieder gern Freunden und Kollegen.

Und auch OpenVPN hatte ich ja unter der 17.1 schon am laufen, das war überhaupt kein Problem. Nur jetzt mit der aktuellen 17.7.7 bekomme ich es irgendwie einfach nicht hin.

Was die Fragen betrifft:

OS: macOS 10.13.1 High Sierra
Browser: Firefox 57.0 (64-Bit) Mac
VPN-Client: Viscosity 1.7.5 Mac
OPNsense: 17.7.7_1-amd64 / FreeBSD 11.0-RELEASE-p12 / LibreSSL 2.5.5 / openvpn 2.4.4

Hatte OPNsense erst vor einigen Tagen noch einmal komplett neu installiert (denn ein Upgrade auf die 17.7 Anfang August hatte scheinbar mein Dateisystem zerschossen).

Frage: Könnte es einen Unterschied machen, wenn ich die verschiedenen Dienste mal in einer anderen Reihenfolge einrichte?

Meine Idee wäre, OPNsense noch einmal komplett zu resetten, und dann WAN- und LAN-Interface zu definieren und den DHCP-Server sowie DynDNS und dann gleich als erstes die interne CA und dann den OpenVPN-Server aufzusetzen.

In der Hoffnung, dass das spätere einrichten weiterer Dienste (siehe Eingangspost, also insbesondere OpenDNS malware + botnet + phishing protection, Unbound DNS als Werbe- & Tracking-Blocker und das Inline Intrusion Prevention per Suricata & Netmap (abuse.ch) weniger Probleme bereitet?

Frage mich nur, ob das etwas bringt, denn ich hatte ja auch schon OpenDNS, Unbound DNS und auch Suricata deaktiviert und trotzdem keine Verbindung hinbekommen ...

Danke für weitere Tipps und Empfehlungen.

So, habe jetzt noch mal meinen VPN-User, dessen Zertifikat, die Firewall-Regeln und den OpenVPN-Server gelöscht und bin dann Schritt für Schritt nach dieser Anleitung vorgegangen:

https://www.sparklabs.com/support/kb/article/setting-up-an-openvpn-server-with-opnsense-and-viscosity/#

Selbes Ergebnis: Es kommt keine Verbindung zustande.

Ich bin echt ratlos ...  :(

PS: Was mir allerdings aufgefallen ist - OPNsense bzw. die WebGUI scheint nicht sauber alle Preferences zu löschen - vieles war auch beim neu einrichten schon wieder so vorgegeben wie vorher und sogar zuvor gelöschte Firewall-Regeln erschienen wie von Geisterhand noch einmal?

Das wirft aus meiner Sicht kein gutes Licht auf "die Technik dahinter" ... ich meine, wenn ich settings oder services lösche, möchte ich nicht, dass die noch irgendwo als Datei-Leichen im System kleben und dann plötzlich doch wieder reingrätschen ...  :-X

Den OpenVPN-Server hatte ich vorher auch noch einmal neu gestartet und danach das log-File noch einmal geleert (da war dann trotz Verbindungsversuch wie gesagt nichts eingegangen).

Der Start des OpenVPN-Servers hatte folgendes ins log geschrieben:

OpenVPN-Server neu gestartet:

Nov 10 15:17:51    openvpn[36764]: Initialization Sequence Completed
Nov 10 15:17:51    openvpn[36764]: TCPv4_SERVER link remote: [AF_UNSPEC]
Nov 10 15:17:51    openvpn[36764]: TCPv4_SERVER link local (bound): [AF_INET]100.93.0.154:443
Nov 10 15:17:51    openvpn[36764]: Listening for incoming TCP connection on [AF_INET]100.93.0.154:443
Nov 10 15:17:51    openvpn[36764]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Nov 10 15:17:50    openvpn[36764]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1624 10.0.8.1 255.255.255.0 init
Nov 10 15:17:50    openvpn[36764]: /sbin/ifconfig ovpns1 10.0.8.1 10.0.8.2 mtu 1500 netmask 255.255.255.0 up
Nov 10 15:17:50    openvpn[36764]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Nov 10 15:17:50    openvpn[36764]: TUN/TAP device /dev/tun1 opened
Nov 10 15:17:50    openvpn[36764]: TUN/TAP device ovpns1 exists previously, keep at program end
Nov 10 15:17:50    openvpn[36764]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Nov 10 15:17:50    openvpn[36534]: library versions: LibreSSL 2.5.5, LZO 2.10
Nov 10 15:17:50    openvpn[36534]: OpenVPN 2.4.4 amd64-portbld-freebsd11.0 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 25 2017
Nov 10 15:17:50    openvpn[86460]: SIGTERM[hard,] received, process exiting
Nov 10 15:17:50    openvpn[86460]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1624 10.0.8.1 255.255.255.0 init
Nov 10 15:17:38    openvpn[86460]: Initialization Sequence Completed
Nov 10 15:17:38    openvpn[86460]: TCPv4_SERVER link remote: [AF_UNSPEC]
Nov 10 15:17:38    openvpn[86460]: TCPv4_SERVER link local (bound): [AF_INET]100.93.0.154:443
Nov 10 15:17:38    openvpn[86460]: Listening for incoming TCP connection on [AF_INET]100.93.0.154:443
Nov 10 15:17:38    openvpn[86460]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Nov 10 15:17:38    openvpn[86460]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1624 10.0.8.1 255.255.255.0 init
Nov 10 15:17:38    openvpn[86460]: /sbin/ifconfig ovpns1 10.0.8.1 10.0.8.2 mtu 1500 netmask 255.255.255.0 up
Nov 10 15:17:38    openvpn[86460]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Nov 10 15:17:38    openvpn[86460]: TUN/TAP device /dev/tun1 opened
Nov 10 15:17:38    openvpn[86460]: TUN/TAP device ovpns1 exists previously, keep at program end
Nov 10 15:17:38    openvpn[86460]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Nov 10 15:17:38    openvpn[86163]: library versions: LibreSSL 2.5.5, LZO 2.10
Nov 10 15:17:38    openvpn[86163]: OpenVPN 2.4.4 amd64-portbld-freebsd11.0 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Oct 25 2017
Nov 10 15:17:38    openvpn[69468]: SIGTERM[hard,] received, process exiting
Nov 10 15:17:37    openvpn[69468]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1624 10.0.8.1 255.255.255.0 init

Und im OpenVPN log file ist leider gar nichts zu sehen ...   :-\

File /var/log/openvpn.log yielded no results.

PS: Suricata hatte ich deaktiviert, den WebGUI-Port auf 34343 geändert.

so, hier nur ein kurzer Post um zu zeigen, dass ich wirklich mir einer anderen IP online bin (DynDNS-Host wird mit IP 158.181.74.19 korrekt aufgelöst)