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.

> 
> Best Regards,
> -pjp
> 
> -- 
> my associated domains:  callpeter.tel|centroid.eu|dtschland.eu|mainrechner.de