Hello!
I run OpenVPN 2.2.1 server.
And there are clients connected by mobile links, so they are not stable.
Connections are over udp.
On connect route add script is executed, on disconnect- route del.
As you see, route del was executed, but no route add.
Sep 4 12:45:19 inetgw1
Hello!
May be this is faq, but I can't find any info which explains what I need
to do in step-by-step manner what I need to do in case of CA expiration.
I generated CA about 8.5 years ago for 10 years (default value), so I'll
face CA expiration soon enough.
I have ca.key and ca.crt, as I
09.04.2014 17:55, Timothe Litt пишет:
Yes, thank you, this is good theoretical explanation.
All I need now are practical examples :-)
I understand that can be like reading mans for me for far more
expirienced... :-( Hope somebody already implemented this and can
share...
That *was*
, this - event_wait : Interrupted
system call (code=4) - is from openvpn stop.
centos 6 again, don't remember the same client , or not.
may be there is some option to limit system calls waiting?
Thank you!
15.07.2016 13:04, Dmitry Melekhov пишет:
> Hello!
>
> This night one of co
Hello!
This night one of connections was not able to reconnect , last message
in log is:
Peer Connection Initiated with
and this is all, openvpn process was running, though.
On server side I see:
SENT CONTROL
TLS Error: TLS key negotiation failed to occur within 60 seconds (check
your
15.07.2016 16:40, Gert Doering пишет:
> Hi,
>
> On Fri, Jul 15, 2016 at 01:04:12PM +0400, Dmitry Melekhov wrote:
>> This night one of connections was not able to reconnect , last message
>> in log is:
>>
>> Peer Connection Initiated with
>>
>> and thi
Hello!
Unfortunately, some of our points still uses blowfish, but we can't
change cipher on all of them once,
so we decided to upgrade servers to 2.4.0 and then , one by one, change
client's ciphers.
Don't know why, but I decided to set default cipher on server to
AES-256-CBC ,
and
24.01.2017 15:43, Gert Doering пишет:
> Hi,
>
> On Tue, Jan 24, 2017 at 02:51:48PM +0400, Dmitry Melekhov wrote:
>> Unfortunately, some of our points still uses blowfish, but we can't
>> change cipher on all of them once,
>>
>> so we decided to upgrade serve
24.01.2017 16:55, Gert Doering пишет:
> Hi,
>
> On Tue, Jan 24, 2017 at 04:45:52PM +0400, Dmitry Melekhov wrote:
>> 24.01.2017 16:31, Gert Doering ??:
>>> Well. If you *know* which of the old clients have been upgraded to AES,
>>> you should be able to put
24.01.2017 16:31, Gert Doering пишет:
> Hi,
>
> On Tue, Jan 24, 2017 at 04:09:29PM +0400, Dmitry Melekhov wrote:
>>>> and found that servers successfully uses blowfish for some old clients,
>>>> but for others not:
>>> It depends on whether
26.01.2017 15:31, debbie10t пишет:
>
> On 26/01/17 07:10, Dmitry Melekhov wrote:
>> 26.01.2017 10:59, Gert Doering пишет:
>>> Hi,
>>>
>>> On Thu, Jan 26, 2017 at 09:54:59AM +0400, Dmitry Melekhov wrote:
>>>> Could you tell me is this expected
26.01.2017 16:43, debbie10t пишет:
>
> On 26/01/17 11:55, Dmitry Melekhov wrote:
>> 26.01.2017 15:31, debbie10t пишет:
>>> On 26/01/17 07:10, Dmitry Melekhov wrote:
>>>> 26.01.2017 10:59, Gert Doering пишет:
>>>>> Hi,
>>>>>
>&g
26.01.2017 10:59, Gert Doering пишет:
> Hi,
>
> On Thu, Jan 26, 2017 at 09:54:59AM +0400, Dmitry Melekhov wrote:
>> Could you tell me is this expected behavior and, if yes, is there any
>> workaround , something like dhcp-release for windows?
> This is a bug - on SIGUSR1
Hello!
We run two openvpn servers, one of them has network 192.168.205.0/24 on
tun and another has 192.168.206.0/24 on tun.
These servers are behind NAT.
Yesterday I rebooted NAT devices, after this we hit problem.
We have Centos 6 client, which runs openvpn 2.4.0 too.
Before NAT device
Hello!
Just installed 2.4 on windows 7.
Connecting to on server, tun is set to, let's say to 10.1.10.6,
everything is fine.
Disconnect.
Change remote in config, connect to another server,
tun address should be 192.168.31.6, gui says so,
but real address on tun is 10.1.10.6.
Reboot solves
Hello!
Just wrote on 2.4.1 server
ncp-ciphers AES-256-CBC:AES-256-GCM:AES-128-GCM
by mistake and then can not connect using 2.4.1 client,
because server pushed AES-256-CBC to client and it is not in ncp-ciphers
default client list.
Yes, this is documented:
"For servers, the first cipher
14.04.2017 23:34, Gert Doering пишет:
> Hi,
>
> On Fri, Apr 14, 2017 at 11:25:04PM +0400, Dmitry Melekhov wrote:
>> I guess negotiation is choosing cipher from both sides list...
> Not today.
>
> It is what is documented today: choose the first cipher in the cip
17 matches
Mail list logo
