Re: [OpenIKED] Is it impossible to differentiate the policies by dstid?

2018-11-07 Thread Claudio Jeker
On Tue, Nov 06, 2018 at 05:42:08PM -0500, Daniel Ouellet wrote:
> The source ID does default yes, but I have a tunnel gateway for multiple
> VPN and I HAD to specify the dstid on the passive side as well or ONLY
> the last rule was picked up for the 0.0.0.0/0 of some of them as an
> example for all the traffic flowing via the VPN.
> 
> Any overlapping routes where not going as one might think if not dstid
> specified.
> 
> example:
> 
> ikev2 "test1-flow" passive from 0.0.0.0/0 to 1.2.3.4/28 peer any dstid
> test1.example.com
> 
> ikev2 "test2-flow" passive from 0.0.0.0/0 to 1.3.3.4/28 peer any dstid
> test2.example.com
> 
> ikev2 "test3-flow" passive from 0.0.0.0/0 to 1.4.3.4/28 peer any dstid
> test3.example.com
> 
> ..etc
> 
> If no dstid was specified, then you didn't have all 3 above as an
> example working.
> 
> May be it is suppose to, that I can't say for sure as the idea of it,
> but it sure wasn't and isn't if I remove the dstid with everything else
> staying the same.
> 
> So what he suggested to you was valid and true.
> 
> But it is your setup and you sure can do as you see fit.

This only works if the rules are the same. The problem is that part of the
lookups during the handshake are done without dstid and so at start the
last rule will match and is used but later on the real rule (with correct
dstid) matches. In general you can not mix different auth types because
the missmatch happens during auth exchange. Fixing this is not trivial and
maybe not even possible.

> On 11/6/18 3:16 PM, 雷致强 wrote:
> > Thanks for the input, however, I think srcid defaults to the hostname when 
> > it’s omitted. Explicitly setting it didn’t give me any luck.
> > 
> >> On Nov 7, 2018, at 2:33 AM, J Evans <3...@startmail.com> wrote:
> >>
> >> I am by no means an expert, but for my setup, in order to get multiple 
> >> policies working, I had to specify both srcid and dstid for each policy on 
> >> the passive peer. And then I set srcid and dstid for the policies on the 
> >> active peers.
> >>
> > 

-- 
:wq Claudio



Re: [OpenIKED] Is it impossible to differentiate the policies by dstid?

2018-11-06 Thread Daniel Ouellet
The source ID does default yes, but I have a tunnel gateway for multiple
VPN and I HAD to specify the dstid on the passive side as well or ONLY
the last rule was picked up for the 0.0.0.0/0 of some of them as an
example for all the traffic flowing via the VPN.

Any overlapping routes where not going as one might think if not dstid
specified.

example:

ikev2 "test1-flow" passive from 0.0.0.0/0 to 1.2.3.4/28 peer any dstid
test1.example.com

ikev2 "test2-flow" passive from 0.0.0.0/0 to 1.3.3.4/28 peer any dstid
test2.example.com

ikev2 "test3-flow" passive from 0.0.0.0/0 to 1.4.3.4/28 peer any dstid
test3.example.com

..etc

If no dstid was specified, then you didn't have all 3 above as an
example working.

May be it is suppose to, that I can't say for sure as the idea of it,
but it sure wasn't and isn't if I remove the dstid with everything else
staying the same.

So what he suggested to you was valid and true.

But it is your setup and you sure can do as you see fit.

Hope this help anyway.

Daniel

On 11/6/18 3:16 PM, 雷致强 wrote:
> Thanks for the input, however, I think srcid defaults to the hostname when 
> it’s omitted. Explicitly setting it didn’t give me any luck.
> 
>> On Nov 7, 2018, at 2:33 AM, J Evans <3...@startmail.com> wrote:
>>
>> I am by no means an expert, but for my setup, in order to get multiple 
>> policies working, I had to specify both srcid and dstid for each policy on 
>> the passive peer. And then I set srcid and dstid for the policies on the 
>> active peers.
>>
> 



Re: [OpenIKED] Is it impossible to differentiate the policies by dstid?

2018-11-06 Thread 雷致强
Thanks for the input, however, I think srcid defaults to the hostname when it’s 
omitted. Explicitly setting it didn’t give me any luck.

> On Nov 7, 2018, at 2:33 AM, J Evans <3...@startmail.com> wrote:
> 
> I am by no means an expert, but for my setup, in order to get multiple 
> policies working, I had to specify both srcid and dstid for each policy on 
> the passive peer. And then I set srcid and dstid for the policies on the 
> active peers.
> 



Re: [OpenIKED] Is it impossible to differentiate the policies by dstid?

2018-11-06 Thread J Evans
I am by no means an expert, but for my setup, in order to get multiple 
policies working, I had to specify both srcid and dstid for each policy 
on the passive peer. And then I set srcid and dstid for the policies on 
the active peers.




Re: [OpenIKED] Is it impossible to differentiate the policies by dstid?

2018-11-05 Thread 雷致强
All incoming connections go to “redheart” policy. “blackjack” users cannot 
connect. I’m using 6.4.

# iked -dv  
set_policy: could not find pubkey for /etc/iked/pubkeys/fqdn/blackjack.local
ikev2 "blackjack" passive esp inet from 0.0.0.0/0 to 10.0.0.2 local 
45.32.34.115 peer any ikesa enc aes-256 prf hmac-sha2-256 auth 
hmac-sha2-256,hmac-sha1 group curve25519 childsa enc chacha20-poly1305 group 
curve25519 dstid blackjack.local lifetime 10800 bytes 536870912 psk 
0x7465737470736b31
set_policy: could not find pubkey for /etc/iked/pubkeys/fqdn/redheart.local
ikev2 "redheart" passive esp inet from 0.0.0.0/0 to 172.16.0.0/24 local 
45.32.34.115 peer any ikesa enc aes-256,aes-192,aes-128,3des prf 
hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group 
modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth 
hmac-sha2-256,hmac-sha1 dstid redheart.local lifetime 10800 bytes 536870912 psk 
0x7465737470736b32 config protected-subnet 0.0.0.0 config address 172.16.0.0 
config netmask 255.255.255.0 config name-server 8.8.8.8
ikev2_recv: IKE_SA_INIT request from initiator 27.8.173.76:500 to 
45.32.34.115:500 policy 'redheart' id 0, 230 bytes
ikev2_sa_responder: no proposal chosen
ikev2_msg_send: IKE_SA_INIT response from 45.32.34.115:500 to 27.8.173.76:500 
msgid 0, 36 bytes
sa_state: SA_INIT -> CLOSED from any to any policy 'redheart'


> On Nov 5, 2018, at 7:25 AM, Aaron Mason  wrote:
> 
> What happens when you remove quick from both policies?
> On Mon, Nov 5, 2018 at 7:00 AM 雷致强  wrote:
>> 
>> OpenIKED is so great when I use one policy for all users. However, I’m 
>> having trouble when I try to apply different policies to different users.
>> With iked.conf followed, iked seems to applies “blackjack” policy to 
>> incoming connections only, which keeps the users of “redheart” out.
>> 
>> ikev2 "blackjack" quick passive ipcomp esp \
>>from 0.0.0.0/0 to 10.0.0.2 \
>>local egress \
>>ikesa enc aes-256 prf hmac-sha2-256 group curve25519 \
>>childsa enc chacha20-poly1305 group curve25519 \
>>dstid "blackjack.local" \
>>psk "testpsk1" \
>> 
>> ikev2 "redheart" quick passive ipcomp esp \
>>from 0.0.0.0/0 to 172.16.0.0/24 \
>>local egress \
>>dstid "redheart.local" \
>>psk "testpsk2" \
>>config protected-subnet 0.0.0.0/0 \
>>config address 172.16.0.0/24 \
>>config netmask 255.255.255.0 \
>>config name-server 8.8.8.8
>> 
>> This is what happens when redheart.local connects to the responder. (I 
>> replaced the IPs to redheart.local and asgard.local)
>> 
>> # iked -dv
>> set_policy: could not find pubkey for /etc/iked/pubkeys/fqdn/blackjack.local
>> ikev2 "blackjack" quick passive esp inet from 0.0.0.0/0 to 10.0.0.2 local 
>> asgard.local peer any ikesa enc aes-256 prf hmac-sha2-256 auth 
>> hmac-sha2-256,hmac-sha1 group curve25519 childsa enc chacha20-poly1305 group 
>> curve25519 dstid blackjack.local lifetime 10800 bytes 536870912 psk 
>> 0x7465737470736b31
>> set_policy: could not find pubkey for /etc/iked/pubkeys/fqdn/redheart.local
>> ikev2 "redheart" quick passive esp inet from 0.0.0.0/0 to 172.16.0.0/24 
>> local asgard.local peer any ikesa enc aes-256,aes-192,aes-128,3des prf 
>> hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group 
>> modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth 
>> hmac-sha2-256,hmac-sha1 dstid redheart.local lifetime 10800 bytes 536870912 
>> psk 0x7465737470736b32 config protected-subnet 0.0.0.0 config address 
>> 172.16.0.0 config netmask 255.255.255.0 config name-server 8.8.8.8
>> ikev2_recv: IKE_SA_INIT request from initiator redheart.local:60970 to 
>> asgard.local:500 policy 'blackjack' id 0, 604 bytes
>> ikev2_sa_responder: no proposal chosen
>> ikev2_msg_send: IKE_SA_INIT response from asgard.local:500 to 
>> redheart.local:60970 msgid 0, 36 bytes
>> sa_state: SA_INIT -> CLOSED from any to any policy 'blackjack'
>> ikev2_recv: IKE_SA_INIT request from initiator redheart.local:60970 to 
>> asgard.local:500 policy 'blackjack' id 0, 604 bytes
>> ikev2_sa_responder: no proposal chosen
>> ikev2_msg_send: IKE_SA_INIT response from asgard.local:500 to 
>> redheart.local:60970 msgid 0, 36 bytes
>> sa_state: SA_INIT -> CLOSED from any to any policy 'blackjack'
>> 
>> If I remove the “quick” option of “blackjack” policy, all incoming 
>> connection goes to “redheart” policy, which blocks “blackjack” users.
>> 
>> Regarding to all the examples I saw, I guess dstid is not a condition to 
>> match the policies? Only “peer” matters?
>> 
> 
> 
> -- 
> Aaron Mason - Programmer, open source addict
> I've taken my software vows - for beta or for worse



Re: [OpenIKED] Is it impossible to differentiate the policies by dstid?

2018-11-04 Thread Aaron Mason
What happens when you remove quick from both policies?
On Mon, Nov 5, 2018 at 7:00 AM 雷致强  wrote:
>
> OpenIKED is so great when I use one policy for all users. However, I’m having 
> trouble when I try to apply different policies to different users.
> With iked.conf followed, iked seems to applies “blackjack” policy to incoming 
> connections only, which keeps the users of “redheart” out.
>
> ikev2 "blackjack" quick passive ipcomp esp \
> from 0.0.0.0/0 to 10.0.0.2 \
> local egress \
> ikesa enc aes-256 prf hmac-sha2-256 group curve25519 \
> childsa enc chacha20-poly1305 group curve25519 \
> dstid "blackjack.local" \
> psk "testpsk1" \
>
> ikev2 "redheart" quick passive ipcomp esp \
> from 0.0.0.0/0 to 172.16.0.0/24 \
> local egress \
> dstid "redheart.local" \
> psk "testpsk2" \
> config protected-subnet 0.0.0.0/0 \
> config address 172.16.0.0/24 \
> config netmask 255.255.255.0 \
> config name-server 8.8.8.8
>
> This is what happens when redheart.local connects to the responder. (I 
> replaced the IPs to redheart.local and asgard.local)
>
> # iked -dv
> set_policy: could not find pubkey for /etc/iked/pubkeys/fqdn/blackjack.local
> ikev2 "blackjack" quick passive esp inet from 0.0.0.0/0 to 10.0.0.2 local 
> asgard.local peer any ikesa enc aes-256 prf hmac-sha2-256 auth 
> hmac-sha2-256,hmac-sha1 group curve25519 childsa enc chacha20-poly1305 group 
> curve25519 dstid blackjack.local lifetime 10800 bytes 536870912 psk 
> 0x7465737470736b31
> set_policy: could not find pubkey for /etc/iked/pubkeys/fqdn/redheart.local
> ikev2 "redheart" quick passive esp inet from 0.0.0.0/0 to 172.16.0.0/24 local 
> asgard.local peer any ikesa enc aes-256,aes-192,aes-128,3des prf 
> hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group 
> modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth 
> hmac-sha2-256,hmac-sha1 dstid redheart.local lifetime 10800 bytes 536870912 
> psk 0x7465737470736b32 config protected-subnet 0.0.0.0 config address 
> 172.16.0.0 config netmask 255.255.255.0 config name-server 8.8.8.8
> ikev2_recv: IKE_SA_INIT request from initiator redheart.local:60970 to 
> asgard.local:500 policy 'blackjack' id 0, 604 bytes
> ikev2_sa_responder: no proposal chosen
> ikev2_msg_send: IKE_SA_INIT response from asgard.local:500 to 
> redheart.local:60970 msgid 0, 36 bytes
> sa_state: SA_INIT -> CLOSED from any to any policy 'blackjack'
> ikev2_recv: IKE_SA_INIT request from initiator redheart.local:60970 to 
> asgard.local:500 policy 'blackjack' id 0, 604 bytes
> ikev2_sa_responder: no proposal chosen
> ikev2_msg_send: IKE_SA_INIT response from asgard.local:500 to 
> redheart.local:60970 msgid 0, 36 bytes
> sa_state: SA_INIT -> CLOSED from any to any policy 'blackjack'
>
> If I remove the “quick” option of “blackjack” policy, all incoming connection 
> goes to “redheart” policy, which blocks “blackjack” users.
>
> Regarding to all the examples I saw, I guess dstid is not a condition to 
> match the policies? Only “peer” matters?
>


-- 
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse



[OpenIKED] Is it impossible to differentiate the policies by dstid?

2018-11-04 Thread 雷致强
OpenIKED is so great when I use one policy for all users. However, I’m having 
trouble when I try to apply different policies to different users.
With iked.conf followed, iked seems to applies “blackjack” policy to incoming 
connections only, which keeps the users of “redheart” out.

ikev2 "blackjack" quick passive ipcomp esp \
from 0.0.0.0/0 to 10.0.0.2 \
local egress \
ikesa enc aes-256 prf hmac-sha2-256 group curve25519 \
childsa enc chacha20-poly1305 group curve25519 \
dstid "blackjack.local" \
psk "testpsk1" \

ikev2 "redheart" quick passive ipcomp esp \
from 0.0.0.0/0 to 172.16.0.0/24 \
local egress \
dstid "redheart.local" \
psk "testpsk2" \
config protected-subnet 0.0.0.0/0 \
config address 172.16.0.0/24 \
config netmask 255.255.255.0 \
config name-server 8.8.8.8

This is what happens when redheart.local connects to the responder. (I replaced 
the IPs to redheart.local and asgard.local)

# iked -dv 
set_policy: could not find pubkey for /etc/iked/pubkeys/fqdn/blackjack.local
ikev2 "blackjack" quick passive esp inet from 0.0.0.0/0 to 10.0.0.2 local 
asgard.local peer any ikesa enc aes-256 prf hmac-sha2-256 auth 
hmac-sha2-256,hmac-sha1 group curve25519 childsa enc chacha20-poly1305 group 
curve25519 dstid blackjack.local lifetime 10800 bytes 536870912 psk 
0x7465737470736b31
set_policy: could not find pubkey for /etc/iked/pubkeys/fqdn/redheart.local
ikev2 "redheart" quick passive esp inet from 0.0.0.0/0 to 172.16.0.0/24 local 
asgard.local peer any ikesa enc aes-256,aes-192,aes-128,3des prf 
hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group 
modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth 
hmac-sha2-256,hmac-sha1 dstid redheart.local lifetime 10800 bytes 536870912 psk 
0x7465737470736b32 config protected-subnet 0.0.0.0 config address 172.16.0.0 
config netmask 255.255.255.0 config name-server 8.8.8.8
ikev2_recv: IKE_SA_INIT request from initiator redheart.local:60970 to 
asgard.local:500 policy 'blackjack' id 0, 604 bytes
ikev2_sa_responder: no proposal chosen
ikev2_msg_send: IKE_SA_INIT response from asgard.local:500 to 
redheart.local:60970 msgid 0, 36 bytes
sa_state: SA_INIT -> CLOSED from any to any policy 'blackjack'
ikev2_recv: IKE_SA_INIT request from initiator redheart.local:60970 to 
asgard.local:500 policy 'blackjack' id 0, 604 bytes
ikev2_sa_responder: no proposal chosen
ikev2_msg_send: IKE_SA_INIT response from asgard.local:500 to 
redheart.local:60970 msgid 0, 36 bytes
sa_state: SA_INIT -> CLOSED from any to any policy 'blackjack'

If I remove the “quick” option of “blackjack” policy, all incoming connection 
goes to “redheart” policy, which blocks “blackjack” users.

Regarding to all the examples I saw, I guess dstid is not a condition to match 
the policies? Only “peer” matters?