Hi,

That thread you've mentioned is almost 10 years old and is about isakmpd not 
iked. I've also tried the same with route-based VPN to AWS with BGP but problem 
is the same. BGP can negotiate route but traffic will not pass if there is no 
approperiate flow set up.


>From iekd perspective this looks like this:

iked_sas: 0x41f72e9e780 rspi 0x0980e96b933f8822 ispi 0x4e425ee4a53d8814 
X.X.X.X:4500->16.170.59.81:4500<IPV4/16.170.59.81>[] ESTABLISHED r natt udpecap 
nexti 0x0 pol 0x41ed13d5000
  sa_childsas: 0x41f72e8f800 ESP 0x8c5e2e0e in 16.170.59.81:4500 -> 
X.X.X.X:4500 (LA) B=0x0 P=0x41f72e8ed00 @0x41f72e9e780
  sa_childsas: 0x41f72e8ed00 ESP 0xc643a377 out X.X.X.X:4500 -> 
16.170.59.81:4500 (L) B=0x0 P=0x41f72e8f800 @0x41f72e9e780
  sa_flows: 0x41f670ba800 ESP out 10.2.15.0/24 -> 172.31.0.0/20 [0]@-1 () 
@0x41f72e9e780
  sa_flows: 0x41f72eafc00 ESP in 172.31.0.0/20 -> 10.2.15.0/24 [0]@-1 () 
@0x41f72e9e780
  sa_flows: 0x41f670cd000 ESP out 10.2.15.0/24 -> 172.31.16.0/20 [0]@-1 () 
@0x41f72e9e780
  sa_flows: 0x41f72ebd000 ESP in 172.31.16.0/20 -> 10.2.15.0/24 [0]@-1 () 
@0x41f72e9e780
  sa_flows: 0x41f72eaf800 ESP out 10.2.15.0/24 -> 172.31.32.0/20 [0]@-1 () 
@0x41f72e9e780
  sa_flows: 0x41f72ea8000 ESP in 172.31.32.0/20 -> 10.2.15.0/24 [0]@-1 () 
@0x41f72e9e780
  sa_flows: 0x41f72ea8400 ESP out 169.254.74.238/32 -> 169.254.74.237/32 [0]@-1 
() @0x41f72e9e780
  sa_flows: 0x41f72eaf000 ESP in 169.254.74.237/32 -> 169.254.74.238/32 [0]@-1 
() @0x41f72e9e780
iked_sas: 0x41f72eab780 rspi 0x19dfa021335741c8 ispi 0x0d8f2ce39a096333 
X.X.X.X:4500->16.170.59.81:4500<IPV4/16.170.59.81>[] ESTABLISHED r natt udpecap 
nexti 0x0 pol 0x41ed13d5000
  sa_childsas: 0x41f72e9a000 ESP 0xc4c246f8 out X.X.X.X:4500 -> 
16.170.59.81:4500 (L) B=0x0 P=0x41f72eb9a00 @0x41f72eab780
  sa_childsas: 0x41f72eb9a00 ESP 0x1345935a in 16.170.59.81:4500 -> 
X.X.X.X:4500 (LA) B=0x0 P=0x41f72e9a000 @0x41f72eab780
  sa_flows: 0x41f72ec7800 ESP out 10.2.15.0/24 -> 172.31.0.0/20 [0]@-1 (L) 
@0x41f72eab780
  sa_flows: 0x41f72e91800 ESP in 172.31.0.0/20 -> 10.2.15.0/24 [0]@-1 (L) 
@0x41f72eab780
  sa_flows: 0x41f72ead400 ESP out 10.2.15.0/24 -> 172.31.16.0/20 [0]@-1 (L) 
@0x41f72eab780
  sa_flows: 0x41f72eadc00 ESP in 172.31.16.0/20 -> 10.2.15.0/24 [0]@-1 (L) 
@0x41f72eab780
  sa_flows: 0x41f72e91c00 ESP out 10.2.15.0/24 -> 172.31.32.0/20 [0]@-1 (L) 
@0x41f72eab780
  sa_flows: 0x41f72ead000 ESP in 172.31.32.0/20 -> 10.2.15.0/24 [0]@-1 (L) 
@0x41f72eab780
  sa_flows: 0x41f72e90400 ESP out 169.254.74.238/32 -> 169.254.74.237/32 [0]@-1 
(L) @0x41f72eab780
  sa_flows: 0x41f72ead800 ESP in 169.254.74.237/32 -> 169.254.74.238/32 [0]@-1 
(L) @0x41f72eab780

I think that (L) marking means that this flow is loaded into the kernel and 
some of them are missing. It may be some change in iked to fix this, I think.



PS: I'm working with devices of different vendors and I think that in some way 
OpenBSD have problem with this.


----- Original Message -----
From: "Hrvoje Popovski" <hrv...@srce.hr>
To: "Rafał Ramocki" <rafal.ramo...@eo.pl>, "bugs" <bugs@openbsd.org>
Sent: Monday, March 11, 2024 1:05:10 PM
Subject: Re: HA IPSec with AWS - no second flow

On 11.3.2024. 10:22, Rafał Ramocki wrote:
>> (...)
> I think IKED may detect that flow is already set for this from-to pair and is 
> not setting up additional one but it should take also remote endpoint into 
> account as those are different. Having no flow set up is resulting in that, 
> when some data are received on that second tunnel that have no flows set, 
> those data are discarded and not forwarded any more propably due to RPF 
> policy. 
> 
> I tried to figure out how those are set up by code analysys but I think it 
> may be beyond my capabilitys as I'm only a sysadmin not a developer. 
> 
> OpenBSD version: 7.3 
> 
> best regards 
> Rafal Ramocki 
> 


Hi,

I think that you can't have two same ipsec tunnels with policy based
vpns in OpenBSD, but you can do something like this
https://www.linuxquestions.org/questions/blog/rocket357-328529/openbsd-etc-ipsec-conf-for-aws-vpc-vpn-36423/

Good thing is that OpenBSD from 7.4 supports route based ipsec tunnels
https://www.undeadly.org/cgi?action=article;sid=20230704094238

Reply via email to