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

Can you share your configuration please? I use rc11, too as l2tp/ipsec access concentrator and everything is fine here.

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

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

Submitted PR #23 on vyos/vyatta-cfg-quagga to fix this.

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.

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.

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.

Hi @hagbard!
Config in attachment.

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

Let's do as you suggest
we just need to nuke all mbr/gpt before install

Uh. That's pretty crazy! I'll play around with the option on the other VMs I am migrating from Proxmox VE to VMWare ESXi.

It is vmware-tools collecting all the routes from VyOS and reporting them to the hypervisor so you can see them in the ESXi GUI. Not really optimal for full tables.

Yes, but only IPv6. It seems that the VMware Tools only produce the load when the BGP sessions are established. Pretty strange! Maybe some sort of memory problem?

Do you have a full bgp table on this box?

Yep, seems to do the job.

IIRC I worked around this by editing /etc/vmware-tools/tools.conf and adding:

The shared-network-parameters is a real pain and should be used "without warranty" we should rather deprecate it and add proper CLI interface.

I saw that in earlier versions too, but not in 1.2.0-RC11. Can you please retest on RC11?

Next rolling release tonight will have the bugfix in place. Thanks for reporting.

As the DHCP client sometimes stores its lst IP address and sends a request for it you probably should delete the lease from the DHCP server:

With the following patch the statements are migrated. Needs some work to also migrate the metric and route-map settings. Will try to do that later.

Thanks for catching this! I've fixed it in the upcoming rc11.

@hagbarg Sorry I haven't spotted this earlier and had to revert your commit! Please check out my commits: this is how it's been done historically. You would have to also add PBR templates so I see no reason for duplicating that, especially in light of planned firewall overhaul that will rid us from interface templates.

Uh, yeah, that sucks. I'm implementing the kernel variables for wireguard at the moment and have a look into the other interfaces after that.

Here what I mean.
Before enabling rp_filter:

net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.eth2.rp_filter = 0
net.ipv4.conf.l2tpeth1.rp_filter = 0
net.ipv4.conf.lo.rp_filter = 0

After enabling:

net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.eth2.rp_filter = 2
net.ipv4.conf.l2tpeth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2

After disabling:

net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.eth2.rp_filter = 2
net.ipv4.conf.l2tpeth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2

Ahh, I think I found it. Usually sysctl sets it to 1, or at least it must have that done in 1.1. I think the command should be called then enable-arp-filter to correct it.

Unless I misunderstood you, int(0) does disable (no source validation) rp_filter.

• CONFIG_MMC_BLOCK already enabled
• CONFIG_MMC_SDHCI_ACPI has been enabled

Thanks for testing and confirming. @trystan

I've installed on two hosts (virtual/cloud instance, and 1 physical) in,local,out rules all work as expected with default drop and firewall state-policy establish/related accepted.

@trystan next rolling image will have the functionality, if you'd like to manual install it, you can do so by installing http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-8_all.deb.
Thanks for your request and please let me know your results.

Please note:

I've tested that I can utilize the existing firewall functions/scripts which work, so I need to write a wrapper for it, but that will solve the issue. Shouldn't take too long.

Not directly but it was added here: https://github.com/librenms/librenms/pull/351

Oh, okay.
Then it looks like the issue is more at Observium and not VyOS.

I see OS version in libreNMS.