Hallo,
hatte das alles schon mal am laufen vor einigen Monaten - aber nachdem ein Upgrade auf die aktuelle Version 17.7 das Filesystem Anfang August zerschossen hatte, musste ich nun alles noch einmal neu aufsetzen.
Was bisher läuft:
- DHCP-Server: 192.168.1.151-199
- DynDNS: bei NO-IP.org
- Network Time Daemon: de.pool.ntp.org
- OpenDNS: malware + botnet + phishing protection
- SSH Login: immer nur an wenn benötigt
- Unbound DNS: /var/unbound/ad-blacklist.conf
- Inline Intrusion Prevention: Suricata & Netmap (abuse.ch)
- Trust Authorities & Certificates: internal_CA
Aber OpenVPN will irgendwie nicht klappen, egal ob Standard UDP Port 1194 oder auch TCP Port 443.
Habe das alles extra per Wizard eingerichtet, da dann auch gleich die nötigen Firewall-Regeln mit erstellt werden, aber Viscosity bekommt einfach keine Verbindung hin und ich weiß nicht so recht, wie ich das Problem jetzt am besten eingrenzen kann.
Das genau setup kann ich gern nachreichen wenn das hilfreich ist, aber sicher wollt ihr eher irgend welche log-files sehen um das Problem analysieren zu können?
Viscosity zeigt mir z.B. nur das hier an:
2017-11-09 23:03:04: Viscosity Mac 1.7.5 (1420)
2017-11-09 23:03:04: Viscosity OpenVPN Engine Started
2017-11-09 23:03:04: Running on macOS 10.13.1
2017-11-09 23:03:04: ---------
2017-11-09 23:03:04: State changed to verbinde
2017-11-09 23:03:04: Checking reachability status of connection...
2017-11-09 23:03:04: Connection is reachable. Starting connection attempt.
2017-11-09 23:03:04: OpenVPN 2.4.4 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Sep 27 2017
2017-11-09 23:03:04: library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.10
2017-11-09 23:03:04: TCP/UDP: Preserving recently used remote address: [AF_INET]158.181.74.19:443
2017-11-09 23:03:04: Attempting to establish TCP connection with [AF_INET]158.181.74.19:443 [nonblock]
Aber es kommt einfach keine Verbindung zu stande - aber eben auch keine Fehlermeldung.
2017-11-09 23:03:41: State changed to Disconnecting
2017-11-09 23:03:41: SIGTERM[hard,init_instance] received, process exiting
2017-11-09 23:03:41: State changed to getrennt
Vermutlich ist es also ein Problem der Firewall meines OPNsense Routers?
Und da wäre jetzt die Frage, welche Infos Ihr braucht, damit das Problem eingegrenzt werden kann?
Danke für Unterstützung!
PS: Andere OpenVPN-Verbindungen laufen ohne Probleme mit Viscosity, es muss also ein Problem mit den settings im OPNsense Router sein (aktuelle Version 17.7.7).
* Testest du die Verbindung auch von extern?
* ist die WAN Adresse korrekt (158...) bzw. nutzt du zur Verbindung die no-ip Domain und ist diese korrekt und aktuell in der Auflösung?
* hast du dein WAN Interface kontrolliert bezüglich der Regeln, dass diese auch angelegt wurden (in dem Fall 443 tcp)?
* Ist deine OPNsense GUI auf einen anderen Port konfiguriert? Ansonsten könnte es Probleme geben mit WebUI auf Port 443 vs OpenVPN 443?
* Blockt ggf. dein Suricata die VPN Verbindungen?`
* Was sagt das OpenVPN Log auf der sense?
Gruß Jens
- ja, Verbindung wird "von extern" per Hotspot des iPhones getestet (das iPhone ist dabei nur per LTE online und das MacBook nur per WLan mit dem iPhone-Hotspot verbunden, per GeoLocation-Check sehe ich dann auch, dass das MacBook im Telekom-Netz statt TeleColumbus-Netz online ist)
- ja, DynDNS funktioniert (aktuelle IP-Adresse wird korrekt aufgelöst)
- was die Firewall-Regeln betrifft:
beim WAN-Interface ist als Firewall-Regel aktiv:
Proto: IPv4 TCP
Source: *
Port: *
Destination: WAN address
Port: 443 (HTTPS)
Gateway: *
Schedule: da ist nichts eingetragen
Description: OpenVPN-TCP-443 wizard
beim OPENVPN-Interface ist als Firewall-Regel aktiv:
Proto: IPv4 *
Source: *
Port: *
Destination: *
Port: *
Gateway: *
Schedule: da ist nichts eingetragen
Description: OpenVPN-TCP-443 wizard
(das sind die beiden Regeln, die automatisch per Wizard erstellt wurden)
- momentan läuft die WebGUI noch auf dem Standard-Port 443, aber das kann ich natürlich noch ändern (da es aber mit UDP Port 1194 auch nicht funktionierte, würde ich ja fast vermuten, dass das nicht das eigentliche Problem ist ...)
- bezüglich Suricata bin ich mir nicht sicher - damals unter 17.1 hatte ich trotz aktiviertem Suricata-Schutz keine Probleme (aber auch das kann ich ja erst einmal deaktivieren zum testen und Fehler eingrenzen)
- das OpenVPN log werde ich gleich noch einmal cleanen und dann posten, aber soweit ich mich erinnere hatte ich da gestern nur gesehen, dass der OpenVPN-Server überhaupt läuft ...
Quote from: JeGr on November 10, 2017, 11:07:28 AM
* Testest du die Verbindung auch von extern?
* ist die WAN Adresse korrekt (158...) bzw. nutzt du zur Verbindung die no-ip Domain und ist diese korrekt und aktuell in der Auflösung?
* hast du dein WAN Interface kontrolliert bezüglich der Regeln, dass diese auch angelegt wurden (in dem Fall 443 tcp)?
* Ist deine OPNsense GUI auf einen anderen Port konfiguriert? Ansonsten könnte es Probleme geben mit WebUI auf Port 443 vs OpenVPN 443?
* Blockt ggf. dein Suricata die VPN Verbindungen?`
* Was sagt das OpenVPN Log auf der sense?
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)
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.
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
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
Quote from: Marcel_75 on November 10, 2017, 08:05:57 PM
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?
Aus Erfahrung ist dies eher unwahrscheinlich, vor allem partiell. Das würde vielleicht eher für Browsereigenheiten sprechen, daher bitte sowohl die Info welches OS, Browsertyp und Version mit den Schritten zum Reproduzieren anhängen, dann sind Bugs meist schnell identifiziert und erledigt.
Quote from: Marcel_75 on November 10, 2017, 08:05:57 PM
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
Ja, wäre ungünstig. Auch nicht so elegant das aus nachvollziehbaren Frust zu vermuten und damit die Motivation weiter zu senken. Daher die Nachfrage nach Details... :)
Grüsse
Franco
Quote from: Marcel_75 on November 10, 2017, 08:05:57 PM
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?
Im System kann man den Unterschied der Konfiguration zu verschiedenen Zeitpunkten betrachten. Wenn du was löscht, sollten alle Zeilen da mit einem "-" vorangestellt auftauchen. Ansonsten wurde die Konfiguration nicht sauber geschrieben, was unwahrscheinlich währe (sonst würde es mehr Beschwerden geben).
Quote from: Marcel_75 on November 10, 2017, 08:05:57 PM
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
Bei der Deinstallation von Plugins bleibt die Konfiguration auf jedem Fall erhalten. Derzeit imho leider auch noch die Konfigurationsdateien, die geschrieben wurden. Diese werden von uns aber so geschrieben, dass hier nichts einander stört.
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.
Ich kann hier keinen Verbindungsaufbau sehen, kannst du mal versuchen, eine Verbindung aufzubauen und dabei ggf. tcpdump mitlaufen lassen?
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
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?
Würde zwar auf der OPNsense mehr Sinn machen aber wenn du da alles markiert hast, kann ich dir mal sagen dass die Kommunikation One-Way ist und daher der Traffic vermutlich in irgendeiner FW hängen bleibt. Würde mal die Regeln checken.
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?
Die Regel sollte funktionieren, wenn du aus dem WAN kommst.
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?
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!
Deine firewall rule ist immer noch port 1194, aber die Konfig versucht port 443?
Ohne die genaue Konfig kann das kein Mensch debuggen. Ich habe gestern einen neuen openVPN Tunnel gegraben, mit opnsense 17.7 (aktuell) und LibreSSL, das funzt einwandfrei. 99.9% ein Fehler in der Konfig. ;-)
Fang nochmal frisch von vorne an.
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/ (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"
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
Der Server läuft auf IPv6? Da kann ich leider nicht weiterhelfen ;-)
Ich würde mal mit preshared key und ipv4 probieren. dann von dort weiter...
Diese Meldungen hatte ich mal, als ich einen Tunnel mit gleicher server und client IP verbinden wollte. Aber das hattest du ja bereits ausgeschlossen.
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
Server:
dev-type tun
tun-ipv6
Client:
sehe nix von ipv6....
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?
Quote from: chemlud on November 13, 2017, 06:35:51 PM
Der Server läuft auf IPv6? Da kann ich leider nicht weiterhelfen ;-)
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.
Moin,
klingt evtl. etwas blöd, aber wie hängt die OPNsense am Internet?
Direkt per Modem (PPoE) oder hast Du evtl. einen Router davor der die Einwahl erledigt!?
Ich hatte anfangs auch einen Router vor meiner OPNsense. In den WAN-Einstellungen der OPNsense muss dann der Haken bei 'Block private networks' rausgenommen werden. Sonst klappt es trotz korrektem Port-Forwarding auf dem Router nicht mit OpenVPN.
Gruß
Dirk
@Marcel: Was hast du beim OpenVPN Server denn als gebundenes Interface ausgewählt? WAN? Und was als Protokoll? UDP oder UDP6? Ansonsten wenn du kein v6 über den Tunnel machst/machen möchtest ggf. auch noch Disable v6 in der Server Konfig setzen und dann nochmal schauen wie sich die Konfiguration ggf. verändert.
Ansonsten wäre es fein, wenn du die Server Konfig mal zeigen könntest :)
- die OPNsense hängt direkt am Kabel-Modem (THOMSON), es ist also kein zusätzlicher Router dazwischen
- als angebundenes Interface beim OpenVPN-Server ist WAN ausgewählt
- als Protokoll UDP
Ansonsten ist meine aktuelle Server-Config wie auch die Client-Config ja schon weiter oben gepostet.
Danke für Hilfe (ich stehe völlig auf dem Schlauch und kann mir keinen Reim darauf machen, warum das nicht funktionieren will)!
So, hatte jetzt auch noch einmal wie empfohlen "Disable IPv6" bei der Server-Config gesetzt, trotzdem - es geht nicht. :o
Anbei noch einmal die aktuelle Server-Config:
dev ovpns1
verb 3
dev-type tun
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"
Sowie die Client-Config (exportiert als "Viscosity bundle OSX"):
#-- Config Auto Generated for Viscosity --#
#viscosity startonopen false
#viscosity dhcp true
#viscosity dnssupport true
#viscosity name OpenVPN-UDP-1194-Mac-On
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
verify-x509-name "OpenVPN_UDP_1194_Server_certificate_MacOn" name
auth-user-pass
remote-cert-tls server
comp-lzo adaptive
passtos
ca ca.crt
tls-auth ta.key 1
cert cert.crt
key key.key
Noch irgend jemand eine Idee?
Auch auf die Gefahr hin, dass ich hier langsam nerve ... ::)
Zumindest eine Kleinigkeit (ein bug?) ist mir gerade noch bei der Server-Config aufgefallen.
push "route 192.168.1.0 255.255.255.0"
Dies steht da jetzt 2x drin!
Eingetragen hatte ich es ursprünglich bei "Advanced" als zusätzliche Option (so wie in der weiter oben verlinkten Anleitung auch beschrieben).
Und da ich gestern ja noch einmal wie empfohlen "Disable IPv6" aktiviert hatte, sonst aber nichts geändert hatte, kann ich es mir nur so erklären, dass dies durch dieses nochmaliges ändern und speichern der Server-Config geschehen ist?
Und auch dazu sage ich: Bitte nicht falsch verstehen (ich finde OPNsense spitze, vor allem da es "OpenSource" ist), aber auch das zeigt einmal mehr, dass bei diesem Projekt configs fehlerhaft gesichert werden (können).
Dieser spezielle Fall mag jetzt keine gravierenden Auswirkungen haben (der doppelt vorhandene Eintrag wird sehr wahrscheinlich einfach ignoriert werden), aber es ist doch schon bedenklich, wenn so etwas überhaupt passieren kann!?!
Wer weiß, an welcher Stelle noch ähnliche Fehler lauern, die dann aber weitreichendere Auswirkungen haben?
PS: Da ich den Fehler leider nicht eingrenzen kann werde ich vermutlich nicht drum herum kommen, OPNsense nun komplett auf die Werkseinstellungen zurückzusetzen und das setup noch einmal von vorn zu beginnen. Werde es dann auch in einer anderen Reihenfolge angehen und OpenVPN mit als erstes konfigurieren.
Danke trotzdem für Eure Hilfe!
>aber auch das zeigt einmal mehr, dass bei diesem Projekt configs fehlerhaft gesichert werden (können).
Ist das angegebene Netz nicht einfach dein LAN? Wenn ja - warum hast du es dann überhaupt nochmal in den Advanced Settings eingetragen? :o
Dann ist es kein Wunder, dass es doppelt drinsteht - was in dem Fall allerdings auch egal wäre, denn ob es nun einmal oder zweimal gepusht wird, das Netz wird eben in der Routing Table stehen. Das hat dann nichts mit irgendwelchem Projekt, Open Source oder Konfiguration falsch speichern zu tun, wenn du selbst es in den Adv. Settings reinschreibst wird es natürlich auch gespeichert, selbst wenn es doppelt ist. Daher HEISST das Feld ja Advanced! Settings. Dort Einträge zu machen geschieht logischerweise auf eigene Gefahr, denn das zu parsen und auszuwerten ob das OK ist was die Leute da reinpacken ist annähernd unmöglich.
Gruß
@JeGr
https://www.sparklabs.com/support/kb/article/setting-up-an-openvpn-server-with-opnsense-and-viscosity/
...in der Anleitung steht das mit der "push route" für's eigene Netz ausdrücklich drin. Verstanden hab' ich's nicht wirklich, wenn man doch sein Netz sowieso angeben muss in der Konfig...
Was wieder ein Grund sein mag, warum ich mich zwar einerseits über Howtos und Tutorials freue aber sie nicht wirklich mag. Oft beziehen sie sich auf ältere oder alte Versionen, Sachen stimmen so nicht mehr oder sind überholt und dann fragt man sich, warum der Kram nicht funktioniert... Da leider die Screens ja ziemlich zusammengeschnitten sind sieht man auch nicht ob sich das Ganze ggf. auf eine alte/ältere Version bezieht. Der Sinn erschließt sich mir aber nicht wirklich.
@JeGr: Diese "Advanced"-Einstellung habe ich an keiner einzigen anderen Stelle gesetzt, sondern ausschließlich (und wie in der Anleitung der Viscosity-Macher vorgesehen) bei der OpenVPN-Server-Config.
Es bleibt also dabei: Diese Einstellung wurde eindeutig deshalb 2x in das Config-file geschrieben, weil ich an der OpenVPN-Server-Config (wie von einem weiteren Foren-Mitglied vorgeschlagen) die Option "Disable IPv6" aktiviert hatte!
Wie Du darauf kommst, dass ich das im "LAN"-Netz eingetragen hätte, erschließt sich mir nicht ...
Auch hatte ich ja das Problem (eingangs erwähnt), dass Firewall-Configs, die eigentlich schon gelöscht waren, plötzlich doch wieder auftauchten! Mag am Browser-Caching oder was auch immer gelegen haben, aber Mozilla Firefox ist ja nun auch kein ungewöhnlicher Browser behaupte ich mal.
Und aus meiner Sicht habe ich hier auch so ziemlich alles gepostet, was möglich war bzw. gewünscht wurde:
- Server- & Client-Config
- TCPDUMP-Aufzeichnungen sowohl der OPNsense als auch des MacBooks
Auch habe ich sichergestellt, dass DynDNS ordnungsgemäß funktioniert, dass das korrekte Interface (WAN) bei der OpenVPN-Server-Config ausgewählt ist, dass die per Wizard gesetzten Firewall-Regeln korrekt sind - ja ich habe sogar auf einen Fehler in der Viscosity-Anleitung verwiesen (DNS-settings), der nun korrigiert ist.
Und trotzdem haben wir leider keine Lösung gefunden! :-\
Ich kann auch gern den Part übernehmen, eine komplett deutsche Anleitung inklusive Screenshots zu erstellen, die dann auch wirklich von allen "abgesegnet" ist und als Referenz-Anleitung durchgehen kann.
Aber eigentlich hätte ich, bevor ich die OPNsense wieder auf die Werkseinstllungen zurücksetze, schon gern gewusst, warum zum T***** das nicht funktioniert?
Maaaannn, liess mal deine Anleitung unter Punkt 9.:
" To allow access to machines on the local network, enter your local IP range in the Local Network setting. It will probably be something like 10.0.0.0/24."
Damit sollte die route *auch* gepushed werden.
"Wir" brauchen keine Lösung, openVPN funzt, du hast die Konfig irgendwo mit einem Typo oder ähnlichem verk*t. Hinsetzen, nochmal machen, bis es geht. Weinen hilft ja nix, es kommt niemand und setzt dir deinen Kram auf... ;-)
Das hier niemand vorbei kommt, um mir das aufzusetzen, ist mir schon klar. ;)
Dass es der Hauptsonsor Deciso (bei dem ich auch die Hardware gekauft habe, um dieses Projekt zu unterstützen) aber scheinbar nicht für nötig hält, auf eine E-Mail zu reagieren (ich warte nun bereits eine Woche auf eine Reaktion), ist mehr als schwach, zumal ich eigentlich noch extra draufgezahlt hatte für einen (offensichtlich ja nicht vorhandenen!!!) Support für ein Jahr.
Fakt ist, Du empfiehlst mir so zu agieren, wie ich es eigentlich nur von Windows-Kollegen kenne - wenn es nicht klappt, Maschine einfach platt machen und noch einmal von vorn beginnen (geht schneller, als den eigentlichen Fehler einzugrenzen).
Sorry, aber ich nutze macOS, weil ein BSD darunter steckt und Du eventuell ein Linux, weil es eben Linux ist.
Und dort haben wir Log-Files und TCPDUMP und und und ...
Und wenn ich schon seit Monaten an irgend welchen configs schrauben würde, gäbe ich Dir im Zweifel ja sogar recht.
Hier reden wir aber von einer OPNsense, die taufrisch vor wenigen Tagen mit 17.7 bestückt wurde!
Und da kann es ja wohl nicht sein, dass alles schon so verkorkst sein soll ...
...die Idee zum Werksreset kam von DIR. ;-)
Was bitte soll denn der Hersteller machen? Wenn deine Fritzbox "nicht geht", kommen die dann vorbei und setzen dir das Ding auf? :-D
QuoteDas hier niemand vorbei kommt, um mir das aufzusetzen, ist mir schon klar. ;)
Doch, "vorbei" kommen und aufsetzen könnten schon Leute. Aber da das Zeit-intensiv sein kann, kostet das meistens Geld ;)
QuoteDass es der Hauptsonsor Deciso (bei dem ich auch die Hardware gekauft habe, um dieses Projekt zu unterstützen) aber scheinbar nicht für nötig hält, auf eine E-Mail zu reagieren (ich warte nun bereits eine Woche auf eine Reaktion), ist mehr als schwach, zumal ich eigentlich noch extra draufgezahlt hatte für einen (offensichtlich ja nicht vorhandenen!!!) Support für ein Jahr.
Der "Hauptsponsor" hat erstmal primär nix mit der Projektleitung oder -führung (im Sinne von "er muss aber X oder Y") zu tun. Nur weil du bspw. eine Asterisk Appliance von Firma X kaufst, hat die Firma an der Stelle auch nichts damit zu tun, wenn dein Asterisk nicht läuft und kann dann dem Projekt vorschreiben irgendwas zu ändern. Ich glaube da verwechselst du ein paar Abhängigkeiten.
Was du für Support gekauft hast, kann ich natürlich nicht sagen, aber ich vermute es war Hardware(!) Support und kein Software Support? Ansonsten hättest du sicherlich entsprechende Daten bekommen an die du dich direkt wenden kannst für den OPNsense Support.
QuoteFakt ist, Du empfiehlst mir so zu agieren, wie ich es eigentlich nur von Windows-Kollegen kenne - wenn es nicht klappt, Maschine einfach platt machen und noch einmal von vorn beginnen (geht schneller, als den eigentlichen Fehler einzugrenzen).
Das wird auch nur deshalb empfohlen, weil es in deinem Fall sehr schwierig ist genau klar zu erkennen, an welcher Stelle was falsch aufgesetzt ist. Du hast irgendwelche Einstellungen vorgenommen, dann ein externes Tutorial verwendet das ggf. ältere oder nicht mehr aktuelle Einstellungen beschreiben könnte und nun noch beim Debugging irgendwelche Haken gesetzt. Inzwischen ist einfach nicht mehr klar erkennbar, wo du dir ggf. selbst auf der Leitung stehst. Deshalb ist es in solch einem Fall - und weil das Aufsetzen im Normalfall sehr schnell geht - einfach die einfachste Form nochmal schnell von einem eindeutigen Stand anzufangen ohne irgendwelche falschen Einstellungen. Ansonsten müsste man schon alle Ecken prüfen, von DNS über Filter Regeln, NAT, OpenVPN settings etc. um mal ein konkretes Bild zu erkennen.
Quote> Sorry, aber ich nutze macOS, weil ein BSD darunter steckt und Du eventuell ein Linux, weil es eben Linux ist.
> Und dort haben wir Log-Files und TCPDUMP und und und ...
Was hat das denn gerade mit dem Problem zu tun? :)
QuoteEs bleibt also dabei: Diese Einstellung wurde eindeutig deshalb 2x in das Config-file geschrieben, weil ich an der OpenVPN-Server-Config (wie von einem weiteren Foren-Mitglied vorgeschlagen) die Option "Disable IPv6" aktiviert hatte!
Das sagst du - allerdings sage ich an der Stelle, dass die Option mit der Route Push Option eigentlich nichts zu tun hat denn das einzige was dadurch getriggert wird, ist die Option "tun-ipv6". Kann ich hier mehrfach problemlos nachvollziehen. Der Eintrag hat absolut keine Auswirkung auf irgendwelche Route Pushes.
Wie gesagt, das ist alles nicht böse gemeint, aber du machst Annahmen und Aussagen, die so einfach nicht ganz passen und deshalb war die Aussage mit "vielleicht mal resetten/neu installieren" gar nicht so verkehrt. Wenns nur um OpenVPN geht, könnte man auch sicherlich nochmal den ganzen VPN Server wegwerfen und löschen und statt eines externen Tutorials einfach mal den intern
bereits vorhandenen! Wizard/Assistenten zum Aufsetzen benutzen. Dann klappts auch vielleicht besser als wenn man mögliche Fehler aus externen Quellen immer wieder wiederholt werden :)
Hallo zusammen,
gerade bei OpenVPN empfehle ich mal die Offizielle "Readme" vom Projekt: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage (https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage)
Um beim Server mehr im Log zu sehen sollte das Verbose Level "verb 4" sein.
Damit eine vom Server gepuschte Route vom Client akzeptiert wird, muss in der Client Config mit einem "pull" ergänzt werden. Dies steht in deiner Client Config, wie ich gerade im Thread gelesen habe, nicht drin.
Beste Grüße
NR
So, habe jetzt mal den User (der die VPN-Verbindung aufbauen darf) sowie sämtliche Zertifikate gelöscht. Sowie den Server natürlich.
Zusätzlich habe ich auch noch einmal per SSH auf der OPNsense geschaut, ob da configs von OpenVPN liegen geblieben sind und diese ebenfalls entfernt.
Außerdem den Browser gewechselt (Safari 11.0.2 statt Firefox 57) und sicherheitshalber den Browser-Cache gelöscht.
Am Ende auch noch einmal die OPNsense komplett neu gestartet.
Frage: Nach einem Neustart der OPNsense sehe ich im Dashboard, dass ntpd und suricata nicht automatisch aktiv sind (sondern nur configd, dhcpd, dyndns, pf sowie unbound) - woran kann das liegen?
Wenn ich ntpd dann manuell starte, läuft ntpd problemlos und auch suricata wird dabei automatisch mit gestartet.
Bei Suricata kann ich dir das leider nicht sagen. Bei NTP könnte es an mehreren Dingen liegen. Gibt es dazu Log Einträge? Der NTP kann z.B. ein bestimmtes Fehler-Intervall nicht überschreiten. Sprich wenn die Zeit um mehr als (2h?) daneben liegt, wird der NTP nicht korrigieren und ggf. beenden. Oder er konnte nicht starten/laufen weil ggf. das WAN noch nicht sauber da war o.ä. - das sollte sich aber im Log finden lassen. Hast du direkt nach einem Neustart geschaut oder den Diensten ein paar Minuten Zeit gegeben dass sie vielleicht noch gestartet hätten? :)
Du hast recht, wenn man sich etwas in Geduld übt, startet der Zeit-Server doch noch. :)
Im log stand übrigens folgendes direkt nach einem Neustart:
Nov 18 18:04:17 OPNsense ntpdate[723]: step time server 129.70.132.34 offset -0.596793 sec
Nov 18 18:04:17 OPNsense ntp: Successfully synced time after 1 attempts.
Nov 18 18:04:17 OPNsense ntp: Starting NTP Daemon.
Nov 18 18:04:17 OPNsense ntpd[79547]: ntpd 4.2.8p10@1.3728-o Wed Oct 25 06:38:17 UTC 2017 (1): Starting
Nov 18 18:04:17 OPNsense ntpd[79547]: Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
Nov 18 18:04:18 OPNsense ntpd[79894]: proto: precision = 0.202 usec (-22)
Nov 18 18:04:18 OPNsense ntpd[79894]: Listen and drop on 0 v6wildcard [::]:123
Nov 18 18:04:18 OPNsense ntpd[79894]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Nov 18 18:04:18 OPNsense ntpd[79894]: Listen normally on 2 em0 192.168.1.1:123
Nov 18 18:04:18 OPNsense ntpd[79894]: Listen normally on 3 em0 [fe80::f690:eaff:fe10:1eef%1]:123
Nov 18 18:04:18 OPNsense ntpd[79894]: Listen normally on 4 lo0 [::1]:123
Nov 18 18:04:18 OPNsense ntpd[79894]: Listen normally on 5 lo0 127.0.0.1:123
Nov 18 18:04:18 OPNsense ntpd[79894]: Listening on routing socket on fd #26 for interface updates
Nov 18 18:04:18 OPNsense ntpd[79894]: mlockall(): Cannot allocate memory
Nov 18 18:05:14 OPNsense ntpd[79894]: ntpd exiting on signal 15 (Terminated)
Nov 18 18:05:14 OPNsense ntpd[79894]: 129.70.132.34 local addr 192.168.1.1 -> <null>
Dieses "Cannot allocate memory" sieht etwas eigenartig aus, kann ich aber wahrscheinlich ignorieren?
Später sieht es im log dann so aus:
Nov 18 18:05:31 OPNsense ntpdate[49019]: adjust time server 85.14.245.16 offset 0.001104 sec
Nov 18 18:05:31 OPNsense ntp: Successfully synced time after 1 attempts.
Nov 18 18:05:31 OPNsense ntp: Starting NTP Daemon.
Nov 18 18:05:31 OPNsense ntpd[93042]: ntpd 4.2.8p10@1.3728-o Wed Oct 25 06:38:17 UTC 2017 (1): Starting
Nov 18 18:05:31 OPNsense ntpd[93042]: Command line: /usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/ntpd.pid
Nov 18 18:05:31 OPNsense ntpd[93075]: proto: precision = 0.205 usec (-22)
Nov 18 18:05:31 OPNsense ntpd[93075]: restrict: 'monitor' cannot be disabled while 'limited' is enabled
Nov 18 18:05:31 OPNsense ntpd[93075]: Listen and drop on 0 v6wildcard [::]:123
Nov 18 18:05:31 OPNsense ntpd[93075]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Nov 18 18:05:31 OPNsense ntpd[93075]: Listen normally on 2 em0 192.168.1.1:123
Nov 18 18:05:31 OPNsense ntpd[93075]: Listen normally on 3 em0 [fe80::f690:eaff:fe10:1eef%1]:123
Nov 18 18:05:31 OPNsense ntpd[93075]: Listen normally on 4 lo0 [::1]:123
Nov 18 18:05:31 OPNsense ntpd[93075]: Listen normally on 5 lo0 127.0.0.1:123
Nov 18 18:05:31 OPNsense ntpd[93075]: Listening on routing socket on fd #26 for interface updates
Nov 18 18:05:31 OPNsense ntpd[93075]: mlockall(): Cannot allocate memory
So, mittlerweile habe ich es per OPNsense Wizard noch einmal "from scratch" versucht - hat leider wieder nicht funktioniert.
Habe deshalb jetzt alternativ in meinem Synology-NAS einen OpenVPN-Server aktiviert und in der OPNsense NAT/Port Forward aktiviert.
Source
--------
If: WAN
Proto: UDP
Address: *
Ports: 1194 (OpenVPN)
Destination
-------------
Address: LAN address
Ports: 1194 (OpenVPN)
IP: 192.168.1.111
Ports: 1194 (OpenVPN)
Und auch so klappt es nicht. :'(
Jetzt habe ich langsam die Vermutung, dass es eventuell mit meinem Internet-Provider zu tun haben könnte?
Tele Columbus (mein bisheriger Kabelnetz-Provider) wurde vor kurzem zu Pyur.
https://www.pyur.com/ (https://www.pyur.com/)
Und da seit der Umstellung zum Beispiel auch im Online-Portal keine Rechnungen mehr abrufbar sind, würde es mich nicht wundern, wenn es eventuell auch an anderer Stelle klemmt?
Ist das denkbar? Falls ja, wie kann man so etwas am besten überprüfen?
PS: Ich habe schon auf gefühlt hunderten Synology-NAS OpenVPN aktiviert und das entsprechende Port Forwarding & DynDNS im Router konfiguriert, das hatte bisher nirgendwo Probleme bereitet. Nur bei mir will es nicht klappen ... weder mit OPNsense selbst noch mit Synology.
Ist also eventuell mein Internet-Provider Schuld?
Ergänzung: Denn auf dem WAN-Interface habe ich einen 100.xxx.xxx.xxx Adresse, außen aber meine auch per DynDNS-erreichbare "normale" IPv4-Adresse. Pyur setzt also Carrier Graded Nat ein - und das ist dann also offensichtlich mein Problem?
Tunnel mit gleicher (öffentlicher) IP für Server und Client funktionieren nicht. Nie.
Du bräuchtest einen Server bei einem Bekannten, mit anderer öffentlicher IP...
Testen kannst du deine Konfig ganz einfach, trage doch statt deiner öffentlichen IP die IP des LAN Interfaces der OPNsense ein, dann siehst ob der Verbindungsaufbau funktioniert. Mit traceroute kannst du dann vom Client prüfen ob der Pfad durch den VPN Tunnel genutzt wird.
Bei einem Kabelprovider wird wahrscheinlich nur die Öffentliche Ipv6 Adresse der OPNsense von aussen erreichbar sein, aber auch nur dann wenn im Router davor die OPNsense in dessen Firewall freigegeben wurde.
In Ordnung, jetzt habe ich also (endlich!!!) erst einmal verstanden, warum das bisher nicht funktioniert.
Sobald ich statt meiner DynDNS-Adresse zum Test die interne 192.168.1.111 meines Synology-NAS eintrage, funktioniert die OpenVPN-Verbindung.
Das selbe Ergebnis hätte ich mit Sicherheit, wenn ich den OpenVPN-Server jetzt z.B. wieder direkt auf der OPNsense einrichte und mich dann mit der internen 192.168.1.1 der OPNsense verbinden würde.
Die OpenVPN-Config war also grundsätzlich i.O., sowohl auf der OPNsense, also auch auf dem Synology-NAS.
Mein Problem ist also dieses so genannte "Carrier Graded Nat" - extern habe ich zwar die IP 158.181.74.19, teile mir diese aber "dank" NAT mit vielen anderen Nutzern. Und mein WAN-Interface hat eigentlich die 100.93.0.154 ... Deshalb funktioniert das alles nicht zur Zeit. :-[
Wie gehe ich damit am besten um? Egal ob ich bei synology.me oder bei no-ip.com eine DynDNS-Adresse nutze, beide geben mir ja nur diese (gemeinsam genutzte) öffentliche IP 158.181.74.19.
Was ich jetzt bräuchte, nämlich eine Port-Weiterleitung von dieser 158.181.74.19 auf meine WAN-Adresse 100.93.0.154 kann ja sowieso nur mein Provider für mich einrichten, und das macht der garantiert nicht. :'(
Was wäre denn in solch einem Fall die beste Lösung für mich?
Ich würde schon gern mein NAS und auch einige Dienste, die ich im lokalen Netzwerk betreibe, per VPN von außen erreichen können.
PS: Das hier habe ich gerade noch bei heise gefunden, ist zwar von 2013, aber betrifft mich ja auch (Quelle: https://www.heise.de/forum/c-t/Netze/Server-Dienste/Re-DYNDNS-nutzlos/posting-243003/show/ (https://www.heise.de/forum/c-t/Netze/Server-Dienste/Re-DYNDNS-nutzlos/posting-243003/show/)):
Solltest du wirklich hinter CGN stecken, bleiben dir nur noch folgende Optionen, wie teilweise schon von anderen gesagt:
1.) IPv6 – langfristig die ,,richtig" Lösung. Wenn Telecolumbus CGN bereits eingeführt hat, dann besteht auch die Chance, dass sie dir evtl. auch schon IPv6 geben. Guck doch mal, ob dein Router das unterstützt (Fritzboxen bspw. ab 7270 – oder wie AVM sagt: ,,die zweite Ziffer in der Modellnummer muss >= 2 sein) und ob dir Telecolumbus IPv6 gibt. Dann noch einen mobilen Tunnel für den Zugriff von außen organisieren und mit der Zukunft glücklich werden.
2.) einen VPN-Tunnel bauen, der sich von drinnen nach draußen über einen Relay-Server aufbaut. Großes Gebastel. Wahrscheinlich auch nicht allzu stabil. Aber einen Versuch wert.
3.) Quängeln. Verschiedene andere Kabelprovider (wenngleich auch nicht Telecolumbus) haben auf dem IPv6-Kongress unter der Hand gesagt, sie würden Kunden, die nur lange genug jammerten, bei CGN auch wieder auf eine public IP umstellen (die anderen störts nicht)
4.) PCP – ganz heiße Scheiße, das ,,Port Control Protocol" gibt die Möglichkeit, auch bei einem CGN noch ein Portforwarding zu installieren. Das ist aber momentan wirklich brandneu (RFC vom April 2013) und wahrscheinlich noch nicht implementiert. AVM baut das gerade in die Fritzbox ein und es ist angemessen, es von deinem ISP zu erwarten, dass er das umsetzt, wenn er dich hinter ein NAT verfrachtet. Nachfragen!
Was sagt ihr dazu? Was wäre Eure Empfehlung?
Bei dir geht also nur IPv6 eingehend, am CG-NAT deines Anbieters kannst du leider nichts ändern. Du kannst aber so einen Dienst nutzen, falls du IPv4 unbdingt brauchst: http://www.feste-ip.net/
Dein Anwendungsgebiet ist das hier: http://www.feste-ip.net/dslite-ipv6-portmapper/allgemeine-informationen/
Allerdings sind die Laufzeit Preise von feste-ip.net so, dass man sich besser gleich nen V-Server Mieten kann und die Umleitung darüber laufen lässt. Siehe hier: https://www.netcup.de/bestellen/produkt.php?produkt=1712
Besser wäre natürlich ein Internet Anschluss mit Dual-Stack, aber je nach dem wo man sich befindet geht das ja leider nicht.
Ansonsten würde ich Quengeln bei Telecolumbus mal versuchen.
> Ansonsten würde ich Quengeln bei Telecolumbus mal versuchen.
Dito. Oft hilft auch schon die Argumentation, dass es ggf. schonmal funktioniert hat (wenn die den Laden eh gerade gekauft haben, kann das gut sein weil sie jetzt IPs sparen wollen), und du das aus beruflichen Gründen für deinen Arbeitgeber brauchst, weil du für Homeoffice/Banking auf einen VPN Tunnel angewiesen bist der funktionieren muss, der aber nur mit echtem v4 bzw. DualStack klappt. Mit letzterer Argumentation sind schon einige Kunden bei UM, KD oder der Telekom durchaus dazu gekommen, dass sie wieder eine v4 bekommen haben.
Gruß
Ich danke Euch allen erst einmal für Eure Geduld und Unterstützung.
Echt übel, dieses CGN (Carrier Graded NAT).
Habe eine "echte" IPv4-Adresse heute sowohl im PYUR-Shop beantragt (ehemals Tele Columbus) als auch jetzt noch einmal per Kontakt-Formular auf der PYUR-Webseite.
Die Hotline von denen ist der absolute Witz - egal zu welcher Uhrzeit man von Mo. bis Fr. zwischen 8 und 22 Uhr anruft, entweder wartet man bis zu 30 Minuten in der Warteschleife und fliegt dann raus (es wird einfach aufgelegt nach knapp einer halben Stunde) oder aber es kommt sogar gleich die Ansage, dass alle Mitarbeiter beschäftigt sind und man es später noch einmal versuchen solle (und da wird dann auch direkt aufgelegt).
Im Shop sagte man mir heute schon, solch eine Änderung könne bis zu 4 Wochen dauern, da aktuell alle Mitarbeiter überlastet seien. :(
Das ist wirklich übel, zumal es ja ursprünglich (zu Tele Columbus Zeiten) funktioniert hatte und nun scheinbar seit PYUR nicht mehr!
Ich frage mich auch nach wie vor, ob man in solch einem Falle nicht ein Sonderkündigungsrecht hat, denn Anschlüsse mit solchem CGN sind doch - wenn man es genau nimmt - "verkrüppelte" Internet-Anschlüsse, die für Oma Trude und Netflix ja ausreichen mögen, für jeden ambitionierten Anwender aber so massive Einschränkungen mit sich bringen (kein normales IPv4-Port-Forwarding mehr möglich), dass der Anschluss im Prinzip völlig nutzlos ist, sobald man "von außen" auf sein privates Netzwerk zugreifen möchte.
Als Notbehelf habe ich jetzt QuickConnect auf der Synology aktiviert, finde das zwar nicht so pralle, weil der Relay-Server von Synology ja im Prinzip auch ein "man in the middle" ist (bzw. sein kann wenn er möchte), aber anders geht es ja vorerst erst einmal nicht und so komme ich wenigstens erst einmal an wichtige Dateien auf meiner Synology.
DynDNS und IPv4-Port-Forwarding oder von mir aus auch eine "feste" IPv4-Adresse nebst entsprechender Port-Weiterleitung brauche ich aber nach wie vor, um OpenVPN spielen zu können.
Hoffe, dass das so schnell wie möglich geklärt wird bei PYUR ... :-\
Auf alle Fälle noch einmal vielen vielen Dank für Eure Geduld und Unterstützung - ihr seid Klasse!
Auch wenn ich dir zum Großteil zustimme, ist es aus Sicht der Provider bzw. "Allgemeinheit" eher so:
Quote"verkrüppelte" Internet-Anschlüsse, die für Oma Trude und Netflix ja ausreichen mögen, für jeden ambitionierten Anwender aber so massive Einschränkungen mit sich bringen (kein normales IPv4-Port-Forwarding mehr möglich), dass der Anschluss im Prinzip völlig nutzlos ist, sobald man "von außen" auf sein privates Netzwerk zugreifen möchte.
Das stimmt so nicht. Die Anschlüsse sind nicht verkrüppelt, sie gewähren Zugang zum Internet. Und zwar - dank CGN - auch zum noch gesamten IPlegacy (v4) Netzwerk. Die "massiven Einschränkungen" von denen du sprichst, haben für die meisten Leute überhaupt keinen Impact, da dort das Internet über den Provider-Router genutzt wird. Und der macht IPv6 + CGN für den Rest und gut ist. Da IPv6 auch bei den Providern und Hostern eine immer größere Rolle spielt und endlich mal großflächiger ausgerollt wird, ist auch wirklich ein Zeitpunkt absehbar, ab dem Gegenstellen genauso per v6 und v4 erreicht werden können und du dann an diesem Anschluß völlig normal angebunden bist.
Ein weiterer Punkt deiner Einschränkung "von außen drauf zugreifen" ist genau der Punkt, den jeder Povider ja versucht so unattraktiv wie möglich zu machen. Egal ob das IPv6 / CGN ist, ob das Zwangstrennungen sind, ob das wechselnde IP Adressen und rotierende IPv6 Prefix Vergabe (unter dem Deckmantel der "Privatsphäre") ist, ob das asynchrone Leitungen mit stark vermindertem Upstream ist, alle Maßnahmen zielen letztendlich darauf ab, dass es dir so unattraktiv wie möglich gemacht wird, über deine Leitung selbst Dienste bereitzustellen. Wer sich (wie ich beruflich) mit Preisen von Leitungsanbietern in bspw. Datacentern oder an größeren Unternehmensstandorten beschäftigen muss, dem wird da schnell auffallen, wie extrem günstig solche Angebote à la Kabel-Internet mit Datenraten von 400/20 bspw. sind. Wer versucht, das annähernd (nicht vom Kabelanbieter) in der Beschaffenheit als Glasfaser oder ähnlichem und dann noch dazu Flat(!) ins Haus gelegt zu bekommen, dem wird bald der Kopf brummen. Die Leistung für den Endkunden ist vergleichbar günstig. Und damit dann Firmen nicht auf die Idee kommen die billige Consumerlösung auch für die eigenen Dienste zu nutzen, muss man ja einen "Mehrwert" schaffen - selbst wenn der stark gekünstelt ist ;)
Tatsächlich ist der Zugriff von außen ins Heimnetz ja eine sehr spezifische "Prosumer" Geschichte. Nicht nur der Omi, den meisten reicht einfach der Anschluß nach draußen - wer bietet schon selbst Webseiten oder -Dienste auf seinem eigenen Server bei sich daheim an und warum auch? Daher ist das überhaupt kein Einsatzgebiet für Privatanschlüsse und demzufolge auch kein Fokus. :)
Zuletzt noch die Formulierung bei der ich schmunzeln musste: "kein normales Port Forwarding/NAT" möglich, Anschluß nutzlos. Warum? Du bist doch im Internet oder nicht? ;) Nein, der Punkt ist eher: NAT wurde gebraucht WEIL plötzlich zu Hause nicht mehr nur ein Computer stand mit einem Modem und Direkteinwahl, sondern plötzlich 2 oder 3. Heute sind da sicher mind. ein paar dutzend IPs im Haus unterwegs bei vielen Prosumern. Trotzdem ist und bleibt NAT letztendlich seit zig Jahren per se eines: eine RIESIGE Krücke, die man loswerden will. Dass man sich überhaupt mit Port Forwardings und Outbound NAT herumschlagen muss liegt ja nur an der IP Knappheit und der Massenträgheit der Provider, Hoster und Verantwortlichen, am Schema F etwas zu ändern. Wäre IPv6 ordentlich und zügig implementiert worden wie alle noch vor Jahren genickt haben, wäre das heute schon lange kein Thema mehr und wir würden uns eher mit den Nachwirkungen der Prefix Rotation herumschlagen, die Telekom und Co eingeführt haben anstatt ihren Kunden statische IPv6 Prefixe zuzuordnen.
Aber deshalb ist der Anschluß ja nicht kaputt - nur für dich als angenehden Prosumer eben ungeeignet ;) Und deshalb reagieren die ISPs auch meist nur beim Aufschrei pro Kunde darauf. Wo man Adressen sparen kann, werden sie eben eingesackt und gespart, denn heute ist jede IPv4 bares Geld wert.
Sorry für das Pamphlet :D Ich verstehe natürlich völlig den Ärger auf deiner Seite - für den Anbieter ist das Verhalten aber recht normal. Siehe auch Kabelanbieter, die als neuster Mitspieler am Markt heute natürlich die wenigsten v4 Adressen haben und dementsprechend sehr stark haushalten müssen und am ehesten deshalb hoffen, dass v6 bald flächig kommt.
Grüße
Jens
Quote from: JeGr on November 21, 2017, 10:16:00 PM
Ein weiterer Punkt deiner Einschränkung "von außen drauf zugreifen" ist genau der Punkt, den jeder Povider ja versucht so unattraktiv wie möglich zu machen. Egal ob das IPv6 / CGN ist, ob das Zwangstrennungen sind, ob das wechselnde IP Adressen und rotierende IPv6 Prefix Vergabe (unter dem Deckmantel der "Privatsphäre") ist, ob das asynchrone Leitungen mit stark vermindertem Upstream ist, alle Maßnahmen zielen letztendlich darauf ab, dass es dir so unattraktiv wie möglich gemacht wird, über deine Leitung selbst Dienste bereitzustellen.
Gerade die IPv6 Prefix Rotation geht mir ziemlich auf die Nerven. Ich würde ja gerne mein Internes Netz nur mit dem Privaten Adressraum "[fd::]" versehen, aber leider macht eben diese Prefix Rotation das unmöglich. So würde das Ipv6 VPN Routing auch einfacher werden, so geht eben nur IPv4, weil sich auf allen Seiten die Prefixe ja immer ändern.
Leider wurden bei Ipv6 in vielen Dingen (Designentscheidungen und deren Umsetzung) teilweise die gleichen Fehler gemacht, wie bei IPv4. Mit der Netzwerkgröße mal angefangen, denn wer braucht in einem Netzwerksegment so viele Adressen wie 2x IPv4 ???? Die Netzwerkgeräte Router etc. kommen teilweise auch nicht mit kleineren gerouteten Netzen klar. Jeder der ein Netz bei der Ripe beantragt bekommt mehr Adressen als jemals gebraucht werden. Irgendwann bekommen die das gleiche Problem wie jetzt bei IPv4. Da fällt mir echt nichts mehr zu ein....
> Gerade die IPv6 Prefix Rotation geht mir ziemlich auf die Nerven.
I feel you. Mir ebenso :(
> Irgendwann bekommen die das gleiche Problem wie jetzt bei IPv4. Da fällt mir echt nichts mehr zu ein....
Der Satz fällt immer wieder ist aber nicht richtig bzw. unbegründet. Selbst die größten ISPs wie Telekom und Co haben eine Adressraum Zuteilung die groß genug für sie ist und wir haben trotz allem nur das 2000:: Netz überhaupt angekratzt! Also "das gleiche Problem" bekommen wir mit Sicherheit nicht. Dass die Adressräume so gewählt sind mit /64 liegt teils in Hardware und Berechnung (ASICS) zu Grunde und dass für gewisse Dinge eben eine gewisse räumliche Größe sinnvoll nutzbar sein soll/muss. Ja da sind immer noch genug drölf-tausende Adressen dann frei, aber man muss einfach das Legacy v4 denken auch mal über Bord werfen bei v6 und es mal konsequent umsetzen, dann sieht man auch dass es weit weniger dramatisch ist, als man denkt.
> Die Netzwerkgeräte Router etc. kommen teilweise auch nicht mit kleineren gerouteten Netzen klar.
Ja aber nur bei statischer Vergabe. Alle Automatismen wie SLAAC und Co setzen auf /64er min. Prefix Size auf.
Aber auch das ist im Prinzip nicht anders (Achtung doofer v4 Vergleich) als ein /24 für ein Transfernetz von bspw. VPN o.ä. zu verwenden. Nur dass eben bei v6 alle Adressen voll routingfähig sind.
> weil sich auf allen Seiten die Prefixe ja immer ändern.
Hauptsächlich ja beim Client - leider. Und durch das dämliche rotieren teils innerhalb weniger Tage kann man auch mit NPt nicht wirklich sinnvoll was gegen machen, denn auch das müsste man ständig statisch nachpflegen. Und damit sind wir wieder bei dyndns - bzw. dynprefix oder dynv6 - damit man das wieder irgendwo zum routing anmelden kann. Miserabel. Und immer unter dem Deckmantel der Kundenfreundlichkeit (das ist nur zum Schutz ihrer Privatsphäre...)
Leider hat Sixxs ja seinen Tunnel eingestellt, aber wenn du ein statisches v6 haben möchtest - HE.net funktioniert wenigstens ordentlich und gibt dir ggf. auch ein /48er Prefix nach Anmeldung. Ansonsten sind 1-2 /64er auch kein Thema :)