Re: [Swan] thought I had connection with arping
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
Re: [Swan] thought I had connection with arping
> > the arping is only sending 10, then quits and 7 seconds after that the
> ping stalls.
>
> Oh I see you did not mix up the terms ping and arping.
>
> >
> >>>
> > 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. 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)
> 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:
- 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
118
119 if [ "${PLUTO_VERB}" == "down-client" ]
120 then
121 echo "$(date +"%Y%m%d-%H%M%S") down" >> $TMPLOG
122 if [ -f "$PIDFILE" ]
123 then
124 kill -9 $(cat "$PIDFILE")
125 rm -f "$PIDFILE"
126 fi
127 fi
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.
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] thought I had connection with arping
On Jan 15, 2024, at 14:50, Marc wrote: > > >> >>> >>> > the arping is only sending 10, then quits and 7 seconds after that the ping > stalls. Oh I see you did not mix up the terms ping and arping. > >>> > 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. 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. ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] thought I had connection with arping
> > > > > > If I do a ping from the ipsec client to the host, it stalls. > > > > When I execute in the libreswan container this command > > > > arping -c 10 -i eth1 -S 192.168.x.3 192.168.11.15 > > > > The ipsec client can ping the host but after 7 seconds, the ping stalls > again. the arping is only sending 10, then quits and 7 seconds after that the ping stalls. > > > > Anyone had something like this? > > I'm a but confused between your use of "ping" and "arping". > > If with libreswan stopped, no this is during a logged in session. > your arpping is stalling, this would not be a > libreswan issue. not the ping is stalling, when I stop the simultanously running arping. > If with libreswan up, arpping is causing stalls, that > would indicate some issue related to the system with libreswan. > I just have problems getting this config running https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2_split_VPN with such a config leftsubnet=192.168.21.0/24 rightaddresspool=192.168.21.200-192.168.21.210 The problem is that somehow when the arpping is stopped, remote hosts are 'forgetting' about the location of the ipsec clients. That is the problem to be solved. I have to little network tcp/ip knowledge what/why/when a remote host will forget about this ip. I think the above configuration only works if one pings ip addresses that are on the host, I don't think hosts on the network can be reached. ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] thought I had connection with arping
On Sun, 14 Jan 2024, Marc wrote: Subject: [Swan] thought I had connection with arping If I do a ping from the ipsec client to the host, it stalls. When I execute in the libreswan container this command arping -c 10 -i eth1 -S 192.168.x.3 192.168.11.15 The ipsec client can ping the host but after 7 seconds, the ping stalls again. Anyone had something like this? I'm a but confused between your use of "ping" and "arping". If with libreswan stopped, your arpping is stalling, this would not be a libreswan issue. If with libreswan up, arpping is causing stalls, that would indicate some issue related to the system with libreswan. Paul ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
