Revert to the original config, since the tighter default restrictions make trouble with pooled addresses.
http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-12_all.deb

I'm going to revert the for default restrict

That's what I thought. Thanks for testing it.

@zsdc How quickly needs that to be resolved? It requires quite some work on the backend for the cli.

Ok, I resolve the IP during config time and wite it into the file, please note that it will be only 1 of the pool IPs, so it should work for you.
Please test: https://github.com/hagbard-01/vyos-1x/releases/download/v1.0/vyos-1x_1.3.0-11_all.deb and let me know if that works for you.

Interesting, it did work during my tests and my implementation was based on the offical ntp documentation.

thx for testing.

this and it's a global rsyslog option only. (https://www.rsyslog.com/doc/v8-stable/configuration/global/index.html)

Can you clarify please, I can't follow what you mean.

What about:
set system syslog global preserve-fqdn

@Dmitry here you go: http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-10_all.deb, or the rolling release created tonight.

@Dmitry Oh ok, I didn't see the trees in the woods. Yeah, that needs to be fixed, I see that I can squeeze it in today.

I didn't find any issues so far, aside from the fact that I think no one is using pptp anymore, I'll keep this task still open for a few days just to make sure the replacement was successful.

found in the old documentation that mppe is always set to the highest, will implement it as a config option with the default of mppe require.

available via latest iso (https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201903062146-amd64.iso)

All right, ready for the first release. I'll add a few more options for radius tuning which are currently set to static defaults values (like timeouts).

https://github.com/hagbard-01/vyos-1x/tree/T833

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.