Should be in the latest rolling or here: http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-13_all.deb

The client status file information is quite different compared to the one from a server config, I couldn't find a way yet to retrieve the information for the table.

@zsdc Is it working for you with the package above?

@zsdc All right, http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-wanloadbalance/vyatta-wanloadbalance_0.13.70+vyos2+current1_amd64.deb should solve the issue you are seeing. The code of the binary is good for another dozen bug tickets =)
Pls let me know if it works as expected, since I only tested your particular use case.

LBDecision::execute(): applying command to system: iptables -t mangle -A WANLOADBALANCE_PRE -i eth1 --proto all --destination ! 192.168.0.0/16 -m state --state NEW -j ISP_eth1
Bad argument `192.168.0.0/16'
Try `iptables -h' or 'iptables --help' for more information.
LBDecision::execute(): applying command to system: iptables -t mangle -A WANLOADBALANCE_PRE -i eth1 --proto all --destination ! 192.168.0.0/16 -j CONNMARK --restore-mark
Bad argument `192.168.0.0/16'
Try `iptables -h' or 'iptables --help' for more information.

Happens in /opt/vyatta/sbin/wan_lb.

Thanks for testing. New rolling has been built as well.
https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201902142225-amd64.iso

Please test http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-wanloadbalance/vyatta-wanloadbalance_0.13.69+vyos2+current1_amd64.deb or latest rolling release.

@thinkl33t Please test the latest rolling which has openvpn2.4 installed.

Nope. The function gethostbyaddr() is a libc function. What you can do is to try to reproduce the issue under debian 8 (jessie).
The crash in the zabbix ticket however is that the zabbix proxy is crashing when it received 3123 byte from 10.255.0.1.

Ok, so that issue has been corrected, I used the wrong validator. (https://github.com/vyos/vyos-1x/commit/1842fc9fdbcfa877e42714eaf620dff18ff9859c)

Hmm, that (the IP validation) was a different change which was working. I'll have a look.

looks to me like a classic buffer overflow on the zabix agent.

• vyatta-webgui removed from vyos-world (https://github.com/vyos/vyos-world/commit/dc9588ad4b49cc8f122075a2b6fe748e2f31af9c)
• vyatta-webgui removed from vyos-build submodules (https://github.com/vyos/vyos-build/commit/730f30c45fb0c1e5f5cb7576c54798941980a9d1)

All right, let me know if you need help.

@thinkl33t Can you please test?

Hmm. That's weird, I tested some rolling releases and 1.2.0, directly connected and via 5 hops, I can't reproduce what you see. If your crypto is ok and you have the the interface up and running, there won't be an issue. I would also see way more bug tickets here. So , I still believe yoru setup is incorrect, however it's hard to say where it fails. If the wg interface has no incoming and outgoing traffic, it's most likely routing. If inside the wg interface traffic goes out but is not answered but received on the upstream interface, somet6hing is wrong with the crypto. In your sho interface output is shows that traffic is being sent, but nothing recveived, that means the traffic you receive on the WAN side can't be authenticated, so that is an crypto issue. Either the traffic can't be decrypted or there is no existing setup for this public key. If the public key fits, then you can always decrypt with with your private one.

@Maltahl That smells more like an issue with your key setup. The wg interface listens on any interface which is up and running. If the traffic inside the wg interface doesn't show anything, that means it can't decrypt the traffic with your private key.

Tested the config above with in 1.2, no issues found. Not sure what it is yet, but it looks like that either the traffic doesn't really reach the destination (aka endpoint) or vice versa. Awaiting some show output to check the key config etc.

@Maltahl You can use any rolling, I made an enhancement yesterday to disable peers, but other than that the code hasn't been touched for a while. If the rolling release works, I need to have a look into 1.2.0. I tested with your config above and everything was working as expected, but I'm around today so feel free to ping me on slack in 1hr.

@Maltahl Let me know if you still need help, please. I put the task meanwhile on-hold.

http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-12_all.deb next rolling release has it.

Hmm, I have 7.1-dev-1~debian8+1 on a rolling and 3 blackhole routes and no issues at all.

@Maltahl Did you try the same with the rolling release? I don't see any issue with your config in particular, did you check that the wg traffic is actually getting to your router02?

@thinkl33t Would you mind testing your use case with https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201901312041-amd64.iso or later? This iso is using the bpo package of openvpn (2.4.0).

@thinkl33t http://dev.packages.vyos.net/repositories/current/vyos/pool/main/o/openvpn/openvpn_2.4.0-6+deb9u1~bpo8+1_amd64.deb

http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-11_all.deb or next rolling release will have the fix.

Fix: https://github.com/vyos/vyos-1x/commit/2f70340179a64d5936c32cc3c0d6d7f6f04054d0 applied, pkg build currently running.

Bug confirmed.

I can't replicate it, but I'm using also the rolling release.
Can you please provide the output of:

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