For send_redirects you can find an answer in the Libreswan FAQ:
Let's say you have a VPN server in a cloud that you use with your
phone. Your phone will setup an IPsec VPN and all its traffic is
encrypted and send to the cloud instance, which decrypts it and sends
it on the internet, using SNAT. Replies it receives are encrypted and
send to your phone.
Your phone will send the VPN server an encrypted packet. The server
receives it on eth0 (its only interface!) and decrypts it. The
decrypted packet is then ready to get routed. The server looks which
interface it should send the packet to. It is destined to go out eth0.
Since the packet came in via eth0 and would go out via eth0, the
server concludes there clearly must be a better path not involving
itself, since it is going out the same interface. It has no idea the
packet arrived encrypted and got decrypted.
This is why we recommend disabling "send_redirects" in
/etc/sysctl.conf using
Maybe the Introduction to strongSwan is a little bit clearer here:
If the VPN gateway is not the default gateway of the LAN, ICMP
redirects might get returned to hosts if they send traffic destined
for the remote hosts/subnets to the VPN gateway, directing them to the
default gateway of the LAN (which probably doesn't work and otherwise
might get that traffic out unencrypted). To avoid this, disable
sending such ICMP messages by setting net.ipv4.conf.all.send_redirects
and net.ipv4.conf.default.send_redirects to 0 (if the latter is not
set before the interface comes up, also set the option for the
individual interface, i.e. net.ipv4.conf..send_redirects).
For accept_redirects I would assume just good networking practice. Since your VPN gateway should know all local routes, any ICMP redirect would be bogus and should be ignored.