[Swan] thought I had connection with arping

[Paul Wouters]

On Mon, 15 Jan 2024, Marc wrote:

>>> with such a config
>>> leftsubnet=192.168.21.0/24
>>> rightaddresspool=192.168.21.200-192.168.21.210
>>
>>
>> This can’t really work. Where does the 192.16821.201 live? It’s both on left
>> and on right.
>
> No ip's are either on the left or on the right.

That is not deterministic in your configuration. If this kernel needs to
send a packet to 192.168.21.201, should it go to "left" or "right" ?

>  I think this is why host routes are required. I can remember doing something like this with cni plugins. However this is probably limited to the host (guessing here a lot)

You are just digger deeping.

>> Usually one reserved a unique space for addresspool and then all internal
>> machines route that range to the vpn server.
>>
>> Pick another range for addresspool.
>
> Currently I have this working with:

You do not have it working :)

> - on the host no ip in the range 192.168.x.0 on eth1
> - no net.ipv4.conf.eth1.proxy_arp=1
> - in _updown.xfrm I commented out #uproute (the host route for peers)
> - and in updown.sh I have something like this:
>
>    105 PLUTO_PEER_CLIENTIP=${PLUTO_PEER_CLIENT%/*}
>    106 PIDFILE="/tmp/${PLUTO_PEER_CLIENTIP}-arp.pid"
>    107
>    108 if [ "${PLUTO_VERB}" == "up-client" ]
>    109 then
>    110   echo "$(date +"%Y%m%d-%H%M%S") up" >> $TMPLOG
>    111   arping -q -W 4 -i ${PLUTO_INTERFACE} -S ${PLUTO_PEER_CLIENTIP} 192.168.x.a >/dev/null 2>&1 &
>    112   PID=$!
>    113   echo -n "$PID " > "$PIDFILE"
>    114   arping -q -W 4 -i ${PLUTO_INTERFACE} -S ${PLUTO_PEER_CLIENTIP} 192.168.x.b >/dev/null 2>&1 &
>    115   PID=$!
>    116   echo -n "$PID " >> "$PIDFILE"
>    117 fi

If you don't do a double fork from updown, it will not detach properly
and pluto will block forever until the arping command has completed.
See libreswan/contrib/updown-example/

My guess is either the systemd watch dog is shooting pluto because its
blocked indefinately, or pluto managed to fail the updown and brings
down the connection.

> Someone with good knowledge should be able to convert this hack to something that does not need to have this arpings running not? I think this is also related to how ipsec works. I there would be an interface with an ip visible in the container, this would work better. Maybe this host route would be indeed sufficient.

*raises hand*

Use a different range for the addresspool and route that range from your
other nodes to the libreswan server :)

Paul