Hello Stephen,
installpolicy=no just means the the IKEv2 charon daemon does not
use the add_policy() and del_policy() methods of the kernel interface
to actively manage the IPsec policies but delegates these tasks to
another process on the same host. charon still uses the query_policy()
method to
Sushil Chaudhari wrote:
> Hi,
>
> I am new to strongswan. Whenever i am trying to make the data transfer
> between the two hosts, the log files says that:
>
> "unable to locate my private key for RSA Signature" and "sending encrypted
> notification authentication Failed"
> can anybody tell me w
Hi,
I am new to strongswan. Whenever i am trying to make the data transfer between
the two hosts, the log files says that:
"unable to locate my private key for RSA Signature" and "sending encrypted
notification authentication Failed"
can anybody tell me what might be the problem??
Do self sige
Hi,
I am new to strongswan. Whenever i am trying to make the data transfer between
the two hosts, the log files says that:
"unable to locate my private key for RSA Signature" and "sending encrypted
notification authentication Failed"
can anybody tell me what might be the problem??
Do self sige
A follow-up to Mugur's question...
It appears that the "SA activity" portion of the peer liveness algorithm
uses a GETPOLICY operation to retrieve the policy use_time. So, I figure
with installpolicy=no, this would essentially disable the "SA activity"
portion of the liveness check. Is that cor
Hello,
attached is a small patch to improve one DPD error message
which occured when we debugged an obscure setup:
Multiple tunnels to the same fixed IP address endpoint using
a different x.509 key for phase 1, DPD went crazy sometimes.
Now all tunnels to the same fixed IP address share one x.509
