Where does openvpn GUI (on Windows) store the user's password, if the
user chooses to store the credentials?
--
Ralf Hildebrandt
Charité - Universitätsmedizin Berlin
Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
Invalidenstraße 120/121 | D-10115 Berlin
Tel. +49 30 450 570 155
I'm quite sure that doesn't exist - but is there a way of syncing
existing sessions between VPN gateways?
--
Ralf Hildebrandt
Charité - Universitätsmedizin Berlin
Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
Invalidenstraße 120/121 | D-10115 Berlin
Tel. +49 30 450 570 155
> I shall assume that your question is "how do I tell the client *not* to try
> sticking to the last IP used?". ;-)
Yes!
> I don't see such an option in the docs (for 2.6, to be precise), but let me
> ask a question for clarification: Does your setup answer requests to a
> now-disabled IP with
Hi!
We're using DNS Round-robin-records with a TTL of 300s for our openvpn
endpoint servers.
Yet, clients seem to reconnect to the same IP, although the DNS entry
has expired; the log usually shows something like:
2024-02-21 11:37:04 TCP/UDP: Preserving recently used remote address:
* Jason Long via Openvpn-users :
> Hello,
> If I want to use the "tls-crypt" option, then the "ta.key" must be a separate
> file and it cannot be merged with the rest of the keys in one file. To be
> honest, it is difficult to use for both computer and mobile users because it
> is two files.
>
* Lev Stipakov :
> Yeah there is definitely something wrong with dco driver behavior on
> that Windows machine. Looks like some TCP packets (running over UDP
> tunnel) got lost?
>
> There is more we could do to look into it, but I need some time to
> prepare necessary steps. Meanwhile it would be
* Lev Stipakov :
> I checked the logs you've sent to me in private and data channel
> params are identical in both dco and non-dco cases.
Ah thanks for the feedback (and to all the others: The logs were
huge, that's why I sent them in private)
> It would be nice to get the logs from the driver
> > Once I switch the 2.6.5 windows client (with DCO) to UDP mode, we
> > still have fast downstream (measured on the client, 644Mbit/s) but
> > only 0.76Mbit/s upstream.
>
> Interesting. We haven't seen this before.
Thought so,
> > So it's some sort of DCO issue -- but only with UDP. Any ideas
We have a setup with the server having no dco, but some clients do
have 2.6.5 and thus DCO enabled. Works like a charm in TCP mode
(upstream/downstream both high bandwidth).
Once I switch the 2.6.5 windows client (with DCO) to UDP mode, we
still have fast downstream (measured on the client,
* Jonny Oschätzky via Openvpn-users :
> On 17.06.23 14:37, Ralf Hildebrandt via Openvpn-users wrote:
> > Attached is the actual crl file in PEM format.
>
> My OpenVPN (Debian 12) does not complain about your crl.
>
> Jun 17 15:17:05 tenebris openvpn[3094334]: Diffi
> This is from the working connection - so it's "just log noise", it seems,
> not causing an actual session abort.
Good!
> My gut feeling is that there is some garbage at the *end* of the CRL file,
> so OpenSSL is able to read "loaded 1 CRLs" from the file, and then there is
> something more,
* Jonny Oschätzky via Openvpn-users :
> On Tuesday, 13 June 2023 10:16:36 CEST Ralf Hildebrandt via Openvpn-users
> wrote:
>
> > routines:get_name:no start line Jun 13 03:06:23 openvpn-igel-int
> > tcp[452155]: CRL: cannot read CRL from file /etc/openvpn/ca/crl.pem
>
&g
Using openvpn 2.6.4-focal0 (on Ubuntu focal 20.04)
My log says:
Jun 13 03:06:23 openvpn-igel-int tcp[452155]: OpenSSL: error:140E0197:SSL
routines:SSL_shutdown:shutdown while in init
Jun 13 03:06:23 openvpn-igel-int tcp[452155]: OpenSSL: error:140E0197:SSL
routines:SSL_shutdown:shutdown while
* Gert Doering :
> If you generate the tokens "outside" and need to tie them to the "proper"
> username (so the reauthentication from $mobile will not invalidate a
> single-use token for $laptop), this might indeed be needed...
We can workaround this by handing all the devices of userA the same
* Gert Doering :
> - actually *changing* the auth-token-user from an original username/password
>authentication - it runs into the same problem, but this might be
>workaroundable by not actually pushing a new "user". So, question to
>you, what is the intention behind changing the
Hi!
We're trying to use a script-generated username as well as an
script-generated auth-token and pushing them to the client from a
client connect script (2.5.5 on the client in this case, 2.6.3 on the
server), like this:
auth-token-user {authtoken_username_b64}
push "auth-token-user
> As far as I understand, 2.6.2 .deb for focal should also be compiled
> "with DCO enabled" now.
Yep!
--
Ralf Hildebrandt
Charité - Universitätsmedizin Berlin
Geschäftsbereich IT | Abteilung Netzwerk
Campus Benjamin Franklin (CBF)
Haus I | 1. OG | Raum 105
Hindenburgdamm 30 | D-12203 Berlin
* Gert Doering :
> On Fri, Mar 10, 2023 at 04:32:37PM +0100, Ralf Hildebrandt via Openvpn-users
> wrote:
> > Now we checked this on our different ubuntu machines and found that
> > openvpn (from the official build repos)
> >
> > on focal: had no DCO
> >
The release notes say:
configure now enables DCO build by default on FreeBSD and Linux. On
Linux this brings in a new default dependency for libnl-genl (for
Linux distributions that are too old to have a suitable version of the
library, use "configure --disable-dco")
Now we checked this
Did I miss the 2.6.1 announcement? It was released on the 8th, but no
announcement it seems.
--
Ralf Hildebrandt
Charité - Universitätsmedizin Berlin
Geschäftsbereich IT | Abteilung Netzwerk
Campus Benjamin Franklin (CBF)
Haus I | 1. OG | Raum 105
Hindenburgdamm 30 | D-12203 Berlin
Tel. +49 30
* Huma Yari :
> We are having openvpn and it is a few days that I can see the following error
> in our server log file:
So, just a few guidelines how to approach this:
1) Find out something about that IP. Where's that located?
Solution: Probably the city Sanya, province Hainan, China.
* Huma Yari :
> Hello everyone,
>
> We are having openvpn and it is a few days that I can see the following error
> in our server log file:
>
> Feb 10 10:44:33 openvpn 34974 TLS Error: cannot locate HMAC in incoming
> packet from [AF_INET]59.50.242.0:56359
Is that server using TCP or Udp?
--
* Gert Doering :
> What they need to do is to enable "compression migrate" on the server
> side, and stop unconditionally pushing "comp-lzo no" to clients that
> are not signalling that they can handle this.
Ah THAT's what we need to use :)
--
Ralf Hildebrandt
Charité - Universitätsmedizin
> It does, and it matters a lot. Mullvad breaks the OpenVPN protocol
> with their server configs (they should never ever push "comp-lzo"
> settings to a client that is not signalling it's willingness to accept
> them).
That's a bit like the problem we had locally. We were pushing
"compress" to
* Stella Ashburne :
> Please find below the config file with "verb 4" and "--disable-dco"
> parameters and the connection log.
>
> My Mozilla Firefox is able to open websites when the dco is disabled.
>
>
> client
> dev tun
> resolv-retry infinite
> nobind
> persist-key
> persist-tun
> verb 4
A new day, a new observation!
$ sudo openvpn --config charite-hildeb.ovpn --up
/etc/openvpn/update-resolv-conf --down /etc/openvpn/update-resolv-conf
... connection is being established, and now I'm sending ctrl-c to openvpn on
the client ...
2023-01-19 10:11:40 Initialization Sequence
> Is there something related to compression in the main config and/or in
> the per-client config (ccd, plugin, ...)?
No, but...
> Anything special config generated by the client-connect script, maybe?
That was it, the client-connect script was pushing:
# Compression anschalten, aber nicht
You might have noticed our bug reports regarding capabilities && 2.6rc2.
The whole point of it all was to test 2.6.x's DCO in our openvpn infrastructure
:)
Upgrades were made, kernel module were being compiled and modprobed,
the gateway's filesystem is cluttered with source packages and
hotfixed
* Doug Lytle :
> >>> Are there tuning tips regarding this particular setup (or openvpnm on
> >>> virtualized hardware), of is virtualbox merely a poor choice :)
>
> I'd say that VB is a poor choice.
Thought so.
> If you have any control over your server environment, I'd suggest a
> type 1
We used to run Openvpn-2.4.8 on bare metal (old hardware), but
currently we're running Openvpn-2.4.8 in a VM on a virtualbox host
system.
With the same software we're seeing excessive CPU consumption by the
UDP based openvpn process. Symptoms are high latency when using
interactive (read: ssh)
> Your OpenVPN is linked against OpenSSL; the hardware crypto comes from the
> openssl library, which nowadays almost always uses the hardware crypto
> (aesni) stuff. You can verify it using an openssl command:
...
> If the results or the two above commands are equal, then your openssl
>
We're (finally) running OpenVPN-2.4.8 on new(er) hardware. How can we
see if it is using the CPU based hardware crypto?
Nov 7 16:00:21 openvpn2019 tcp[704]: OpenVPN 2.4.8 x86_64-pc-linux-gnu [SSL
(OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Oct 30 2019
Nov 7 16:00:26
32 matches
Mail list logo
