theblo...@gmail.com writes: > Thank you for your help!
No problem! > I’ve been meaning to use the patch but I still hadn’t the time to test > it. I will probably do it in the future and report back with problems > if I get them. Either way I’ll be watching out for news about this. I plan to stay active on this topic, so watch that tech@ thread for more details. >> On 19/06/2017, at 05:07, Tim Stewart <t...@stoo.org> wrote: >> >> theblo...@gmail.com writes: >> >>> Hello, >>> >>> I’ve been trying to create an IPSec VPN in my OpenBSD computer and >>> every time I connect my Android phone (running StrongSWAN) to the >>> server I get the following errors in the logs (running iked -dvvv): >>> >>>> ikev2_sa_responder_dh: invalid dh, size 4096 >>>> ikev2_resp_recv: failed to get IKE SA keys >> >> The problem is that iked(8) does not know how to perform Diffie-Hellman >> group negotiation. I have an incomplete fix for this issue: >> >> https://marc.info/?l=openbsd-tech&m=149499865830823 >> >> You can try the patch in that thread and see if it allows you to >> complete negotiation. The first patch is probably better, but I think >> it breaks rekeying of child SAs. I failed to mention that the referenced patch was motivated specifically by strongSwan support. On Android, strongSwan uses ECP_256 in its initial IKE_SA_INIT request which is different than the policy I had at the time, so I attempted to add negotiation support (it worked). >> I'm working on a better fix right now. I hope to have something more >> correct to submit to the above thread this week. >> >>> My iked.conf is: >>> >>>> ikev2 "base" from any to any \ >>>> peer any \ >>>> ikesa enc aes-256 auth hmac-sha2-512 group modp4096 \ >>>> childsa enc aes-256 auth hmac-sha2-512 group modp4096 \ >>>> config address 192.168.2.0/24 \ >>>> config name-server 192.168.1.254 \ >>>> config access-server 192.168.1.254 >>> >>> I’m using 4096 keys and modp4096 but AFAIK both the server and the >>> cliente support them. I’m not sure where to start troubleshooting the >>> problem and could use some help. Instead of the patch, you could also try specifying "group ecp256" within the ikesa line above. In theory this removes the needs for DH group negotiation. Strangely, I don't remember if I tried this before. >>> Thanks in advance. >> >> I don't see anything obviously wrong here. -- Tim Stewart ----------- Mail: t...@stoo.org Matrix: @tim:stoo.org
