@c-po imported and test against latest rolling, I couldn't find any issue with 2.4.

@c-po it only affects clients which enforce tls 1.0 or 1.1, at least what I have tested. The perl code needs quite some rework, so I think I split the task into getting a newer release of openvpn into the build. Newer versions have tls 1.0 and 1.1 disabled per default from what I have read, so I think it might be more a changelog announcement that with the new version only tls 1.2 is automatically supported and you have the option to enable weak ciphers via opt .... or so. I'm not too sure yet, I think I have to wait a little on the response once the newer version is in rolling and the feedback I receive.

Done. https://github.com/vyos/vyatta-nat/commit/98ce64bc3c73118c8e909173da460501ca6cabf1

Perfect. Merged: https://github.com/vyos/vyatta-cfg-firewall/commit/23447bef89a46f44d7544f15c2755d33f38ffd4c

In T1051#27092, @c-po wrote:

set interfaces openvpn vtun0 disable-weak-tls-ciphers

@Merijn Have you tested your changes already? I was only bale to find https://github.com/vyos/vyatta-cfg-firewall/pull/12 which only contains the ip6tables targets, did you send PRs for systctl too?

@syncer Currently we ship in the iso openvpn from main, we could use it from bpo which would be 2.4 (2.6 is the latest), or we replace it with a self-compiled 2.6, or do you just want cpo's solution implemented?

Rebuilding iso, once it finished it will have the correct version.
[...]
Get:152 http://dev.packages.vyos.net/repositories/current/vyos/ current/main libvyosconfig0 amd64 0.0.6 [841 kB]
[...]
Will test it from the iso, just for peace of mind.

Dev.packages has 0.0.06, so something goes sideways during build process, I will work on that and test. I'll take the task back and close it when resolved in ci (looking into it right now). I manually installed the package and everything works as expected.

Still same issue on 1.2.0-rolling+201901250337.

Nice! I will test it tomorrow for sure.

Anyone?

Found the bug, https://github.com/hagbard-01/vyos-1x/releases/download/1.2.0-10/vyos-1x_1.2.0-10_all.deb should fix it. As soon as You guys can confirm, I push it upstream.

@c-po All right, found it. Try it without arguments, then it ends up just as */5 * * * * root /usr/bin/logger which causes the issue. That shouldn't be too hard to fix, the existence of the cronjobfile after a reboot without the save command however is a longer journey.

Thanks that helps, I gotta review. Remote authenticated users would act like local ones by the way, pam would resolve it or if it can't be resolved, con exits with 1.

@c-po
*/5 * * * * cpo sg vyattacfg "/usr/bin/logger foo"

I had to pass on libvyos and OCAML, just reading and understanding a few lines took me forever. What would be the fix?

Issue sits somewhere in vyos.configtree

All right, can you please test: https://github.com/hagbard-01/vyos-1x/releases/download/1.2.0-10/vyos-1x_1.2.0-10_all.deb

OK, so the issue happens only if a) the cronjobs was executed by root and b) it modifies the config (which gets then rewritten via union-fs). I created another user called test01, the user vyos has a cron job in his name, regardless what user (test01 or vyos) the script runs, all stays healthy. As soon as the script is triggered via root, you can't set anything in your running config due to the permission changes I wrote yesterday.

Thanks for confirming. With 2 users, you may encounter always the issue that a cronjob locks up your ability to change the config afterwards. For now the manual workaround should help you, I'm going to revert my changes from yesterday and return to the drawing board.

Thx for testing.

Fixed via T1181

I wouldn't execute a scheduled script. Thats all. Do you recreate then a different user? Since all users have admin privs, the probem with the change permissions will persist. Actually makes it works, one user can block the other. So, I have to find something else out.

@cpo it would just exit 1. I gotta look into the possibility to see the commit user, I was under the assumption that the vyos user always exists. If there are multiple (at least 2 different) and the cron runs a root or the user (the one which did not setup the job), it will disable any config for all other users, since the filesystem permissions change. ACL's would be something which can solve it, but I have to verify it. I'll keep this task open to track it. Do you just replace the vyos user, or are you using root only in your config?

@yun can you please test with the latest rolling?

@kroy install http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-10_all.deb and try again, I have the changes in that package and tonights rolling will have it too. I couldn't find anywhere a requirement that the cronjobs need root, so I switched it to always run as vyos which keeps the file system permissions intact. Test it on a test machine first, but it should now do what you want, I used your script code from above, but didn't have any real ospf adjacency with any other route, but that shouldn't matter at all. Let me know the results please.

OK, I think I found it, however so far I can only give you a quick workaround rather than solving it.
Short explanation, if you setup cron, your script is executed as root which changes the permissions for the configs on union-fs and the directories, that's why already a set fails, it can't simply write as user vyos to the directory.
To get your stuff working, try the following (preferably on a test box, I used the rolling from tonight but any 1.2 image should work if it's not older than 3 months or so)

The 'commit' causes the issue, but right now I'm not sure why.

In T1178#30992, @kroy wrote:

@hagbard Note that a reboot does fix the ability to edit configuration again until the next time the cron script runs.

I'm going to implement it into the configuration, which will assure that is it going to be the last step executed after a reboot.

wireguard identifies peers on their key, improve the command for sh int wireguard wg01 peers etc. so that the peer name from the config is visible as well.

@ekim https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201901181924-amd64.iso should address the dhcp issue, can you please test? I only tested on VMs yet.

@yun https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201901181924-amd64.iso should address that issue, can you please test? I only tested on VMs yet.

pending ci netplugd integration, local tests were quite successful, I think it can be release into rolling in the next few days.

http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-vmwaretools-scripts/vyos-vmwaretools-scripts_1.0-1_all.deb

T1181 will fix that issue.

All right @ekim I have that feature working in an experimental package. If you want to test it you can build it from here:
https://github.com/hagbard-01/vyos-netplug via dpkg-buildpackage -b -tc -uc -us and install it on any rolling iso. I used the latest for my tests, but it should work on older ones too. It will still take a little time to have that pushed into the normal build process, since it requires some integration work.

@ekim Yeah, that is a known issue I was looking into a while ago already. disable/enable in eth interfaces should now work in the latest rolling, the plug-in and unplug will still need a little. I'll keep this task here open for it.

I think I know what you mean now, it also starts translating the global address on the external interface. Can you send a PR for the changes you've made please?

At the first quick review it works:

@Merijn I haven't added anything. I just tested nptv6 and it was working as expected. I used your setup you have initially posted, I just used a different interface for the outgoing traffic. I confirmed via tcpdump that NAT did work.

@ekim I think I found it. When I put the interface into disabled mode and then delete disabled, the dhcp client isn't started anymore if the address is supposed to be received via dhcp, correct?

Have you checked on the server DHCP server side for issues?

I've tested it without doing anything on the code and everything is working properly.

That's all to test. I did test it based on the config you provide above, I just want to see if there are any corner case I did not consider.

I got a bit further. uacctd seems to have an issue, I started manually pmacctd on pppoe0 and everything is working well. Uacctd shows that it gets hit with something when I check via strace, but it doesn't show anything.

merged and closed on @kroy 's behalf. (https://phabricator.vyos.net/R5:749d923ee9704624a476bef17d66d752aff6bf0d)
thx @kroy

The latest rolling has now 'net.ipv4.conf.all.send_redirects = 0', can you please test if that would solve that issue?

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?

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

Sorry for the delay @Barrysdca , please test the rolling release January 8th. or alternativly you can install http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-cfg-system/vyatta-cfg-system_0.20.44+vyos2+current17_amd64.deb as well, which should fix the issue.
Please provide feedback as soon as you can, I tested the config you have posted above and everything appears to be working well now with the new package.