Page MenuHomePhabricator

"firewall send-redirects enable" works only after switching from disabled state on running system
Closed, ResolvedPublicBUG

Description

Hello!
firewall send-redirects enable option don't work as expected.

After booting with enabled redirects:

vyos@vyos-12-01:~$ show configuration | match send-redirects
    send-redirects enable
vyos@vyos-12-01:~$ sudo sysctl -a | grep send_redirects
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.eth0.send_redirects = 0
net.ipv4.conf.eth1.send_redirects = 0
net.ipv4.conf.eth2.send_redirects = 0
net.ipv4.conf.lo.send_redirects = 0

After deleting option and setting again:

[edit]
vyos@vyos-12-01# delete firewall send-redirects 
[edit]
vyos@vyos-12-01# commit
[edit]
vyos@vyos-12-01# exit
Warning: configuration changes have not been saved.
exit
vyos@vyos-12-01:~$ show configuration | match send-redirects
vyos@vyos-12-01:~$ sudo sysctl -a | grep send_redirects
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.eth0.send_redirects = 0
net.ipv4.conf.eth1.send_redirects = 0
net.ipv4.conf.eth2.send_redirects = 0
net.ipv4.conf.lo.send_redirects = 0
vyos@vyos-12-01:~$ conf
[edit]
vyos@vyos-12-01# set firewall send-redirects enable 
[edit]
vyos@vyos-12-01# commit
[edit]
vyos@vyos-12-01# exit
Warning: configuration changes have not been saved.
exit
vyos@vyos-12-01:~$ show configuration | match send-redirects
    send-redirects enable
vyos@vyos-12-01:~$ sudo sysctl -a | grep send_redirects
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.eth0.send_redirects = 0
net.ipv4.conf.eth1.send_redirects = 0
net.ipv4.conf.eth2.send_redirects = 0
net.ipv4.conf.lo.send_redirects = 0

After disabling and enabling again (the same behavior will be if boot with disabled and enable on running system):

[edit]
vyos@vyos-12-01# set firewall send-redirects disable 
[edit]
vyos@vyos-12-01# commit
[edit]
vyos@vyos-12-01# exit
Warning: configuration changes have not been saved.
exit
vyos@vyos-12-01:~$ show configuration | match send-redirects
    send-redirects disable
vyos@vyos-12-01:~$ sudo sysctl -a | grep send_redirects
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.eth0.send_redirects = 0
net.ipv4.conf.eth1.send_redirects = 0
net.ipv4.conf.eth2.send_redirects = 0
net.ipv4.conf.lo.send_redirects = 0
vyos@vyos-12-01:~$ conf
[edit]
vyos@vyos-12-01# set firewall send-redirects enable 
[edit]
vyos@vyos-12-01# commit
[edit]
vyos@vyos-12-01# exit
Warning: configuration changes have not been saved.
exit
vyos@vyos-12-01:~$ show configuration | match send-redirects
    send-redirects enable
vyos@vyos-12-01:~$ sudo sysctl -a | grep send_redirects
net.ipv4.conf.all.send_redirects = 1
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.eth0.send_redirects = 0
net.ipv4.conf.eth1.send_redirects = 0
net.ipv4.conf.eth2.send_redirects = 0
net.ipv4.conf.lo.send_redirects = 0

Details

Difficulty level
Unknown (require assessment)
Version
1.2.0-rolling+201812240337
Why the issue appeared?
Will be filled on close

Event Timeline

zsdc created this task.Dec 24 2018, 2:43 PM
hagbard claimed this task.Dec 24 2018, 6:00 PM

@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.

zsdc added a comment.Dec 24 2018, 9:29 PM

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.

zsdc added a comment.Dec 25 2018, 6:21 AM

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?

zsdc added a comment.Dec 27 2018, 4:42 PM

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.

zsdc added a comment.Dec 28 2018, 10:45 PM

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


In test PC gateway to 10.2.1.0/24 is R2.
In R2 we have next routing tables:

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.

syncer triaged this task as Normal priority.Jan 3 2019, 2:05 PM
syncer edited projects, added VyOS 1.2 Crux (VyOS 1.2.0-EPA3); removed VyOS 1.2 Crux.
pasik added a subscriber: pasik.Jan 3 2019, 10:44 PM
hagbard changed the task status from Open to In progress.Jan 8 2019, 5:48 PM
hagbard added a comment.EditedJan 8 2019, 6:02 PM

@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?

zsdc added a comment.Jan 8 2019, 8:28 PM

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.

zsdc added a comment.Jan 8 2019, 8:53 PM

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. :)

hagbard added a comment.EditedJan 8 2019, 9:07 PM

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?

hagbard changed the task status from In progress to Needs testing.Jan 8 2019, 10:28 PM
hagbard closed this task as Resolved.Jan 15 2019, 5:48 PM