- User Since
- May 25 2018, 2:31 AM (38 w, 4 d)
It also overwrites resolv.conf without checking if dhcp already set it up.
Tested it myself and can't find any issues.
No idea what that could be, it's for sure a config problem since many others use it as well as myself with no issue at all. Is there any way I can access your env?
Fri, Feb 15
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?
Thu, Feb 14
@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 =)
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.
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.
Wed, Feb 13
@thinkl33t Please test the latest rolling which has openvpn2.4 installed.
Mon, Feb 11
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.
Sat, Feb 9
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)
Fri, Feb 8
All right, let me know if you need help.
Thu, Feb 7
@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.
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.
Tue, Feb 5
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.
Mon, Feb 4
@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.
Sat, Feb 2
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?
Fri, Feb 1
Thu, Jan 31
@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).
Wed, Jan 30
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.
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.
Can you please set it up in ci? I'll take it from there once set up.
@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.
Tue, Jan 29
@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?
Mon, Jan 28
@syncer Currently we ship in the iso openvpn from, 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?
Sat, Jan 26
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.
Fri, Jan 25
Wed, Jan 23
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.
*/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?
Tue, Jan 22
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.