OpenVPN - bekomme keine Verbindung zustande

Started by Marcel_75, November 09, 2017, 11:18:51 PM

Previous topic - Next topic
Print
Go Down Pages1 2 3 4
User actions
November 09, 2017, 11:18:51 PM Last Edit: November 09, 2017, 11:21:35 PM by Marcel_75
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).
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
November 10, 2017, 11:07:28 AM #1
* 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
"It doesn't work!" is no valid error description! - Don't forget to [applaud] those offering time & brainpower to help you!
Better have some *sense as no(n)sense! ;)

If you're interested in german-speaking business support, feel free to reach out via PM.
November 10, 2017, 03:15:51 PM #2
- 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?
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
November 10, 2017, 03:24:17 PM #3
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)
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
November 10, 2017, 03:25:49 PM #4
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.
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
November 10, 2017, 03:28:41 PM #5
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

The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
November 10, 2017, 08:05:57 PM #6 Last Edit: November 10, 2017, 10:58:53 PM by Marcel_75
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
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
November 11, 2017, 11:05:48 AM #7
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
November 11, 2017, 12:20:45 PM #8
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.
November 11, 2017, 05:53:00 PM #9
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.
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
November 11, 2017, 06:08:55 PM #10
Ich kann hier keinen Verbindungsaufbau sehen, kannst du mal versuchen, eine Verbindung aufzubauen und dabei ggf. tcpdump mitlaufen lassen?
November 11, 2017, 09:31:11 PM #11 Last Edit: November 11, 2017, 09:33:11 PM by Marcel_75
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
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
November 11, 2017, 09:35:53 PM #12
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?
The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
November 11, 2017, 10:26:58 PM #13
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.
November 11, 2017, 11:59:39 PM #14 Last Edit: November 12, 2017, 10:31:25 AM by Marcel_75
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?

The fact that we live at the bottom of a deep gravity well, on the surface of a gas covered planet going around a nuclear fireball 90 million miles away and think this to be normal is obviously some indication of how skewed our perspective tends to be. (Douglas Adams)
Print
Go Up Pages1 2 3 4
User actions