Hi Tobias,
Thank you for your reply.
If the case you mentioned has been fixed in 5.2.1,
the version 5.6.2 that I am running shoud have the fix.
And the symptom could be reproduced 100% even only initiate 5 tunnels.
What I concern about is that if there are only 5 users configured in
On 2018-02-27 Tobias Brunner wrote:
> Hi Trevor,
>
> > Is PLUTO_XAUTH_ID (as passed to a user-defined updown script) 100%
>
> Yes, it's trustworthy. While the client can send an arbitrary value,
> it has to match an identity in the certificate (either the subject DN
> or a SAN).
That's great
Hi Harald,
> I had hoped that putting the whole chain into
> /etc/ipsec.d/certs/mycert.pem
> would help, but apparently it doesn't.
strongSwan reads only the first certificate from PEM encoded files. So
put them in separate files.
>>>
>>> This is unusual, is it?
Hi Tobias,
On 02/26/18 09:28, Tobias Brunner wrote:
Hi Harri,
I had hoped that putting the whole chain into /etc/ipsec.d/certs/mycert.pem
would help, but apparently it doesn't.
strongSwan reads only the first certificate from PEM encoded files. So
put them in separate files.
This is
Hi Trevor,
> Is PLUTO_XAUTH_ID (as passed to a user-defined updown script) 100%
> trustworthy in an ikev2 / eap-tls / user certs connection scenario?
> What I mean by that, is can it be selected, set, or spoofed by the
> client?
Yes, it's trustworthy. While the client can send an arbitrary
Hi,
> I am facing a problem of load-tester that "%d" of initiator_id didnot
> start from 1, but from 2.
Yes, that's the case since 5.2.0 (since [1] to be exact). I pushed a
fix to the load-tester-id branch. Is that really a problem, though?
Regards,
Tobias
[1]
Is PLUTO_XAUTH_ID (as passed to a user-defined updown script) 100%
trustworthy in an ikev2 / eap-tls / user certs connection scenario?
What I mean by that, is can it be selected, set, or spoofed by the
client?
What I'm hoping is PLUTO_XAUTH_ID (or some other updown variable)
contains the CN or
