@fromport http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-openvpn/vyatta-openvpn_0.2.60+vyos3+current2_all.deb or next rolling release (Feb 23rd).

@fromport http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-3_all.deb or Feb 23rd rolling release. If it's urgent I can trigger a build for you.

Will test with the next rolling before I close off the task.

https://github.com/vyos/vyatta-openvpn/commit/9166dde7fd5ca7b313de585067b06af6a8b9c82a Should be in the next latest rolling, can you please test?

Yeah, I agree.

We should NOT backport this to VyOS 1.2 crux

/opt/vyatta/share/vyatta-cfg/templates/system/static-host-mapping/host-name/node.def writes the entry, I think the functionality should be integrated into host_name.py. I contacted @c-po to hear his opinion.

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?

In T1247#32887, @oleksandr.ovsiannikov wrote:

@hagbardIt fixes the issue with WANLOADBALANCE_PRE chain, but we still observe unexpected behavior.
I will write a little bit more letter.

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: