Re: [Openvpn-users] surf the internet through openvpn

[Jan Just Keijser]

Hi,

On 03/06/21 17:30, Fermin Francisco via Openvpn-users wrote:

Good morning!

How can I make openvpn clients (Linux clients) surf the internet 
through openvpn using the public ip of the openvpn server (the openvpn 
server is on Windows)?And also that emails using Thunderbird can work 
with this method (that emails can enter and leave without problems).



this writeup for Windows 7 is a good starting point:

https://forums.openvpn.net/viewtopic.php?f=7&t=7806

HTH,

JJK
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] figuring out connection interface

[Aleksandar Ivanisevic]

> On 3. Jun 2021, at 14:36, Jan Just Keijser  wrote:
> from reading the 2.5.1 sources I cannot find any environment variables being 
> set that reflect the "incoming" IP address or interface;   I would think that 
> during 'client-connect' time you can determine from which IP the client is 
> connecting, e.g. by looking at the connection details at the OS level.  This 
> may not be fool proof, however.

how would you suggest to do that? Nothing comes to mind except inspecting the 
conntrack table or logging at the firewall level, which boils down to grepping 
different logs. Not to mention that not everyone is running the vpn server on 
the firewall, noone shouldn’t actually ;)

> It may be best to actually grep the logs, especially as you can easily grep 
> for "Peer Connection Initiated".

Not so easily for tunnels running longer than the logs are kept though. 

> 
> HTH,
> 
> JJK
> 
> PS now waiting for Gert to prove me wrong ;)

Please be wrong ;) Or can we have a feature request for server IP and interface 
to be passed in connect script env or in one of the status reports in 
management interface or in —status file or at all three places ;)

___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] figuring out connection interface

[Gert Doering]

Hi,

On Fri, Jun 04, 2021 at 12:20:10PM +0200, Aleksandar Ivanisevic wrote:
> > PS now waiting for Gert to prove me wrong ;)
> 
> Please be wrong ;) Or can we have a feature request for server
> IP and interface to be passed in connect script env or in one of
> the status reports in management interface or in ???status file or
> at all three places ;)

The "server IP address" - at least for UDP based OpenVPN sessions - needs
to be sorted "somewhere" in our socket structure, so the "send packet"
path can choose the right source address.

That said, I have no idea if it is ever exposed to management API or
plugin/script env... "some reading of the source" is needed.

gert


-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Openvpn-users] Openvpn install ubuntu 20.04 compile

[Gokan Atmaca]

Hello

I am getting an error as below in openvpn installation. what would be
the reason ?

make[5]: Leaving directory '/root/tmp1/openvpn/src/plugins/down-root'
make[4]: Leaving directory '/root/tmp1/openvpn/src/plugins/down-root'
make[4]: Entering directory '/root/tmp1/openvpn/src/plugins'
make[5]: Entering directory '/root/tmp1/openvpn/src/plugins'
make[5]: Nothing to be done for 'install-exec-am'.
make[5]: Nothing to be done for 'install-data-am'.
make[5]: Leaving directory '/root/tmp1/openvpn/src/plugins'
make[4]: Leaving directory '/root/tmp1/openvpn/src/plugins'
make[3]: Leaving directory '/root/tmp1/openvpn/src/plugins'
Making install in tapctl
make[3]: Entering directory '/root/tmp1/openvpn/src/tapctl'
make[4]: Entering directory '/root/tmp1/openvpn/src/tapctl'
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/root/tmp1/openvpn/src/tapctl'
make[3]: Leaving directory '/root/tmp1/openvpn/src/tapctl'
make[3]: Entering directory '/root/tmp1/openvpn/src'
make[4]: Entering directory '/root/tmp1/openvpn/src'
make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/root/tmp1/openvpn/src'
make[3]: Leaving directory '/root/tmp1/openvpn/src'
make[2]: Leaving directory '/root/tmp1/openvpn/src'
Making install in sample
make[2]: Entering directory '/root/tmp1/openvpn/sample'
make[3]: Entering directory '/root/tmp1/openvpn/sample'
make[3]: Nothing to be done for 'install-exec-am'.
make[3]: Leaving directory '/root/tmp1/openvpn/sample'
make[2]: Leaving directory '/root/tmp1/openvpn/sample'
Making install in doc
make[2]: Entering directory '/root/tmp1/openvpn/doc'
Making install in doxygen
make[3]: Entering directory '/root/tmp1/openvpn/doc/doxygen'
make[4]: Entering directory '/root/tmp1/openvpn/doc/doxygen'
make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/root/tmp1/openvpn/doc/doxygen'
make[3]: Leaving directory '/root/tmp1/openvpn/doc/doxygen'
make[3]: Entering directory '/root/tmp1/openvpn/doc'
Missing python-docutils - skipping man page generation
make[4]: Entering directory '/root/tmp1/openvpn/doc'
make[4]: Nothing to be done for 'install-exec-am'.
 /usr/bin/mkdir -p '/usr/local/share/doc/openvpn'
 /usr/bin/install -c -m 644 management-notes.txt gui-notes.txt
'/usr/local/share/doc/openvpn'
Missing python-docutils - skipping man page generation
 /usr/bin/mkdir -p '/usr/local/share/man/man8'
 /usr/bin/install -c -m 644 ./openvpn.8 '/usr/local/share/man/man8'
/usr/bin/install: cannot stat './openvpn.8': No such file or directory
make[4]: *** [Makefile:515: install-man8] Error 1
make[4]: Leaving directory '/root/tmp1/openvpn/doc'
make[3]: *** [Makefile:773: install-am] Error 2
make[3]: Leaving directory '/root/tmp1/openvpn/doc'
make[2]: *** [Makefile:606: install-recursive] Error 1
make[2]: Leaving directory '/root/tmp1/openvpn/doc'
make[1]: *** [Makefile:615: install-recursive] Error 1
make[1]: Leaving directory '/root/tmp1/openvpn'
make: *** [Makefile:915: install] Error 2


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Openvpn install ubuntu 20.04 compile

[tincantech via Openvpn-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

‐‐‐ Original Message ‐‐‐
On Friday, 4 June 2021 16:04, Gokan Atmaca  wrote:

> Hello
>
> I am getting an error as below in openvpn installation. what would be
> the reason ?
>
> make[5]: Leaving directory '/root/tmp1/openvpn/src/plugins/down-root'
> make[4]: Leaving directory '/root/tmp1/openvpn/src/plugins/down-root'
> make[4]: Entering directory '/root/tmp1/openvpn/src/plugins'
> make[5]: Entering directory '/root/tmp1/openvpn/src/plugins'
> make[5]: Nothing to be done for 'install-exec-am'.
> make[5]: Nothing to be done for 'install-data-am'.
> make[5]: Leaving directory '/root/tmp1/openvpn/src/plugins'
> make[4]: Leaving directory '/root/tmp1/openvpn/src/plugins'
> make[3]: Leaving directory '/root/tmp1/openvpn/src/plugins'
> Making install in tapctl
> make[3]: Entering directory '/root/tmp1/openvpn/src/tapctl'
> make[4]: Entering directory '/root/tmp1/openvpn/src/tapctl'
> make[4]: Nothing to be done for 'install-data-am'.
> make[4]: Leaving directory '/root/tmp1/openvpn/src/tapctl'
> make[3]: Leaving directory '/root/tmp1/openvpn/src/tapctl'
> make[3]: Entering directory '/root/tmp1/openvpn/src'
> make[4]: Entering directory '/root/tmp1/openvpn/src'
> make[4]: Nothing to be done for 'install-exec-am'.
> make[4]: Nothing to be done for 'install-data-am'.
> make[4]: Leaving directory '/root/tmp1/openvpn/src'
> make[3]: Leaving directory '/root/tmp1/openvpn/src'
> make[2]: Leaving directory '/root/tmp1/openvpn/src'
> Making install in sample
> make[2]: Entering directory '/root/tmp1/openvpn/sample'
> make[3]: Entering directory '/root/tmp1/openvpn/sample'
> make[3]: Nothing to be done for 'install-exec-am'.
> make[3]: Leaving directory '/root/tmp1/openvpn/sample'
> make[2]: Leaving directory '/root/tmp1/openvpn/sample'
> Making install in doc
> make[2]: Entering directory '/root/tmp1/openvpn/doc'
> Making install in doxygen
> make[3]: Entering directory '/root/tmp1/openvpn/doc/doxygen'
> make[4]: Entering directory '/root/tmp1/openvpn/doc/doxygen'
> make[4]: Nothing to be done for 'install-exec-am'.
> make[4]: Nothing to be done for 'install-data-am'.
> make[4]: Leaving directory '/root/tmp1/openvpn/doc/doxygen'
> make[3]: Leaving directory '/root/tmp1/openvpn/doc/doxygen'
> make[3]: Entering directory '/root/tmp1/openvpn/doc'
> Missing python-docutils - skipping man page generation
> make[4]: Entering directory '/root/tmp1/openvpn/doc'
> make[4]: Nothing to be done for 'install-exec-am'.
> /usr/bin/mkdir -p '/usr/local/share/doc/openvpn'
> /usr/bin/install -c -m 644 management-notes.txt gui-notes.txt
> '/usr/local/share/doc/openvpn'
> Missing python-docutils - skipping man page generation
> /usr/bin/mkdir -p '/usr/local/share/man/man8'
> /usr/bin/install -c -m 644 ./openvpn.8 '/usr/local/share/man/man8'
> /usr/bin/install: cannot stat './openvpn.8': No such file or directory
> make[4]: *** [Makefile:515: install-man8] Error 1
> make[4]: Leaving directory '/root/tmp1/openvpn/doc'
> make[3]: *** [Makefile:773: install-am] Error 2
> make[3]: Leaving directory '/root/tmp1/openvpn/doc'
> make[2]: *** [Makefile:606: install-recursive] Error 1
> make[2]: Leaving directory '/root/tmp1/openvpn/doc'
> make[1]: *** [Makefile:615: install-recursive] Error 1
> make[1]: Leaving directory '/root/tmp1/openvpn'
> make: *** [Makefile:915: install] Error 2
>

I believe you need rst2html or rst2man from docutils or docutils-common.


-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJgulADACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ0Pcgf/VEEAZ8GcYHYNlmETEkcLlyys1w5Eb0E/yDR5HL0pQRf782gr
M16NGbxJsetHIzUFQajoCedR6qqZztoi8ms6ZNd9pHM2ToXrucdM1OaU/6Fu
fEHfNY4vC1bOUCCT6ZpoWNBoNKavXrDA/WUkcOLlBFW+QYQ+rr9HJirmF+PL
ehZKWZrfhkOo7VQKoV4jnM4f0UluNdoSnBCJLZPFhGwHhlXbQx6sw0elB+Fk
F0bCv9nJT3p2Rl6ty67ms719ah+HZTXPGnVVZj6QlSRZbag+z+qZU++qMuLG
qyyxtEROYkdFOS/5Ixk4TQMI55irM+cH3lXX+V6ue8uj/l5t5Z8Cfg==
=UJkD
-END PGP SIGNATURE-


publickey - tincantech@protonmail.com - 0x09BC3D44.asc
Description: application/pgp-keys


publickey - tincantech@protonmail.com - 0x09BC3D44.asc.sig
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] figuring out connection interface

[Jan Just Keijser]

Hi,

On 04/06/21 12:20, Aleksandar Ivanisevic wrote:


On 3. Jun 2021, at 14:36, Jan Just Keijser > wrote:
from reading the 2.5.1 sources I cannot find any environment 
variables being set that reflect the "incoming" IP address or 
interface;   I would think that during 'client-connect' time you can 
determine from which IP the client is connecting, e.g. by looking at 
the connection details at the OS level.  This may not be fool proof, 
however.


how would you suggest to do that? Nothing comes to mind except 
inspecting the conntrack table or logging at the firewall level, which 
boils down to grepping different logs. Not to mention that not 
everyone is running the vpn server on the firewall, noone shouldn’t 
actually ;)


you could use the conntrack tool to check the *local* UDP connections 
(e.g. on the server on which OpenVPN is running). The downside is that 
you will most likely need root privileges
It may be best to actually grep the logs, especially as you can 
easily grep for "Peer Connection Initiated".


Not so easily for tunnels running longer than the logs are kept though.

that's a non-argument as the same applies when doing this via a 
client-connect script; I guess  you can run a "grep the server log" at 
'client-connect' time with a small delay and write out the result to a 
file/database. That way you can look for the "Peer Connection Initiated" 
text , say, 15 seconds after the client logs in. Or you could set up 
periodic monitor of the server log file to look for "Peer Connection 
Initiated" and distill the connection from that.





PS now waiting for Gert to prove me wrong ;)


Please be wrong ;) Or can we have a feature request for server IP and 
interface to be passed in connect script env or in one of the status 
reports in management interface or in —status file or at all three 
places ;)


Unless I missed something in the (v2.5.1) sources I think a change 
request might be in place for this - seems non-intrusive.


cheers,

JJK

___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Openvpn-users] Client-to-client setup fails mysteriously...

[Bo Berglund]

I have set up an Openvpn server on a Raspberry Pi at a remote location I can
access through another OpenVPN server.
The new server is a proof-of-concept to  check how client-to-client comm inside
the tunnel works.

For initial testing I am using my Windows10 laptop and a RaspberryPi both on my
home LAN. The RaspberryPi will later be moved to yet another distinct LAN.

Initial tests:
1) Connect RPi to tunnel-only server
Command:
sudo openvpn --config /home/pi/openvpn/SSRemote001.ovpn
This works fine and I can communicate with the vpn server and also open an ssh
session into it from the RPi. 

2) Connect the Windows PC to the tunnel-only server.
Now possible to ping the openvpn server etc.

Those initial teste were done with a sizable time separation and *not* at the
same time.

3) Now connect the RPi again to its (password-less) connection.

4) Connect the Windows 10 PC now fails with TLS negotiation error (timeout)

5) Close both connections.

6) Now again try to connect the RPi, but now it fails also on TLS as does the
Windows 10 connection...

7) Go have dinner for some time...

8) Now back and can connect the RPi fine again!

9) But when the RPi is connected the Windows connection attempt fails with a TLS
timeout error.

What could be causing this strange behavior?

It seems like when the server has been connected to it goes blind for a while
but then returns to normal for a new comm session
Don't know how long one has to wait for.


Server config:
--
port 1196 #NOTE: the port differs between server instances!
server 10.117.3.0 255.255.255.0 'nopool' #Tunnel Network base address
proto udp4 #Use only ipv4
dev tun
ca   /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/AGIVPN.crt
key  /etc/openvpn/keys/AGIVPN.key  # This file should be kept secret
dh   /etc/openvpn/keys/dh2048.pem
tls-auth /etc/openvpn/keys/ta.key 0 # This file is secret
key-direction 0
topology subnet
ifconfig-pool 10.117.3.2 10.117.3.127 255.255.255.0 #Server: 10.117.3.1
client-config-dir /etc/openvpn/ccdtun
ifconfig-pool-persist ipptun.txt 
#Specific config for VPN tunnel only access:
client-to-client
#End specifics
keepalive 10 120
cipher AES-256-CBC
comp-lzo#Compress transfered data
max-clients 20  #Might be set as appropriate for usage
persist-key
persist-tun
verb 4  #Log files verbosity
explicit-exit-notify 1  #Make the server notify client before restarting
status  /etc/openvpn/log/ovpn-status_tun.log
log-append  /etc/openvpn/log/ovpn_tun.log


RPi Client config:
--
remote xyzx.myowndomain.com 1193 #Only for client-to-client comm
client
dev tun
proto udp
resolv-retry infinite
nobind
persist-key
persist-tun
auth-nocache
mute-replay-warnings
remote-cert-tls server
key-direction 1
cipher AES-256-CBC
comp-lzo
verb 1
mute 20

Next follows all the cert/key encryption data

The Windows laptop client config is similar but it uses an encrypted key for
security. The connections from the RPi units are to be done automatically so
their ovpn files are not password protected.

NOTE:
-
The router at the server site is doing port forward from incoming port 1193 to
server port 1196.


-- 
Bo Berglund
Developer in Sweden



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Openvpn install ubuntu 20.04 compile

[Gert Doering]

Hi,

On Fri, Jun 04, 2021 at 06:04:31PM +0300, Gokan Atmaca wrote:
> I am getting an error as below in openvpn installation. what would be
> the reason ?

Is this 2.5.0?  2.5.1?  git master?

My crystal ball is a bit cloudy today.

(Richard is right, rst2man will help, but I think this was a bug in
2.5.0 where it failed installation if rst2man was not available, while
it *should* "just not install" the html page then - but 2.5.0 is old
anyway, 2.5.2 is current)

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Client-to-client setup fails mysteriously...

[Gert Doering]

Hi,

On Fri, Jun 04, 2021 at 08:17:59PM +0200, Bo Berglund wrote:
> 6) Now again try to connect the RPi, but now it fails also on TLS as does the
> Windows 10 connection...

Run both client and server with "verb 4" and see what the logs on both
ends have to say.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Client-to-client setup fails mysteriously...

[Bo Berglund]

On Fri, 04 Jun 2021 20:17:59 +0200, Bo Berglund  wrote:

>What could be causing this strange behavior?
>
>It seems like when the server has been connected to it goes blind for a while
>but then returns to normal for a new comm session
>Don't know how long one has to wait for.

I have now added the directive:
explicit-exit-notify

to the client side ovpn files, but it does not make much difference.

>From what I can see now the openvpn server is only able to authenticate and
connect a *single* client at a time! Thus defeating the whole idea behind using
client-to-client in the first place...

As soon as one connection succeeds a connection from the other device that
succeeded earlier now fails in the TLS phase.

Is there something that must be done to make openvpn server multi-user?
Please check the config files I posted in my previous message!


-- 
Bo Berglund
Developer in Sweden



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Client-to-client setup fails mysteriously...

[Bo Berglund]

On Fri, 4 Jun 2021 21:03:26 +0200, Gert Doering  wrote:

>On Fri, Jun 04, 2021 at 08:17:59PM +0200, Bo Berglund wrote:
>> 6) Now again try to connect the RPi, but now it fails also on TLS as does the
>> Windows 10 connection...
>
>Run both client and server with "verb 4" and see what the logs on both
>ends have to say.

I changed the Windows and RPi cient configs to verb4
Then I connected the RPi client and it succeeded.
Next I tried to connect teh Windows client but it failed as before just hanging
until I disconnect.

I don't know where to look for the RPi client log, do you know where it may be
located?

The Windows log shown by OpenVPN-GUI for the failed connection attempt while the
RPi is connected:

Fri Jun 04 21:30:14 2021 us=500087 Current Parameter Settings:
Fri Jun 04 21:30:14 2021 us=500087   config = 'SSRClient001-tun.ovpn'
Fri Jun 04 21:30:14 2021 us=500087   mode = 0
Fri Jun 04 21:30:14 2021 us=500087   show_ciphers = DISABLED
Fri Jun 04 21:30:14 2021 us=500087   show_digests = DISABLED
Fri Jun 04 21:30:14 2021 us=500087   show_engines = DISABLED
Fri Jun 04 21:30:14 2021 us=500087   genkey = DISABLED
Fri Jun 04 21:30:14 2021 us=500087   key_pass_file = '[UNDEF]'
Fri Jun 04 21:30:14 2021 us=500087   show_tls_ciphers = DISABLED
Fri Jun 04 21:30:14 2021 us=500087   connect_retry_max = 0
Fri Jun 04 21:30:14 2021 us=500087 Connection profiles [0]:
Fri Jun 04 21:30:14 2021 us=500087   proto = udp
Fri Jun 04 21:30:14 2021 us=500087   local = '[UNDEF]'
Fri Jun 04 21:30:14 2021 us=500087   local_port = '[UNDEF]'
Fri Jun 04 21:30:14 2021 us=500087   remote = 'xxx.xxx.com'
Fri Jun 04 21:30:14 2021 us=500087   remote_port = '1193'
Fri Jun 04 21:30:14 2021 us=500087   remote_float = DISABLED
Fri Jun 04 21:30:14 2021 us=500087   bind_defined = DISABLED
Fri Jun 04 21:30:14 2021 us=500087   bind_local = DISABLED
Fri Jun 04 21:30:14 2021 us=500087   bind_ipv6_only = DISABLED
Fri Jun 04 21:30:14 2021 us=500087 NOTE: --mute triggered...
Fri Jun 04 21:30:14 2021 us=519432 275 variation(s) on previous 20 message(s)
suppressed by --mute
Fri Jun 04 21:30:14 2021 us=519432 OpenVPN 2.4.8 x86_64-w64-mingw32 [SSL
(OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 31 2019
Fri Jun 04 21:30:14 2021 us=519432 Windows version 6.2 (Windows 8 or greater)
64bit
Fri Jun 04 21:30:14 2021 us=519432 library versions: OpenSSL 1.1.0l  10 Sep
2019, LZO 2.10
Enter Management Password:
Fri Jun 04 21:30:14 2021 us=519432 MANAGEMENT: TCP Socket listening on
[AF_INET]127.0.0.1:25353
Fri Jun 04 21:30:14 2021 us=519432 Need hold release from management interface,
waiting...
Fri Jun 04 21:30:15 2021 us=16884 MANAGEMENT: Client connected from
[AF_INET]127.0.0.1:25353
Fri Jun 04 21:30:15 2021 us=132240 MANAGEMENT: CMD 'state on'
Fri Jun 04 21:30:15 2021 us=132240 MANAGEMENT: CMD 'log all on'
Fri Jun 04 21:30:15 2021 us=248068 MANAGEMENT: CMD 'echo all on'
Fri Jun 04 21:30:15 2021 us=263691 MANAGEMENT: CMD 'bytecount 5'
Fri Jun 04 21:30:15 2021 us=270230 MANAGEMENT: CMD 'hold off'
Fri Jun 04 21:30:15 2021 us=270230 MANAGEMENT: CMD 'hold release'
Fri Jun 04 21:30:15 2021 us=285894 MANAGEMENT: CMD 'password [...]'
Fri Jun 04 21:30:15 2021 us=301476 Outgoing Control Channel Authentication:
Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jun 04 21:30:15 2021 us=301476 Incoming Control Channel Authentication:
Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jun 04 21:30:15 2021 us=301476 LZO compression initializing
Fri Jun 04 21:30:15 2021 us=301476 Control Channel MTU parms [ L:1622 D:1184
EF:66 EB:0 ET:0 EL:3 ]
Fri Jun 04 21:30:15 2021 us=301476 MANAGEMENT: >STATE:1622835015,RESOLVE,,
Fri Jun 04 21:30:15 2021 us=301476 Data Channel MTU parms [ L:1622 D:1450 EF:122
EB:406 ET:0 EL:3 ]
Fri Jun 04 21:30:15 2021 us=301476 Local Options String (VER=V4): 'V4,dev-type
tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher
AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
Fri Jun 04 21:30:15 2021 us=301476 Expected Remote Options String (VER=V4):
'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher
AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
Fri Jun 04 21:30:15 2021 us=301476 TCP/UDP: Preserving recently used remote
address: [AF_INET]95.192.35.35:1193
Fri Jun 04 21:30:15 2021 us=301476 Socket Buffers: R=[65536->65536]
S=[65536->65536]
Fri Jun 04 21:30:15 2021 us=301476 UDP link local: (not bound)
Fri Jun 04 21:30:15 2021 us=301476 UDP link remote: [AF_INET]95.192.35.35:1193
Fri Jun 04 21:30:15 2021 us=301476 MANAGEMENT: >STATE:1622835015,WAIT,,
Fri Jun 04 21:30:40 2021 us=307700 SIGTERM received, sending exit notification
to peer
Fri Jun 04 21:30:41 2021 us=473967 TCP/UDP: Closing socket
Fri Jun 04 21:30:41 2021 us=473967 SIGTERM[soft,exit-with-notification]
received, process exiting
Fri Jun 04 21:30:41 2021 us=473967 MANAGEMENT:
>STATE:1622835041,EXITING,exit-with-notification,


-- 
Bo Berglund
Developer in Sweden



___

Re: [Openvpn-users] Client-to-client setup fails mysteriously...

[tincantech via Openvpn-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

‐‐‐ Original Message ‐‐‐
On Friday, 4 June 2021 19:17, Bo Berglund  wrote:

> I have set up an Openvpn server on a Raspberry Pi at a remote location I can
> access through another OpenVPN server.

So: HOST:Client -> Server:HOST:Client -> Server:HOST

> 3.  Now connect the RPi again to its (password-less) connection.
> 4.  Connect the Windows 10 PC now fails with TLS negotiation error (timeout)
> 5.  Close both connections.
> 6.  Now again try to connect the RPi, but now it fails also on TLS as does the
> Windows 10 connection...
>
> 7.  Go have dinner for some time...
> 8.  Now back and can connect the RPi fine again!
> 9.  But when the RPi is connected the Windows connection attempt fails with a 
> TLS
> timeout error.
>
> What could be causing this strange behavior?

That's not strange at all ..

And now you have four logs to inspect at --verb 4.
You may have to forego dinner, in future.

Enjoy
R
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJguoPOACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ0iGAf+JSO1+OW1cf0OZLvgYxStBhNXLjRdQDoRYwtJNGCUXWCAulL0
Wj4tRQJjhQ66xCFEKuN6iOjZZxp8Tv5bshhU2i6iORDtdhoPLsD5Y1Y20q87
fnAe2+l5R+7A1ojOnXqUqP62TE2MJxc8hebgQ9BcfP06TtXkjcB6pHGs9FkG
9JDxvgeLCRu5lI5Ql8pqcu1IGgDEtDgpDYJEcAGYLYUk4RxHRb5wub/50Lek
yuIEB6XWfrrp2FbppOQA6/XhRHPjolb0ArOhE65jzV4W0GZmPo2ATHFMOSjb
5lCBpTwKPHAV7ghj/6kuwpjMI5npuyi1HXN+Xl18is+BZYCIqqqkeA==
=4xTX
-END PGP SIGNATURE-


publickey - tincantech@protonmail.com - 0x09BC3D44.asc
Description: application/pgp-keys


publickey - tincantech@protonmail.com - 0x09BC3D44.asc.sig
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Client-to-client setup fails mysteriously...

[Selva Nair]

On Fri, Jun 4, 2021 at 3:34 PM Bo Berglund  wrote:
>
> On Fri, 04 Jun 2021 20:17:59 +0200, Bo Berglund  wrote:
>
> >What could be causing this strange behavior?
> >
> >It seems like when the server has been connected to it goes blind for a while
> >but then returns to normal for a new comm session
> >Don't know how long one has to wait for.
>
> I have now added the directive:
> explicit-exit-notify
>
> to the client side ovpn files, but it does not make much difference.
>
> From what I can see now the openvpn server is only able to authenticate and
> connect a *single* client at a time! Thus defeating the whole idea behind 
> using
> client-to-client in the first place...
>
> As soon as one connection succeeds a connection from the other device that
> succeeded earlier now fails in the TLS phase.

You haven't shown us the server log without which you cannot make any
conclusions. The client log ends at WAIT state which could mean either
there is no route to the server or the server is not responding to TLS
handshake. Post the server log.

My guess would be that there is some messed up routing is happening.
Once the RPi is connected your Win10 client may be losing route to the
server.

Selva


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Client-to-client setup fails mysteriously...

[tincantech via Openvpn-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Correction:

‐‐‐ Original Message ‐‐‐
On Friday, 4 June 2021 20:49, tincantech via Openvpn-users 
 wrote:

> Hi,
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, 4 June 2021 19:17, Bo Berglund bo.bergl...@gmail.com wrote:
>
> > I have set up an Openvpn server on a Raspberry Pi at a remote location I can
> > access through another OpenVPN server.
>
> So: HOST:Client -> Server:HOST:Client -> Server:HOST
>
> > 3.  Now connect the RPi again to its (password-less) connection.
> >
> > 4.  Connect the Windows 10 PC now fails with TLS negotiation error (timeout)
> >
> > 5.  Close both connections.
> >
> > 6.  Now again try to connect the RPi, but now it fails also on TLS as does 
> > the
> > Windows 10 connection...
> >
> > 7.  Go have dinner for some time...
> >
> > 8.  Now back and can connect the RPi fine again!
> >
> > 9.  But when the RPi is connected the Windows connection attempt fails with 
> > a TLS
> > timeout error.
> > What could be causing this strange behavior?
> >
>
> That's not strange at all ..
>
> And now you have four logs to inspect at --verb 4.

You probably have at least five logs to inspect.
Looks like supper is off the menu too !

> You may have to forego dinner, in future.
>
> Enjoy
> R


-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJguoZ3ACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ1WzQf/XomZqAVRKYCxnDabp7gHoc5zW5FpJZS3Wq4IV1YGM9k0IIFU
93WUj+6iUWcbpcugo0sFtlABm4kGDTU3eoXLGirbi/JoSharr4dHLpNo3egJ
bA2/J5d14MiVgEpekINLbw0n5G6KoPAgxkEDYUi0LEJ6XFnTtUJzHuHqMHO1
0/hGSw0LB/qTngEy+GzJ+Eb17VM000v3fFaMywjYjeAb/ZwUrbW/mdzj77jk
GXxTZOhOCMSORqwXtcgnRpMKj1e0mw0i2WZzeNDKAkqCYeQQwLCvgrFlzwF+
KY9lCkFbgoknlBKpbX7arPhTh4xuULnWUplmsxCmlA3gwUAeCoD5Bg==
=drxn
-END PGP SIGNATURE-


publickey - tincantech@protonmail.com - 0x09BC3D44.asc
Description: application/pgp-keys


publickey - tincantech@protonmail.com - 0x09BC3D44.asc.sig
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Client-to-client setup fails mysteriously...

[Bo Berglund]

On Fri, 04 Jun 2021 19:49:36 +, tincantech via Openvpn-users
 wrote:

>> I have set up an Openvpn server on a Raspberry Pi at a remote location I can
>> access through another OpenVPN server.
>
>So: HOST:Client -> Server:HOST:Client -> Server:HOST

I don't quite understand what you mean by this comment.
What I wanted to say is that I heva two OpenVPN servers operational on the
remote network. the origional one is what I use to access that remote network
and I just mentioned it because I have a way to get to the remote network to
inspect things NOT using the system I am working on now.
But I am not connected to that VPN while doing these tests.


>> 3.  Now connect the RPi again to its (password-less) connection.
>> 4.  Connect the Windows 10 PC now fails with TLS negotiation error (timeout)
>> 5.  Close both connections.
>> 6.  Now again try to connect the RPi, but now it fails also on TLS as does 
>> the
>> Windows 10 connection...
>>
>> 7.  Go have dinner for some time...
>> 8.  Now back and can connect the RPi fine again!
>> 9.  But when the RPi is connected the Windows connection attempt fails with 
>> a TLS
>> timeout error.
>>
>> What could be causing this strange behavior?
>
>That's not strange at all ..

To me it is really strange that if I run an OVPN server and connect using a
client on one computer, then the VPN server is no longer able to accept an
incoming connection from another client computer (they use separate Common Names
and separate keys and certs).
In all of my 8 years of using OpenVPN servers on Raspberry Pi I have never seen
such a block happening between clients.

>
>And now you have four logs to inspect at --verb 4.
I guess you mean 3 logs?
- The RPi server log
- The Rpi client log
- The Windows client log


>You may have to forego dinner, in future.
>
I mentioned dinner just to indicate a pause with no activity during which the
VPN server recovered

Now I have made further tests and the failure pattern is repeatable:
- Connect one client
- Now the other clent cannot connect
- Disconnect the first client
- The second client cannot connect still
- Now the first client also cannot connect anymore
- Wait an as yet unspecified time in the range of 4-5 minutes or so
- Now either of the two clients can connect.

Concerning logs I already posted the Windows client log, but the RPi client
apparently did not log anything anywhere I could find so I had to add a
directive into the conf file to specify a log-append location.
Then all user feedback when running the connect command vanished from the
console, but afterwards I found a logfile containing a lot of message lines.

The only items I find in the server log that can mean anything is this when
trying to connect the RPi client while the Windows client is already connected:

Fri Jun  4 21:50:55 2021 us=160902 MULTI: multi_create_instance called
Fri Jun  4 21:50:55 2021 us=161247 158.174.104.130:44459 Re-using SSL/TLS
context
Fri Jun  4 21:50:55 2021 us=161341 158.174.104.130:44459 LZO compression
initializing
Fri Jun  4 21:50:55 2021 us=161776 158.174.104.130:44459 Control Channel MTU
parms [ L:1622 D:1184 EF:66 EB:0 ET:0 EL:3 ]
Fri Jun  4 21:50:55 2021 us=161878 158.174.104.130:44459 Data Channel MTU parms
[ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Fri Jun  4 21:50:55 2021 us=162128 158.174.104.130:44459 Local Options String
(VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto
UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-au$
Fri Jun  4 21:50:55 2021 us=162208 158.174.104.130:44459 Expected Remote Options
String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto
UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize $
Fri Jun  4 21:50:55 2021 us=162379 158.174.104.130:44459 TLS: Initial packet
from [AF_INET]158.174.104.130:44459, sid=99fc0e35 4c0bac25
Fri Jun  4 21:51:55 2021 us=2072 158.174.104.130:44459 TLS Error: TLS key
negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Jun  4 21:51:55 2021 us=2301 158.174.104.130:44459 TLS Error: TLS handshake
failed
Fri Jun  4 21:51:55 2021 us=2674 158.174.104.130:44459 SIGUSR1[soft,tls-error]
received, client-instance restarting


Everything looks normal up until the TLS handshake, which fails.

The previous RPi connection has this in the same position where it succeeds:

Fri Jun  4 21:50:01 2021 us=71256 MULTI: multi_create_instance called
Fri Jun  4 21:50:01 2021 us=71588 158.174.104.130:51803 Re-using SSL/TLS context
Fri Jun  4 21:50:01 2021 us=71673 158.174.104.130:51803 LZO compression
initializing
Fri Jun  4 21:50:01 2021 us=71991 158.174.104.130:51803 Control Channel MTU
parms [ L:1622 D:1184 EF:66 EB:0 ET:0 EL:3 ]
Fri Jun  4 21:50:01 2021 us=72077 158.174.104.130:51803 Data Channel MTU parms [
L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Fri Jun  4 21:50:01 2021 us=72297 158.174.104.130:51803 Local Options String
(VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto
UDPv4,comp-lzo,keydir 0,ciphe

Re: [Openvpn-users] Client-to-client setup fails mysteriously...

[Selva Nair]

Hi,

You have to post the full client and server logs  -- we need to see
the whole server log showing one connection succeeding and the
subsequent one failing. And the corresponding (i.e matching) client
logs. I want to see what routes are being set up, which port and IP
connections are coming from, what is pushed to the clients etc.  Not
snippets of logs here and there.

In the absence of that I'm out.

Selva


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Client-to-client setup fails mysteriously...

[tincantech via Openvpn-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

‐‐‐ Original Message ‐‐‐
On Friday, 4 June 2021 21:23, Bo Berglund  wrote:

> On Fri, 04 Jun 2021 19:49:36 +, tincantech via Openvpn-users
> openvpn-users@lists.sourceforge.net wrote:
>
> > > I have set up an Openvpn server on a Raspberry Pi at a remote location I 
> > > can
> > > access through another OpenVPN server.
> >
> > So: HOST:Client -> Server:HOST:Client -> Server:HOST
>
> I don't quite understand what you mean by this comment.
> What I wanted to say is that I heva two OpenVPN servers operational on the
> remote network. the origional one is what I use to access that remote network
> and I just mentioned it because I have a way to get to the remote network to
> inspect things NOT using the system I am working on now.
> But I am not connected to that VPN while doing these tests.
>

Cut to the chase ..

I meant for you to clarify your statement "access through another OpenVPN 
server".

"You have access to both server and client at all times, regardless of the 
method."

Clarity is key.

Down to business:

If your client cannot connect to your server then you MUST read the server log 
to:

* See if the client tried to connect to the server.
  Your server log will have details.

* See what errors are logged in the server log.
  No errors are logged in the client log because Openvpn server is too secure
  to give away details to the client.

If your server log does not have any record concerning the client connection 
attempt
then your client has failed to "find" your server.

Or, you have set your server log --verb setting so low that nothing is logged 
at all.

Regards
R
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJgupNKACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ0ipwgAl0lG7O6GUqR5Ck99/dsNXJkBxidn6VN8X0CrhYEiVeAfxELY
6tnyX145oRgnyYwUYOKGn/aFEqZ50fbC300KFHR3ppyJ8P4eu34G4IYoA4rf
NSLWBQIKMxMgXNorcT/eUbDKXp5JzF0j72xTOxjU1DU2Pz+V5LciEUW+dTyl
caj1UeoZ1xTlmJIcYhzz+jN+8htUsn6RMNXGoJ02lELsluP32ljrwoplPfPm
KFgN697MFIY6ddlCq+p8WH2vNaEQ2rFN4l67G7XX72qdaydmSui2F5q/Ga+h
SqKVC+2tYFFZyPHfm/b2OG6lV/gBNJ4UueXihE9qQyYL8HM5QkfZtQ==
=vLsj
-END PGP SIGNATURE-


publickey - tincantech@protonmail.com - 0x09BC3D44.asc
Description: application/pgp-keys


publickey - tincantech@protonmail.com - 0x09BC3D44.asc.sig
Description: PGP signature
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Client-to-client setup fails mysteriously...

[Bo Berglund]

On Fri, 04 Jun 2021 20:55:40 +, tincantech via Openvpn-users
 wrote:

>If your client cannot connect to your server then you MUST read the server log 
>to:
>
>* See if the client tried to connect to the server.
>  Your server log will have details.
>
>* See what errors are logged in the server log.
>  No errors are logged in the client log because Openvpn server is too secure
>  to give away details to the client.

I have posted a reply containing the logs from all involved places, but then I
got a postmaster message saying the post must be reviewed by a moderator because
it is too big
(That is really why I did not post full logs earlier)
I am using a News reader to interact with this list via Gmane so that can also
play into it.


-- 
Bo Berglund
Developer in Sweden



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Client-to-client setup fails mysteriously... (0/1)

[Bo Berglund]

On Fri, 04 Jun 2021 20:55:40 +, tincantech via Openvpn-users
 wrote:

>Down to business:
>
>If your client cannot connect to your server then you MUST read the server log 
>to:
>
>* See if the client tried to connect to the server.
>  Your server log will have details.
>
>* See what errors are logged in the server log.
>  No errors are logged in the client log because Openvpn server is too secure
>  to give away details to the client.
>
>If your server log does not have any record concerning the client connection 
>attempt
>then your client has failed to "find" your server.
Of course it has, I have already written about the TLS errors...

>
>
REPEAT post
since my previous attempt was blocked due to excessive size...

Now I have performed the following:
- Stopped the VPN services on the test server
- Made sure that verb 4 is in effect in the server conf file
- Changed logging from log-append to just log so old stuff is erased
- Started the tunnel-only service on the test server at 00:24:10

Next on the RPI client:
- verified that verb 4 is in the client conf file
- Connected successfully to the server (at 00:25:53)

Then on the Windows 10 client:
- verified verb 4 also here
- Started a connection attempt at 00:27:03
- Noted that (as expected) the connection failed, showing TLS error after 60s
- Disconnected the client connection attempts at 00:28:30

Finally on the RPi client:
- Disconnected (using Ctrl-C in the terminal) VPN at 00:29:00
- Retrieved the client log file

Then retrieved the logs as follows (long post...):

-
Now trying to attach compressed logfiles rather than adding the text right
here...


-- 
Bo Berglund
Developer in Sweden



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Client-to-client setup fails mysteriously... (1/1)

[Bo Berglund]

begin 644 RPi-server-log.7z
M-WJ\KR<<``3=1#=)"1,```!B`/^RT63@=N83`5T`*9A*@@'C
MY")L^"OG((P/&B_W<_J3+)RW]SV[`?R4TB(/$,BT'_\ZJ-@FJ$K;IJ'&JA=_
MCK8S@,=GUP1G%W4$0,07O#S?&U)TE._ZLHT-8-^^.?0GXLY>O7>>O6G@CPC=
MJ[[V0RUH.&R@URF;D/P>II]JLQM/VS6_P/#L2%?_"[.2,+&=L8XMS>YN,+0N
MISHDFX:7C\SPTW2=(3WZ^Q^)+'=JVP_N&RFB.9U/R$*6.9L711?N*:2V3=::
MC^<6*-E!1&BP!`3#3),:>:1/&?N0/I-%#VQ_8,L5;^E]1;KDOR#\=,P4Y#:#
M/<@*4RDN0@T+5B>R*W8,0D3MG5.&:G3R9CP)8AH+P/"B!'T`NSTZH!&&]9?(
M0!:7'00RC&D$0P_DH;YF.U-!?!%Q##6-"UQV1A`!#']5!YBGG@1<*X>!"LU^
M&SE[^^[_ACN1-,Z!JXXT\)R]^CAAF#PAY)UQ?V8^S6RXUITN
M)1-5W2)38=KUA#EY7X':`(.#0D1`I^2G89B_&>M;NG-(!L@1T9YJ)FODIY4K
MDQ\4QAFI&IE@+OWH:T5G;3124A*_KO2[;Z5"H#B8_I":NW+GA`D"2?4@(J&?
ML%8**/^0D93.;B&VIF#D3@[03H8Z#QQ55\VR@55U?]5VQ9Q!EBI[C3JAK[Z[
MW*!]F0X:1%!Z^N]W'Y$9Z[-'W7NF+*A+*`+=*4;N-/>*G(NB2(>E
MLXN6OK/XP@:S)F)?F+ZX@,>W:/W_"TWY4&$]8_Q;7U*LVJUN4;;P8`:R#JQ!UYKA!+F'>V]K?_0Y"@O
M)1G4`XLM.HI&44:$W>GUOEF@`U86:#B+`7RZSAUAI=VSHRQ!)I"YB^&$F4U+CMVT_CL9_+4^?IWD"\;5(C-\`!Y@G:F.9F&HF3O6^$"85-P]'E@*]S;:1XA@Z,=^!$X=!'>L'+LHL5]^&32ZQ*AV+-(#:
MDM(L;;&#FA^:'H.OE8HRTK$A&]GHJOKF)D/^(PTDKW=0F&
M5SN&)DDR+A"I*1@.DLF'H5<7\Y7J\)&?%XRLFK$M?TLO6^(&_4QCN>T)7!CK
M+.6]A'YT"?:SY?EYU*VAF%)C6(;0>WE\$(3K%5`VG\.7\XH6,DW=-&B<5(!E
M\U@*A2K32R:/'L)!7H!F"=_'&7[$D2%;C!IR4]>-*WV6&&1Z9B-SM#2KQG#2
M\9L9H/NV()B51<'3L/H.LA5_N&^=U2[Y+1BX&\T,!VF%%_Z8/K;)#LUT\K0V
M(T6PJ6VE=I:)&G7#9';7\:!!I6J@U*Z7V-H6KFK4UGRSWS1.]&0UYAW>Q?54
MIZ94D=TZ<_O-MDYT/=O4'),]:/4S^M59E=(APD%Z5F-\?&8BO^>>H<_I`OHF
M@ZA'99SAJUA))%[A4-I!_;Q:&8//1!6R?E@1[!57\L+1
M,VA%%?ZA@64,WS_$>6;ILLD-2K@L[VXKVRSZU@24"7=]H&K9^H;_5J;]DF4*
MR`_S_\98=#G.,M(GM"'7408J4V(K,+D`,Z2AYD\@*>4%D`Y#`&.1`R+#H4PA
M,(:>;3D()+:]=UK8N'OKQ3&GFP010$B+&WRG?`1)QC2];IG
MP(!@%_U9L<_<@+0P+'+NO23`VU#<7._5'IF+RX4"@3U?B5_G?O!M'
MY0S\Z0$CA;W!:"UB\I.8*GV48']02.`W@6&U%"S#.U?(1"
MO!"\RQ)A.201<69.O=L'3>F8YU.P@X,;#[G)#ZO]%?*$ZR,['.+756P;MK^L
M:0//W&DP)5X/4YB16BMH"SD-*,XG!_\&&>UKROH-*XP^J!@2^/X:ZAJ^BMJ.
M?"(<@"X8LN4F<38"FL(F<9P.+,/-8\QS*,:82S,NU4
ME1%Y`=,Q#_D\"KDW!SK$.VV^,G-^Z@5'>*W)Q'C2L-B)$)V&I[BWQD$8K1TGJZ@+B):UAIB<1,T
M-NJ#C<)DNFTIP=1+].B/&F+MLX,',C?Y/!+%'.IF1IF=]6O[S!WS;V;F-1M*
MGT:\+S%42&>4KR*!&Z&=7YATHCR5??EU2?;@"4B/O97Q33-3$IW>>9?(9B.S
MX],^9V0[3,@"L#$62)N:;\B21G`,RKU1"V.S1"JFMS:,4/QFM1L#+`\%CQY3
MN1BTO),RN08B,"3KT4BO>?KTL
MB4^C8J(CS)!35AP/7F+?^6J/UVO[.<`*-]1@+@1IYNG"10GV]62V-(B(&YNX
MMD>T!VA"+%SG:-1)^I'WY0"14QG$?J&A$*ZH<\C&_07)D.?OV5HEIK\YW,1X
MWW*15?E*JE,Z$4K5(V.%@Q[Z/M;YQ.:<"(%/,BKUE([9,(<&9C
M\ED](R29U?]3E<6A8-.M-<9@8[;C5IR=L#`T?=I&G.H*];42;P.:Y@V%?5IC?H3]%Z.'!N[5"KE\C
MF&7)8YE+PTRC2EN:P-X!4
M9<9&L-`,2`UQ+Q%^:5RQNX6LG[#UPL_W_APLT-0WY<3F6,"+EJN3VPRP2?9V"A'.LGOC
M5R_EQ8S@_6=:HAVAORX2=/7^<>">]3S%\T;/[*PXD"&UY5UDP!OO@'-::CC?
M0)5!)4W--;K-R\U4/N`+GT,>X]@?@YG@%WR&0OK+>I@#L_NLMEZ!!"2F(A;PN\7(Q.39N"WOD^6%XU_>X27$/<[,VX:4=C?]#[\6#`1W==G*7]8
M>\DB;&R;P*PK76\Y[X9?"0FG1PB/SPB"B?"
M8@Z%^Z;V7K^_,:VT`TY)P&WY=443KB_3.);&.WBW->$HA:&Q"45*+Z*X%%7$
MP]?A(9AAE_D[!?5BX8X,%DMKO,#O@BRKR<\P0,-;#R]$N'-?D[X_8(U`RSX[
M<,R7P+U$PJ5"MW!69=C+:"W<]G>]6?>`T6`&ANV`V8<)T*W_$]&`#TG['UE;
MV="/%WNH^@H).?;$@'JF-K3"%AIUU59,P.:G!)&I?41J1*V/HKJM?@6B.O6&
M\T?&EU9*-VW5*9^OO$59/^6[!5QKZP;;R/ZVNKM)UODF#-AW'@-+DFI_/J&6
M7!J;S.$`=K6$QC$?1EP%4^GLH7?[C<1KB7#T+ALI\M-@V62@.[FW>Q,
MT?T^1UUU6IE_=Q.)D%VS,+0)V.:*4A2+^EYS/2X[18-]W4,:&GV'\Z;M.K;^
MY^Z5V7,I0<9+'VB404\8IM+$_.%TQET!T:`-",E#=-*\134AG.H5RUP^/!66
M=)?L=,>-6JH*U[1K,)8^Q&?`0VR$5R/[-!&TKWX9
MNTE?$:@LDU?/,36S''LS91^CO"N$*Y,M*K8:S9'&;
MS[/O:A9?[C9AZ8NASD47_S;JSP:AT$+8&KB@T@72_T&26ND2F,VJ*W=.L
MC8";M1PDK,B^[F,U?PF-.5<=$06+4^T@DKB_\OVD:&YLML9NA,T="YSCAD
M%1J;+A_E6T+(<*I:VN(%>[R;44C='+Q/XT@I\NJ"@=$)ATW+0=^MEU8`&>>%6Q+:,?)0CO;RZ:XM$:AR"V;!2S7(V=9-:Z#GY
MY;T@$J/B8[1H:K?"5',B(`.8KN*2ZW1G`[A$:`7L!76E-5
MXWL6>.3:6<5J:,C)JI@#@M0X)*\9`10+!>L,I!T4O(X!])P"IA;5Z?I+K;8Q
ME2!KZB7??S+G8F/99F]"E#]&-81B$WV+=9C9+8PC4`H&+=,I'A#.F"L]6U+(
M6/!693DPTHG,CY8D-_#./8+QV3
M)?C;'M]$R@9)RL^'S<-G$%*O4+Q8NZY;D]0J;AH`%/57(UT)%4
MEJ$QG_M21!$M3VFGS,+W*_/\5=ZYFK25//Q)J]N&`T,%\5;O\`!ZZCY;AW)/
MSV2OFC"8R`S/>9JKU&LL@L'Y%[0*$?YO$E+,NZK1A8101/&W5%=E.=Q@3'19
MF)!4JJ`4@W'UD;+)F3H#?34HGMI,CTMVX"X5'#FCES;X`N0%Y/I4NQ%^8C+`
MAO01_1BJJSL9>\,L/2=#CG*.Z*K(*9-M-=@/P.&65C?X=9"*M?]5]>_3?R
MG,\;\40V?SO\WQ,^X_=4)@-.V=$.O"PZB09L^\%_IVT3HSB?E])0(2A<1R)Y
M^51J#:/SB2+4PW;90WJ.L*K^,#&Y=WZLK_#LLT2>%X3C/.2H`.R?/'/D`
M`00&``$)DPD`!PL!``$A(0$&#,#G=@`("@$D#VWC```%`1D)
M$1T`;P!V`'``;@!?`'0`=0!N`#$`+@!L`&\`9P```!0*`0``;4)HDEG7`14&
(`0`@
`
end

begin 644 Windows-client-log.7z
M-WJ\KR<<``2?,S*WZ04```""`"A3EH'@&"8%X5T`*YI)QEBY
M](FQ0%V!A>C`]<,JS#F1#B*;_C`=]C%:FA%K]&.@2U`'>""M=#FG4LA/!'JZ
MRB.8XY#;'$[>@%D/Y3__TRIJW8`YNXQRHOQ)"Z>UG+\1"V/'K;_"L[DT1;@;
M+P,Q48W;L<&M#;Z))%OE#R2X8<`C3#2=$X&9NN?PS1YX]H@/HC;.WYE`L$C3*KH*JV
M_4MQ8WV:WOUR"L3^00==T&,=<'+Z%/E.T&,E,G_4BRK`^L[R<99?XY^A[L6G
M"6VY519`-V0I&Y+F`B96Q-%L.D0KN&)Z?09+XAZ']&S%J/.O#)%X)8(,X4G7
M%?KEET^=_D#N.YF?S5'2A,U?K\7+BX^''J58K1A@@*7$?`GNH;?D(9`'.V"V$[
M5X/X2_:6O1YLU0:SN(7...@qay.vco&@L_.&
M04YI73UWM+GZ?0BN522W6@O\!+#B:G;KHH4W'HC1'3@'.1B(TH?X\RRGW(*O
M3_3]3-4H'+#Z(=0&%CT^&K)L)78EKQB-H?#]5N@O/]_#\P5B*)/%
M

Re: [Openvpn-users] Client-to-client setup fails mysteriously... (1/1)

[Selva Nair]

Hi,

You can share large logs using some service like pastebin in pure text
format. Compressed logs are hard to look through.

As per the logs the server gets the initial TLS packet from the second
client, but hears nothing after that. The client gets nothing back
from the server. So something is blocking the return path from the
server.

Does your server have multiple interfaces? If yes, you will need to
add --multihome. Though the error in this case should be more random
than the systematic failure of the second connection. Otherwise try to
see what's going on the routers on both ends.

Do you know which client is triggering the HMAC error at the end of
the server log? This may be unrelated, though.



Selva

On Fri, Jun 4, 2021 at 7:26 PM Bo Berglund  wrote:
>
>
>
>
>
>
>
> ___
> Openvpn-users mailing list
> Openvpn-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-users


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users