Not too sure what I'm supposed to do here, I added noquery notrust, but everything else looks pretty good.

@syncer send hostname is automatically set, so not sure if that task is still valid. (see: /var/lib/dhcp/dhclient_eth0.conf).
The value is taken from hostname.
However dhcp has a ton of client options (https://tools.ietf.org/html/rfc2132), implementing all of them or just a portion and make them configurable, means the rewrite of th dhclient scripts, which I think is overdue anyway.

@Maltahl Do you receive the udp packets now?

Thanks, sounds good.

Since it's not a wireguard issue rather then a network issue between both systems, I'll remove it from 1.2 and put it into 1.3 .

Yes, I agree it's a good idea. In general, the openvpn package has ipv6 support already, the only missing part is rewriting the vyatta code to enable the user to actually use them.
I think we can close this task here and you may want to open a new request for rewriting the openvpn code, which will happen at one point in the future anyway. Another option would be that you rewrite the backend. I don't use openvpn, so I don't have a lot of experience with it.
Let me know what works for you best.

Gotcha. I merged your PR.
PLease test with: http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-openvpn/vyatta-openvpn_0.2.60+vyos3+current2_all.deb

That information is not easily visible, never been according to the openvpn folks.

Do you see now the udp arriving on both sides?

@varesa so 'server push-route x.x.x.0/24' does work for you?
The double quotes are an issue with the parser and I doubt that if will be allowed in the future again.

@Maltahl any news on the traffic via vlan?

Can you share your config please, with the statement that breaks your config. thx.

That should be already in there for a few days now.

@fromport does the new pkg solve the issue you are seeing? It did during all my tests.

The wg traffic from host1 never reaches host 2, therefore wireguard can't function. Suggested to investigate the infrastructure to see if the traffic leaves actually the premises. Will put the task on hold meanwhile.

Awesome, thx.

@oleksandr.ovsiannikov any updates?

binaries (lcdproc, lcdproc-extra-drivers) added to rolling releases.

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