- User Since
- Feb 7 2016, 4:09 PM (137 w, 1 d)
Fri, Sep 21
Yes, quite an embarassing mistake. I'm working on it.
Mon, Sep 17
Sun, Sep 16
Fri, Sep 14
I've fixed it by adjusting the syntax for new StrongSWAN. The new way to do it is arguably better than it used to be, but I still wonder why the old syntax had to break. The fix is in 0.12.45+vyos2+current2 and should be in tomorrow's nightly build.
Sun, Sep 9
Sun, Sep 2
I think it's best done at the same time with IPsec CLI rewrite.
@c-po You've found a workaround, right?
Have people tested it? Please reopen if it doesn't work.
Moving to 1.3.x, let's combine this with dropping pre-6.5 compatibility and removal of old migration scripts.
Moving to 1.3.x, since there was no deprecation warning. Let's do it properly.
Sat, Sep 1
Mon, Aug 27
Sun, Aug 26
@UnicronNL also likes constellations, so let's go with it.
Aug 25 2018
FRR changed quite a few commands here and there, most are easy fixes indeed.
Aug 23 2018
Aug 11 2018
Aug 9 2018
if the interface gets delete from the config, the wg device gets deleted from the OS and all its routes
This is exactly the reason why "set protocols static ..." commands use zebra instead of pushing routes directly to the kernel with iproute2. Zebra takes care of interfaces going up and down and reinstalls the routes when needed.
Now, is that suppose to happen automatically ( i can include it in the wireguard.py script), or is it supposed to be setup via 'set static proto ...'? What would be the better way?
If wireguard cannot create routes on its own, I believe we should leave route setup to the user. Doing it automatically when it's not actually supported is a very leaky abstraction.