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