pfSense Usergroup #016 - 2022-03-04 - 17:00

Bob.Dig

Ich hab mich inzwischen an einem p2p TLS Server versucht, wobei ich die ganzen Keys etc. von einem bestehenden Remote Access Server genommen habe.
Die Verbindung mit dem Windows Client kam auch zu stande, aber die Cipher negotiation nicht, so dass ich letztens wieder bei 265 CBC gelandet bin und nicht bei CHACHA20-POLY1305, was mein Favorit gewesen wäre.

JeGr

@bob-dig said in pfSense Usergroup #016 - 2022-03-04 - 17:00:

aber die Cipher negotiation nicht, so dass ich letztens wieder bei 265 CBC gelandet bin und nicht bei CHACHA20-POLY1305, was mein Favorit gewesen wäre.

sowas liegt dann aber an der Einstellung an Server und Client. Wenns da nicht passt gibts eben nen Fallback. Und Chacha20 gibts erst ab OVPN 2.5, wenn also Client alt ist klappt das nicht.

Bob.Dig

@jegr Moin, der client ist aktuell und ja, irgendwas hat nicht gepasst, so wie immer mit OpenVPN bei mir, hat halt kein GUI und so...

Bob.Dig

@JeGr Ich bin inzwischen weiter:

Apr 27 09:20:56     openvpn     571     Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA512

Apr 27 09:20:56     openvpn     571     Incoming Data Channel: Cipher 'CHACHA20-POLY1305' initialized with 256 bit key

Apr 27 09:20:56     openvpn     571     Outgoing Data Channel: Cipher 'CHACHA20-POLY1305' initialized with 256 bit key

Die Speed kann bei mir aber dennoch nicht mit WG mithalten. Any thoughts?

JeGr

@bob-dig said in pfSense Usergroup #016 - 2022-03-04 - 17:00:

Die Speed kann bei mir aber dennoch nicht mit WG mithalten. Any thoughts?

Speed zwischen wem oder was?

Bob.Dig

@jegr said in pfSense Usergroup #016 - 2022-03-04 - 17:00:

@bob-dig said in pfSense Usergroup #016 - 2022-03-04 - 17:00:

Die Speed kann bei mir aber dennoch nicht mit WG mithalten. Any thoughts?

Speed zwischen wem oder was?

Zwischen Home (pfSense) und VPS (Windows) mittels Peer to Peer ( SSL/TLS ) .

C:\iperf>iperf3.exe -c 10.0.9.2 -P 3 -R
Connecting to host 10.0.9.2, port 5201
Reverse mode, remote host 10.0.9.2 is sending
[  4] local 192.168.1.10 port 60793 connected to 10.0.9.2 port 5201
[  6] local 192.168.1.10 port 60794 connected to 10.0.9.2 port 5201
[  8] local 192.168.1.10 port 60795 connected to 10.0.9.2 port 5201
[ ID] Interval           Transfer     Bandwidth
[SUM]   0.00-10.00  sec   160 MBytes   135 Mbits/sec                  sender
[SUM]   0.00-10.00  sec   160 MBytes   135 Mbits/sec                  receiver

iperf Done.

JeGr

@bob-dig said in pfSense Usergroup #016 - 2022-03-04 - 17:00:

Zwischen Home (pfSense) und VPS (Windows) mittels Peer to Peer ( SSL/TLS ) .

Da macht auch Chacha20Poly1305 kein Sinn. Warum kein AES-GCM nutzen? Das ist ja x64 Hardware und kein Arm o.ä. ohne Crypto Beschleunigung. Da ist GCM im Normalfall wesentlich effizienter. Und -P 5 wäre normaler für Tests. 5 Streams sind recht normal auf ner Leitung.

Bob.Dig

@jegr Abend, auch der Wechsel auf AES-256-GCM hat die Lage nicht geändert, 100% CPU Last auf dem Windows VPS.

C:\iperf>iperf3.exe -c 10.0.9.2 -R -P 5
Connecting to host 10.0.9.2, port 5201
Reverse mode, remote host 10.0.9.2 is sending
[  4] local 192.168.1.10 port 63195 connected to 10.0.9.2 port 5201
[  6] local 192.168.1.10 port 63196 connected to 10.0.9.2 port 5201
[  8] local 192.168.1.10 port 63197 connected to 10.0.9.2 port 5201
[ 10] local 192.168.1.10 port 63198 connected to 10.0.9.2 port 5201
[ 12] local 192.168.1.10 port 63199 connected to 10.0.9.2 port 5201
[ ID] Interval           Transfer     Bandwidth
[SUM]   0.00-10.00  sec   164 MBytes   138 Mbits/sec                  sender
[SUM]   0.00-10.00  sec   164 MBytes   138 Mbits/sec                  receiver

Ich werde also morgen nochmal WG einrichten und gucken, ob der Vorteil von damals noch besteht. Bin jetzt auch frohen Mutes was das NATing betrifft, denke das kriege ich dieses mal hin auf dem WinServer.

PS: Auch mit AES-128-GCM keine Änderung.

Bob.Dig

Also bei mir ist die Sache eindeutig, wenn ich nicht vorher beim OVPN Server noch irgendeine nicht optimal Einstellung drin habe.

Mit Wireguard:

C:\iperf>iperf3.exe -c 10.1.9.1 -R -P 5
Connecting to host 10.1.9.1, port 5201
Reverse mode, remote host 10.1.9.1 is sending
[  4] local 192.168.1.10 port 65281 connected to 10.1.9.1 port 5201
[  6] local 192.168.1.10 port 65282 connected to 10.1.9.1 port 5201
[  8] local 192.168.1.10 port 65283 connected to 10.1.9.1 port 5201
[ 10] local 192.168.1.10 port 65284 connected to 10.1.9.1 port 5201
[ 12] local 192.168.1.10 port 65285 connected to 10.1.9.1 port 5201
[ ID] Interval           Transfer     Bandwidth
[SUM]   0.00-10.00  sec   304 MBytes   255 Mbits/sec                  sender
[SUM]   0.00-10.00  sec   304 MBytes   255 Mbits/sec                  receiver

NAT und Autostart unter Windows habe ich auch hinbekommen, damit fliegt OVPN raus.

JeGr

@bob-dig AMD K6? Das war doch ein Duron oder Chomper? Die sind doch 19-vorm-Krieg. Das der keine ordentliche AES-GCM hinbekommt würde mich jetzt nicht super wundern. Ist das nur ne falsche Anzeige oder wirklich so ne alte Kiste? Wenn ja - kein Wunder. AES-NI war 2010 von Intel eingeführt. K6 ist definitiv älter. Dass der mit der Crypto zu Knabbern hat wundert nicht. Da kann Wireguard im Kernel mit CHACHA20 und stärkerer Parallelisierung mehr rausholen.

Bob.Dig

@jegr Das war der VPS bei netcup für unter drei Öcken/M.
WG läuft bis jetzt auch rund. Diesen stateless approach habe ich jetzt auch mal umgesetzt, kein monitoring mehr, kein keep alive, sondern beide Seiten können die Verbindung jederzeit herstellen. Wahrscheinlich nix für den Profi-Bereich aber es hat was, komme mir so öko vor.

JeGr

@bob-dig said in pfSense Usergroup #016 - 2022-03-04 - 17:00:

@jegr Das war der VPS bei netcup für unter drei Öcken/M.
WG läuft bis jetzt auch rund. Diesen stateless approach habe ich jetzt auch mal umgesetzt, kein monitoring mehr, kein keep alive, sondern beide Seiten können die Verbindung jederzeit herstellen. Wahrscheinlich nix für den Profi-Bereich aber es hat was, komme mir so öko vor.

Hrhr ;) Ey wenns läuft ist doch gut. Ich habe ja selbst gesagt dass ich denke, dass WG da gerade im S2S Mode den Rang ablaufen wird. Aber Einwahl für >5-10 Leute ist halt ein Krampf wenn du das alles selbst konfigurieren und bei Leuten einrichten musst. Da muss noch mehr Feinschliff und Support via Export Assistenten oder QR Code oder Kram her :)

Bob.Dig

@jegr Das auf jeden Fall. Es gibt weitere Sachen, die mich wundern.
Wireguard für Windows erlaubt mir meinen "eigenen" privaten Key zu exportieren, zusammen mit dem öffentlichen Key der Gegenseite.
Ich habe dies nun gemacht und anschließend den Tunnel komplett im Programm gelöscht. Anschließend habe ich das ganze wieder importiert und mein öffentlicher (edit) Key, der nicht Teil des Exportes war, wurde ebenfalls wieder verwendet. Sprich, mein öffentlicher (edit) Key ist wohl Teil der Installation geworden(?), aber ist selbst, zumindest nicht offensichtlich, exportierbar.
Das macht ein Deployen natürlich ebenfalls schwierig. Für mich privat natürlich kein Problem... Vielleicht werde ich mal WG für Android probieren, um mir ein noch besseres Bild der Lage zu machen.
Edit: Musste was korrigieren.

Bob.Dig

Holy... der öffentliche Schlüssel kann bei WG jederzeit aus dem Privaten Schlüssel gebildet werden? Okay, ich habe das Protokoll nicht verstanden.

Edit: Verstanden wäre eh zu viel gesagt, aber nach etwas Recherche auf youtube: Nicht nur, dass es genauso ist, der öffentliche kann jederzeit aus dem privaten gebildet werden, auch gibt es keinerlei "Verhandlungen", also den ungeschützten Port auf dem VPS zu öffnen ist völlig risikolos und darauf antwortet auch nichts gegenüber einem Dritten, sehr geil.

JeGr

@bob-dig said in pfSense Usergroup #016 - 2022-03-04 - 17:00:

Holy... der öffentliche Schlüssel kann bei WG jederzeit aus dem Privaten Schlüssel gebildet werden? Okay, ich habe das Protokoll nicht verstanden.

Hö? Na klar wird der öffi Schlüssel AUS dem privaten gebildet. Ist ja ein Schlüsselpaar. So funktioniert GPG/PGP etc. genauso. Oder SSH. Oder whatever. Aus dem private Key ist IMMER logischerweise der öffentliche ableit-/errechenbar. Warum auch nicht? Darum ists ja der PRIVATE Schlüssel

Darum gibt es ja die Möglichkeit bei WG zusätzlich zum reinen Schlüsselaustausch als 2. Faktor noch einen PSK on top zu definieren. Damit müssen die Schlüssel auf beiden Seiten passen UND der gemeinsame Verbindungs-PSK.

Naja antwortet "nichts" ist ja so auch nicht richtig. Es antwortet Wireguard. Und wartet, dass du was tust und dich mit deinem Schlüssel etc. vorstellst. Und wenn er dich nicht kennt - fliegste halt raus. Auch nicht signifikant anders als bei SSH mit "Pubkey only" Setup, dann gibts auch kein Passwortrategedöns und die andere Seite fliegt direkt bei nicht-senden eines Keys hochkant raus.

Bob.Dig

@jegr Also ich meine mal gehört zu haben, dass die beiden Schlüssel zwar in einer Beziehung stehen, aber quasi gleichwertig sind, also man könnte sie rein technisch auch tauschen, hier scheint es mir aber anders zu sein.

Der PSK scheint wohl eher gegen quanten-computer zu schützen, hab ich natürlich auch eingerichtet.

Ich hab keine Ahnung von SSH, leider, aber bei WG schlägt nicht mal ein Portscan an, weil WG halt nichts antwortet, solange du nicht autorisiert bist. Keine Ahnung, ob das bei SSH genauso ist.

Kurz, auch ich bin jetzt begeistert.

JeGr

@bob-dig said in pfSense Usergroup #016 - 2022-03-04 - 17:00:

@jegr Also ich meine mal gehört zu haben, dass die beiden Schlüssel zwar in einer Beziehung stehen, aber quasi gleichwertig sind, also man könnte sie rein technisch auch tauschen, hier scheint es mir aber anders zu sein.

Nope, never. Sonst wäre das eine kein öffentlicher Schlüssel. Einem public key ist die Tatsache zu eigen, dass ich ihn problemlos weitergeben und bekannt machen darf und kann ohne Rückschlüssel auf den private key zu haben. Normalerweise wird das mathematisch via Falltür Algorithmus gemacht, also ne Rechnung, die nicht reversibel ist aber immer den gleichen Quark ausgibt einfach ausgedrückt. Somit kannst du aus Priv immer Pub machen aber aus Pub niemals Priv.

Andernfalls wäre das ja brandgefährlich weil du aus den öffentlichen Keys private ableiten könntest

Bei SSH antwortet natürlich der Server - ist eine TCP Verbindung. Wireguard läuft ja auf UDP und das ist normalerweise stateless. UDP Ports zu erkennen ist daher etwas tricky aber IMHO kann man WG Ports schon erkennen. Man kommt halt nur nicht sehr weit ;) Und das ist ja auch sinnvoll, denn man will den ja nicht verschließen müssen

OVPN macht an der Stelle eben beides, kann UDP oder TCP und verhält sich daher anders. Nicht schlechter oder besser einfach anders. Man muss sich nur im Hinterkopf behalten, dass WG eben noch jung ist, es auch was schiefgehen könnte und es aktuell noch "beta" ist. Alpha nicht mehr, aber auch nicht "rock solid super stable". Wenn man das auf'm Schirm hat - let's go :)

Bob.Dig

@jegr said in pfSense Usergroup #016 - 2022-03-04 - 17:00:

Nope, never.

Danke, keine Ahnung, wie sich das bei mir eingeschlichen hatte.