From: "Peter J. Philipp" Subject: Re: suggestions for sec(4) To: David Gwynne Cc: tech@openbsd.org Date: Sun, 5 May 2024 14:18:34 +0200 On Sun, May 05, 2024 at 09:17:56PM +1000, David Gwynne wrote: > On Sun, Apr 28, 2024 at 09:51:20AM +0200, Peter J. Philipp wrote: > > Hi David, Hi tech@, > > > > I somehow managed to configure a few sec(4) interfaces and everything worked > > fine yesterday. This morning as i got up I noticed my nightly recycling of > > pppoe0 broke everything. I tried to bring it back but noticed that no flows > > would be installed by iked. I had to revert yesterdays configuration of > > changing everything to sec(4). > > > > I have a dynamic IP through an ISP in germany which outsourced the last mile > > to telekom (DTAG). What I do is I go through everything through my cloud > > provider by IPSEC'ing the traffic from the dynamic IP to the cloud VPS. It > > works well except in one aspect. The IPSEC without sec(4) is doggedly slow, > > so there has to be something like an MTU issue or something. To make matters > > a little more complicated, I have a wireguard tunnel inside the IPSEC so it's > > doubly encrypted with AES 256. This has a caveat that when the IPSEC is not > > configured with iked, the wireguard will not initiate either as the telekom > > or this ISP have installed certain filters preventing wireguards initiation > > signature. However once it is initiated it will function nicely. > > > > My pppoe0 when it connects has only 1 route, to the VPS. It does not have > > a default route. For sec0 it was weird configuring it with an IP of 0.0.0.0/0 > > or 0.0.0.2/0 to indicate that it is of dynamic nature and I don't know before- > > hand what the IP is going to be. I somehow believe that this caused problems > > and sec(4) is not really meant to be on dynamic PPPoE. > > having only a route to your VPS via pppoe0 sounds right for the config > you're trying to acheive. > > are you saying you configured 0.0.0.0/0 or 0.0.0.2/0 as the IP address > inside the sec interface? that sounds wrong. sec(4) provides a private > point to point tunnel, so you should configure static non-conflicting > private IPs (rfc1918 style, or 169.254.foo.bar like AWS s2s vpn links) > inside the tunnel. > > eg, something like this in /etc/hostname.sec0: > > inet 169.254.121.11 255.255.255.255 169.254.121.10 > up > > and this in /etc/mygate: > > 169.254.121.10 > > > I propose this pseudo-driver change: Much like vlan(4) it should be configured > > on top of the physical or other pseudo interface, that way it knows it's > > dynamic IP. The condition it will dynamically do this is when the source IP > > is in the 0.0.0.0/24 netblock. For the other side it's reversed we know the > > source IP but not the destination, configuring it to the 0.0.0.0/24 netblock > > again should be indication enough that this is an arbitrary IP somewhere on > > the Internet. The same concept could be done or IPv6 configs. > > again, using the IP address of the pppoe0 link inside sec(4) sounds > wrong to me. further to this, sec(4) itself doesnt know and doesn't > care about the IP addresses used for the IPsec traffic. > > > I'd be willing to look into this but my TODO is growing and growing, I can't. > > I have too many projects on my plate right now. I'll let you in on my dynamic > > IPSEC/IKED config. > > > > ... > > ikev2 passive transport esp from $self_ip to $telekom_ip1 \ > > ikesa enc aes-256-gcm \ > > group sntrup761x25519 \ > > childsa enc aes-256-gcm \ > > group sntrup761x25519 \ > > srcid $self_ip lifetime 1200 tag "IPSEC" > > ... > > your situation sounds more like a "roadwarrior" setup to me. you should > move to using certs instead of IPs to identify the endpoints, then your > home connection should be able to negotiate SAs regardless of what it's > local IP is. > > > There is similar $telekom_ip0, $telekom_ip2, and $telekom_ip3 as they are > > pooled by 4 different /10's and alternate. This is a working config. With > > sec(4) it breaks though (even with the added iface sec0). > > > > In the above config paste the $telekom_ip1 is 87.128.0.0/10 and the $self_ip > > is self explanatory (it's the IP of the VPS). > > > > Is something like this already on a TODO somewhere? Or is there a trick or > > hint that I can get how to make this work with dynamic IP's with sec(4)? > > > > Otherwise my proposal should be considered, and if nothings done by autumn > > I can perhaps look into that. > > i'm not convinced there's a need to change any code here. iked can > already handle setting up SAs with dynamic IPs, and you should be using > static IPs inside the sec(4) tunnel. Thanks for the explanation. I will try this again, in time with your suggestions. Yep it is a little like a roadwarrior setup. To continue on as a GENERAL QUESTION (not just you David): Since you mentioned iked.. Is there any way to make this enc TRANSFORM work? $ man iked.conf | grep chacha20 chacha20-poly1305 288 bits [ESP only] I'm looking for AES alternatives and found only 4 alternatives in iked. There is that, cast, blowfish and 3des. I don't know much about cast, and twofish and threefish exist so blowfish is probably outdated. I chose triple des. ikev2 passive transport esp from $self_ip to $telekom_ip3 \ ikesa auth hmac-sha2-512 prf hmac-sha2-512 enc 3des \ group sntrup761x25519 \ childsa auth hmac-sha2-512 prf hmac-sha2-512 enc 3des \ group sntrup761x25519 \ srcid $self_ip lifetime 1200 tag "IPSEC" However I couldn't get the chacha20-poly1305 to work by placing it as: "enc chacha20-poly1305" in place of "enc 3des"... Does the x in "Default" Column have anything to do with that? Thank you! Best Regards, -pjp