FRR people fixed it rather quickly!

Ok, ignore it, I decided not to be a lazy butt and test it myself. ;)
Reload is not enough, restart is needed, so the fix should be complete.

I've added SNMP restart on hostname change, it will be in the next nightly build.

Oh, you forgot metric and route-map options. Extending your patch to support them wasn's hard though, most of the work was already done.

Hey @Merijn, sorry for late reply and thanks for the patch! I've merged it in and it will be in the next nightly build.

I could reproduce it in today's FRR master. I'm reporting the issue to FRR maintainers.

I've changed it to handle the situation gracefully. Actual display of connecting SAs is another story of course... The fix will be in the next nightly build.

@zsdc The fix for T1011 should have fixed this, but there's a crucial and annoying detail: apparently when the nf_conntrack module is (re)loaded without nf_conntrack_helper=1 option, the sysctl value gets overwritten.

Yes, seems it's just forgotten sync-group. A sync-group is required for it to work, in the current implementation. The error message is confusing and bug-like though, as of me.

@m.cremers The fix will be in the next nightly build, please re-test.

So far:

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

If we are planning firewall overhaul, the old design issues should not get in the way. It's planned for 1.3 though

That command works for me in the upcoming rc, so I assume they fixed it.

That command has been removed in rc10. "run show ipsec debug" is now mapped to "ipsec statusall", which should be detailed enough for all practical purposes.

Good catch! Fixed.

Ah , another minor incompatibility between Quagga and FRR. I've fixed it, the fix will be in the next rc.

@hagbard I've added it to all interface templates generators now, including that for QoS.

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

@begetan Yeah, very strange. I need to check why this issue re-appeared, hope I'll get it fixed by tomorrow.

I've tested this configuration again and it works for me, so I suppose it's fixed. If it reapprears, feel free to reopen.

@hagbard "show vpn ipsec sa verbose" is now a thin wrapper for "ipsec statusall" so it's not applicable there either. :)

...to be fair, I also think there should be a warning when trying to save a config on a livecd. We hear from people once in a while that they forgot they are running from a livecd and lose their config after reboot.

Clearly undesirable behaviour was caused by a combination of two issues: StrongSWAN starting even when IPsec is not present in the VyOS config, and /etc/ipsec.conf staying in place if config was commited but not saved.

The only remaining bit is the valid_address utility, which is much more difficult to remove because it's so pervasive (used by the "address" option in every interface type).

The root cause is that /config is not mounted on livecd anymore, due to the difference in startup scripts.

Ok, the issue is that StrongSWAN uses different format for SAs with zero and non-zero counters!

@jakevis This exact config works for me in rc9. Could you update and re-test?

This should have been resolved by https://github.com/vyos/vyos-build/commit/2896acaf144a6091576e10b65e477ea35243b3c2

I could not reproduce it, in its simplest form:

It is a known design weirdness. That command is "set interfaces tunnel tun0 parameters ip bridge-group bridge br0". Don't ask why. We should make the CLI more intuitive some time, but the functionality is there.

@arne I think it's a sensible workaround. It's an interesting design question whether we should escape backslashes in config output.

I've verified that it writes the grub.cfg correctly now.

The daemons package is in the rc9. Could anyone test in Hyper-V if it works as expected?

I'm putting this on hold until we receive a reproducible procedure for testing this.

I hope 256 will be enough for everyone. ;)