Hi Martin,
you've been a great help. Thanks a lot. I've been looking in all the
wrong places all the time. I was in deed using the IKEv2 identity from
the client which doesn't match any fields in the clients certificate in
my case. Sadly I don't know how to change the client's IKEv2 identity
Hi Mugur,
need to support with strongSwan an exotic cipher implemented both by
the NPU and the remote system.
Adding a new ESP cipher is possible, but not straight forward. You'll
need to add support in several layers:
- First, of course, the kernel needs support for this algorithm in the
Hi Andreas,
I don't know how to change the client's IKEv2 identity cause the
clients are Windows 7 not StrongSWAN clients.
You can't, Windows always uses the local IP as the IKEv2 identity. There
have been rumors that Service Pack 1 brings additional identity options,
but I haven't seen
Hi Martin,
Adding a new ESP cipher is possible, but not straight forward.
You'll need to add support in several layers:
1) First, of course, the kernel needs support for this algorithm
in the crypto API
2) The kernel needs support for the new algorithm in the XFRM
subsystem.
3)
any one can help me? thanks
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
The IP data flow is not IPsec-ed by Linux but by an external NPU.
I see. I assume you're using our PF_KEY kernel interface plugin, then.
Then, probably only the items 3) and 4) from your list are required.
You'll need 5), too. Your NPU probably provides a PF_KEY algorithm
identifier (such as
