strongSwan

Note that I am not using the DHCP plugin and I assume FARP should not depend on DHCP.

Thanks for the rapid response Tobias!

Even though my traffic selectors (leftsubnet rightsubnet) are IPv6, the $PLUTO_MY_SOURCEIP returns the IPv4 addres of the VPN client (I read Issue #848). What is the correct reference to fetch virtual IPv6 address?

Even though my traffic selectors (leftsubnet rightsubnet) are IPv6, the $PLUTO_MY_SOURCEIP returns the IPv4 addres of the VPN client (I read Issue #848). What is the correct reference to fetch virtual IPv6 address?

It won't work with that variable.

PLUTO_MY_SOURCEIP will contain the first virtual IP that is assigned. But all virtual IPs (including the first one) are passed in PLUTO_MY_SOURCEIP4_x and PLUTO_MY_SOURCEIP6_x to the script (x is an index starting with 1) - at least since 5.0.1.

However, these variables only contain the local virtual IPs, i.e. those that were assigned by the other peer. What's currently missing are PLUTO_PEER_SOURCEIP* variables that would contain the virtual IPs assigned to a peer, if any. It's strange that PLUTO_MY_SOURCEIP is set at all when the script runs on the responder in your case (or did you check on the initiator?). I pushed a commit to the updown-peer-vip branch that adds these variables.

Also, please be aware that the script might be called multiple times with the same virtual IPs but different local and remote traffic selectors (PLUTO_MY|PEER_CLIENT).

So in your case you could probably just check whether the remote traffic selector (PLUTO_PEER_CLIENT) ends with /128 and if so interpret that as virtual IP and just ignore PLUTO_*_SOURCEIP* (with the PLUTO_PEER_SOURCEIP* variables these could be compared to PLUTO_PEER_CLIENT to make sure they are virtual IPs).

using MY_SOURCEIP was a mistake, I am working on the responder.
The traffic selector for remote traffic is a /97 (the entire VPN IPv6 pool) in ipsec.conf.
PLUTO_PEER_CLIENT fetches the /97 not individual /128.
Following is from syslog

assigning virtual IP 2001:470:1:1a5:1::1 to peer 'carol'
CHILD_SA rw{2} established with SPIs c9bd255e_i 194839bc_o and TS ::/0 === 2001:470:1:1a5:1::/97

So it assigns a /128 but establishes the CHILD_SA to /97. So every time a VPN client dials in, the same CHILD_SA will be created as duplicate?

Too bad that add proxy command works with /128 only.

The traffic selector for remote traffic is a /97 (the entire VPN IPv6 pool) in ipsec.conf.

Which is wrong (see #1006#note-3 for my recent explanation why, it's for IPv4 but applies here too if you have rightsubnet configured).

So it assigns a /128 but establishes the CHILD_SA to /97. So every time a VPN client dials in, the same CHILD_SA will be created as duplicate?

Yes, see link above.

Too bad that add proxy command works with /128 only.

What do you mean?

I sensed that using rightsubnet could be wrong and removed it. I just saw that you also suggested that way.
Now it all works, I appreciate your help Tobias!
For anyone who may need, following is the script

#/etc/strongswan.d/proxyndp.updown
case $PLUTO_VERB in
        up-client-v6)
        ip -6 neigh add proxy ${PLUTO_PEER_CLIENT%????} dev eth0
        ;;
        down-client-v6)
        ip -6 neigh delete proxy ${PLUTO_PEER_CLIENT%????} dev eth0
        ;;
esac

...and in case your default interface for a route is not always eth0:

# cat /etc/strongswan.d/proxyndp.updown
OUTDEV=$(ip -6 r get ${PLUTO_PEER_CLIENT%????}|sed -ne 's,^.*dev \(\S\+\) .*,\1,p')
case $PLUTO_VERB in
        up-client-v6)
        ip -6 neigh add proxy ${PLUTO_PEER_CLIENT%????} dev ${OUTDEV:-eth0}
        ;;
        down-client-v6)
        ip -6 neigh delete proxy ${PLUTO_PEER_CLIENT%????} dev ${OUTDEV:-eth0}
        ;;
esac