On Mon, Mar 11, 2024 at 02:33:26PM +0100, Rafa?? Ramocki wrote: > 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.
the problem you're hitting up against is in the kernel though, so it doesnt matter whether it is isakmpd or iked sets up the flows. > 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. yes, that's why we added support for route based ipsec vpns via the sec(4) interface, as per the links that hrvoje provided and https://marc.info/?l=openbsd-tech&m=168844868110327&w=2. i just set up a an openbsd box talking to aws s2s with iked yesterday. your config would look a bit like this: dlg@obsd-aws-gw0:/etc$ sudo cat hostname.em0 inet 192.0.2.51 255.255.255.0 dlg@obsd-aws-gw0:/etc$ sudo cat hostname.sec0 inet 169.254.21.38 255.255.255.252 169.254.21.37 up dlg@obsd-aws-gw0:/etc$ sudo cat hostname.sec1 inet 169.254.74.238 255.255.255.252 169.254.74.237 up dlg@obsd-aws-gw0:/etc$ sudo cat iked.conf h_self="192.0.2.51" h_s2s1="51.21.86.8" h_s2s1_key="0123456789abcdefghijklmnopqrstuv" h_s2s2="16.170.59.81" h_s2s2_key="abcdefghijklmnopqrstuvwxyz012345" ikev2 "s2s1" active \ from any to any \ local $h_self peer $h_s2s1 \ childsa auth hmac-sha2-256 enc aes-256 group ecp256 \ psk $h_s2s1_key \ iface sec0 ikev2 "s2s2" active \ from any to any \ local $h_self peer $h_s2s2 \ childsa auth hmac-sha2-256 enc aes-256 group ecp256 \ psk $h_s2s2_key \ iface sec1 that should be enough to get ipsec up and running so you can talk to aws over the sec(4) interfaces. the next step is to set up routes to your nets in aws over these links. we use bgpd to dynamically learn routes and fail over between the the different sec interfaces, but if you wanted to do ecmp/multipath you could manually add routes over each interface. dlg > ----- 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 >
