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

Did anything happen to the github integration?

Will just setting it to =n solve the problem?

@oliko Could you retest it with rc9, which uses a 4.19.4 kernel?

Apparently we do not have phabricator integration setup for the ipaddrcheck repo, since it didn't pick this commit up: https://github.com/vyos/ipaddrcheck/commit/21c0775c51da1ca3d4ef6506fca82bce5b334c79

This should have been resolved by T956, but if it reappears or the fix turns out incomplete, feel free to reopen.

Since most of the work is done and every release candidate of 1.2.0 has been using FRR already, I suppose we should close it. Remaining issues that are causes by FRR incompatibilities should, and are getting their own tasks anyway.

Is the root hints file included in the package? I can't find it. Or it has a built-in list of root servers?

Since the fix is far from trivial, a workaround exists, and the entire PBR subsystem is due for a rewrite in the next release, I'm moving this to 1.3.x.

This issue existed in Quagga as well, so I'm simply disallowing decimal notation.

@Line2 Could you attach the IPsec config and the output of "sudo ipsec statusall"?

Good idea, thanks! I've applied the patch and will push it shortly.

A long standing problem indeed. StrongSWAN changed its output format, I cannot say it was for the better.

@rps Sorry for late reply. I would prefer a git format patch of course, but I've merged it by hand and it seems to work fine. It will be in tomorrow's release candidate and today's nightly build.

Looks like this was reported before we released the first version with 4.19 kernel. Please re-test with rc7 and let us know if you still have this issue.

I think I've fixed it enough to give it meaningful testing.

Deleting neighbors, as such, works, so we need an exact reproducing procedure.

Since WAN load balancing/failover is due for complete rewrite, perhaps it's better to move this to 1.3.0

It is not possible to use this exact syntax in FRR, and it's not possible to fake it in the current BGP script either. It is possible to add a new "interface" option to match the FRR CLI though.

Good ol' Occam says no. We already have a general mechanism for that, and I think as we rewrite code, we may want to get rid of the description fields that predate that mechanism.

I've also reported the issue to FRR: https://github.com/FRRouting/frr/issues/3309

The argument number in the command definition was wrong.

The last bit is blocked by https://github.com/FRRouting/frr/issues/3308 , but otherwise it's done now.

I couldn't reproduce the issue on my rc6 setup. We'll need exact reproducing steps.

The range feature is quite problematic since IPset doesn't really support ranges, and "ipset -A foo 192.0.2.10-192.0.2.20" really adds 20 addressed to the group "foo". Thus, if you add a range and then add a single address to that range, and then delete that address (or the range), your IPset setup ends up in an inconsistent state where that address is supposed to be there according to the VyOS config, but actually isn't.

I cannot reproduce it in rc6, either with zone-policy or without. I guess the pull request fixed it.

Good catch!