Re: iked choosing the wrong policy?
On Tue, Jul 27, 2021 at 11:18:53AM +0200, Patrick Wildt wrote: > On Tue, Jul 27, 2021 at 09:55:34AM +0200, Claudio Jeker wrote: > > On Tue, Jul 27, 2021 at 07:32:09AM -, Stuart Henderson wrote: > > > On 2021-07-27, Vladimir Nikishkin wrote: > > > > Hello, everyone. > > > > > > > > This is my iked.conf: > > > > > > > > ``` > > > > ikev2 "for-phone" passive esp \ > > > > from any to 10.0.3.2/32 \ > > > > local egress peer any \ > > > ... > > > > dstid phone.mine \ > > > > > > > ikev2 "for-laptop" passive esp \ > > > > from any to 10.0.3.3/32 \ > > > > local egress peer any \ > > > ... > > > > dstid laptop.mine \ > > > > > > Two policies with "peer any" doesn't work. > > > > > > > How to correct the setup? > > > > > > Maybe it's possible by modifying the code, I'm not sure if the > > > id is sent early enough though so it might not be possible. > > > > This is one of the biggest annoyances of iked. It does not even help to > > use different IPs and 'local' to split up the rules. Would love if someone > > would fix this. > > Using differnt IPs for local should work. The trouble is not in iked, > but in the IKEv2 protocol. The IDs are only shared in the second part > of the handshake. So until then, there's no way for the daemon to find > the correct policy, apart from looking at local or peer address. > > That's why the settings for the IKE-SA should be similar across all > policies thate could be valid, and the Child-SA can then (afaik) have > different settings. > > But still, using different IPs for local should work in -current. > The protocol is tricky but this SHOULD work as long as the policies use different dstids and it does so in my tests. I am not sure what exactly causes it to fail in this particular setup. Some more info such as a verbose log of the handshake and the OpenBSD version would be helpful to figure out what's wrong.
Re: iked choosing the wrong policy?
On Tue, Jul 27, 2021 at 09:55:34AM +0200, Claudio Jeker wrote: > On Tue, Jul 27, 2021 at 07:32:09AM -, Stuart Henderson wrote: > > On 2021-07-27, Vladimir Nikishkin wrote: > > > Hello, everyone. > > > > > > This is my iked.conf: > > > > > > ``` > > > ikev2 "for-phone" passive esp \ > > > from any to 10.0.3.2/32 \ > > > local egress peer any \ > > ... > > > dstid phone.mine \ > > > > > ikev2 "for-laptop" passive esp \ > > > from any to 10.0.3.3/32 \ > > > local egress peer any \ > > ... > > > dstid laptop.mine \ > > > > Two policies with "peer any" doesn't work. > > > > > How to correct the setup? > > > > Maybe it's possible by modifying the code, I'm not sure if the > > id is sent early enough though so it might not be possible. > > This is one of the biggest annoyances of iked. It does not even help to > use different IPs and 'local' to split up the rules. Would love if someone > would fix this. Using differnt IPs for local should work. The trouble is not in iked, but in the IKEv2 protocol. The IDs are only shared in the second part of the handshake. So until then, there's no way for the daemon to find the correct policy, apart from looking at local or peer address. That's why the settings for the IKE-SA should be similar across all policies thate could be valid, and the Child-SA can then (afaik) have different settings. But still, using different IPs for local should work in -current.
Re: iked choosing the wrong policy?
On Tue, Jul 27, 2021 at 07:32:09AM -, Stuart Henderson wrote: > On 2021-07-27, Vladimir Nikishkin wrote: > > Hello, everyone. > > > > This is my iked.conf: > > > > ``` > > ikev2 "for-phone" passive esp \ > > from any to 10.0.3.2/32 \ > > local egress peer any \ > ... > > dstid phone.mine \ > > > ikev2 "for-laptop" passive esp \ > > from any to 10.0.3.3/32 \ > > local egress peer any \ > ... > > dstid laptop.mine \ > > Two policies with "peer any" doesn't work. > > > How to correct the setup? > > Maybe it's possible by modifying the code, I'm not sure if the > id is sent early enough though so it might not be possible. This is one of the biggest annoyances of iked. It does not even help to use different IPs and 'local' to split up the rules. Would love if someone would fix this. -- :wq Claudio
Re: iked choosing the wrong policy?
On 2021-07-27, Vladimir Nikishkin wrote: > Hello, everyone. > > This is my iked.conf: > > ``` > ikev2 "for-phone" passive esp \ > from any to 10.0.3.2/32 \ > local egress peer any \ ... > dstid phone.mine \ > ikev2 "for-laptop" passive esp \ > from any to 10.0.3.3/32 \ > local egress peer any \ ... > dstid laptop.mine \ Two policies with "peer any" doesn't work. > How to correct the setup? Maybe it's possible by modifying the code, I'm not sure if the id is sent early enough though so it might not be possible.
iked choosing the wrong policy?
Hello, everyone. This is my iked.conf: ``` ikev2 "for-phone" passive esp \ from any to 10.0.3.2/32 \ local egress peer any \ ikesa enc aes-256 prf hmac-sha2-256 auth hmac-sha2-256 group ecp256 \ childsa enc aes-256 auth hmac-sha2-256 prf hmac-sha2-256 group ecp256 \ srcid server.mine \ dstid phone.mine \ eap "mschap-v2" \ config address 10.0.3.2 \ config name-server 10.0.0.1 \ config netmask 255.255.255.255 \ config protected-subnet 10.0.0.0/24 \ config protected-subnet 10.0.1.0/24 \ config protected-subnet 10.0.2.0/24 \ tag "ROADW" ikev2 "for-laptop" passive esp \ from any to 10.0.3.3/32 \ local egress peer any \ ikesa enc aes-256 auth hmac-sha2-512 prf hmac-sha2-512 group ecp521 \ childsa enc aes-256 auth hmac-sha2-512 group ecp521 \ srcid server.mine \ dstid laptop.mine \ rsa \ config address 10.0.3.3 \ config name-server 10.0.0.1 \ config netmask 255.255.255.255 \ config protected-subnet 10.0.0.0/24 \ config protected-subnet 10.0.1.0/24 \ config protected-subnet 10.0.2.0/24 \ tag "ROADW" ``` I expected the peer presenting itself as "phone.mine" get the first policy (as long as it manages to authenticate by mschapv2), and the peer presenting itself as "laptop.mine" to get the second policy. However, what happens in reality is that both of them are being given the second policy, and the phone fails to authenticate. If I comment out the second policy, the phone successfully gets the first policy and authenticates itself, but, obviously, the laptop does not work then. How to correct the setup? -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop)
