@zsdc I can't reproduce it, can you please share your config? I have only enable send redirects set, nothing else in the config and everything works like expected. I suspect that something is overwriting your variables. We'll find out.

Hi @hagbard!
Config in attachment.

I still have no luck reproducing it, I loaded your config on a vm, runni9ng the smae version as you do but if I enable and disable redirects it switches between 1 and 0, as expected.

If you just enable and reboot it works too? I've seen this problem at different routers with RC3, RC11 and rolling, but I can't find obvious reason for it.

Yes, that's correct. When I enable redirects, it automatically disables receive redirects, which I didn't know but makes sense.
I have only set the redirect and dhcp on eth0, commit && save and rebooted, all looks good.

set firewall ipv6-receive-redirects 'disable'
set firewall receive-redirects 'disable'
set firewall send-redirects 'enable'

before and after reboot:

sudo sysctl -a | grep send_redirects
net.ipv4.conf.all.send_redirects = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.eth0.send_redirects = 1
net.ipv4.conf.eth1.send_redirects = 1
net.ipv4.conf.lo.send_redirects = 1

Can you check ig you have any postscripts running or any manual sysctl variable set? Or do you experience that on new insatllations?

I found. This is VPN settings.
Based on information from Linux IP stack flow diagrams, IPSec policy applying after route decision, and ICMP redirects doing before this. So we can't leave send_redirects=1 on interface, where we receive unencrypted traffic for IPSec.
But, we can:

1. Check for firewall send-redirects 'enable' and prevent to commiting vpn ipsec options, when send_redirects is enabled.
2. Disable send_redirects only on interfaces, where we expect incoming unencrypted IPSec traffic.

I'm not sure, what is better.

I have a look into it but I doubt that this will be an issue. Charon is usually taking care of the routes if an IPSec tunnel has been established and you have a valid SA. The redirects from the settings above shouldn't interferer with it at all. If a mode tunnel is being used with public IPs, the packets will leave the system unencrypted anyway as long as no valid SA exists, so they will go the default route. I'll check if the perl script is actually changing these settings, that would be not so nice since you will face a race condition which would explain why I can't reproduce your issue, since I never tested with a working IPSec tunnel :). I'm having the flu right now, so please give me a few days to have a look.

I've made some tests...
I have build a lab with next configuration:

vyos@vyos:~$ show ip route 
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route

S>* 0.0.0.0/0 [1/0] via 10.1.1.1, eth0, 00:05:39
C>* 10.1.1.0/24 is directly connected, eth0, 00:05:40
vyos@vyos:~$ show ip route table 220
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route

K>* 10.2.1.0/24 [0/0] via 10.1.1.1, eth0, src 10.1.1.2, 00:05:47

IPSec settings and policy on R2:

vyos@vyos# show vpn ipsec site-to-site 
 peer 10.3.1.2 {
     authentication {
         mode pre-shared-secret
         pre-shared-secret secret
     }
     connection-type initiate
     ike-group ike1
     ikev2-reauth inherit
     local-address 10.1.1.2
     tunnel 1 {
         allow-nat-networks disable
         allow-public-networks disable
         esp-group esp1
         local {
             prefix 10.1.1.0/24
         }
         remote {
             prefix 10.2.1.0/24
         }
     }
 }

vyos@vyos:~$ show vpn ipsec policy 
src 10.1.1.0/24 dst 10.2.1.0/24 
        dir out priority 375423 ptype main 
        tmpl src 10.1.1.2 dst 10.3.1.2
                proto esp spi 0xc48f6ea9 reqid 1 mode tunnel
src 10.2.1.0/24 dst 10.1.1.0/24 
        dir fwd priority 375423 ptype main 
        tmpl src 10.3.1.2 dst 10.1.1.2
                proto esp reqid 1 mode tunnel
src 10.2.1.0/24 dst 10.1.1.0/24 
        dir in priority 375423 ptype main 
        tmpl src 10.3.1.2 dst 10.1.1.2
                proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket in priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket out priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket in priority 0 ptype main 
src 0.0.0.0/0 dst 0.0.0.0/0 
        socket out priority 0 ptype main 
src ::/0 dst ::/0 
        socket in priority 0 ptype main 
src ::/0 dst ::/0 
        socket out priority 0 ptype main 
src ::/0 dst ::/0 
        socket in priority 0 ptype main 
src ::/0 dst ::/0 
        socket out priority 0 ptype main

Then, I have run ICMP ping from test PC to 10.2.1.1 and start dumping.
With send_redirects=0:

00:17:09.996120 IP 10.1.1.3 > 10.2.1.1: ICMP echo request, id 23602, seq 1, length 64
00:17:10.025372 IP 10.2.1.1 > 10.1.1.3: ICMP echo reply, id 23602, seq 1, length 64
00:17:10.996472 IP 10.1.1.3 > 10.2.1.1: ICMP echo request, id 23602, seq 2, length 64
00:17:11.024287 IP 10.2.1.1 > 10.1.1.3: ICMP echo reply, id 23602, seq 2, length 64

After sysctl net.ipv4.conf.all.send_redirects=1:

00:17:38.431684 IP 10.1.1.3 > 10.2.1.1: ICMP echo request, id 23615, seq 1, length 64
00:17:38.431958 IP 10.1.1.2 > 10.1.1.3: ICMP redirect 10.2.1.1 to host 10.1.1.1, length 92
00:17:38.461083 IP 10.2.1.1 > 10.1.1.3: ICMP echo reply, id 23615, seq 1, length 64
00:17:39.433141 IP 10.1.1.3 > 10.2.1.1: ICMP echo request, id 23615, seq 2, length 64
00:17:39.433466 IP 10.1.1.2 > 10.1.1.3: ICMP redirect 10.2.1.1 to host 10.1.1.1, length 92
00:17:39.460036 IP 10.2.1.1 > 10.1.1.3: ICMP echo reply, id 23615, seq 2, length 64

So, routing works before IPSec, as was expected, and problem is really exist. And we must keep send_redirects disabled (at least on a part of interfaces) when using IPSec.

@zsdc if I understand you correctly, you want that /proc/sys/net/ipv4/conf/all/send_redirects is always 0 unless configured on purpose, correct?
Per default router should do that.

Wouldn't a cli command like:
'set interfaces ethernet ethx ip send-redirect disable' help?

By default, more optimal will be leaving send_redirects in enabled state.
I think, that better will be preventing to commit something in vpn ipsec if send_redirects is enabled for any interface, as we can't predict at 100% from which interface will be received traffic, that need to be encrypted with IPSec.
Per-interface option can help in any case, definitely. But we need to leave at least warning to user, where will be clearly said, that with enabled send_redirects some of traffic from interface with this option can be leaked through unencrypted channels.

Hmm, I don't like the leaking part :D (I doubt that it will be unecrypted, but haven't tested it yet) . Per default redirects are enabled on every interface, which is the default.

I doubt that it will be unecrypted

It can be at 100% unencrypted. If sender accept redirects, then traffic can be routed through another router. :)

But wouldn't that be a n SA issue in strongswan?
Found their bugreports, I think the best and safest way is to turn redirects entirely off and set an option in interfaces to turn it on. That way we can assure that a warning messages is also read and understood. agree?

The latest rolling has now 'net.ipv4.conf.all.send_redirects = 0', can you please test if that would solve that issue?