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
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
