PR: https://github.com/vyos/vyos-1x/pull/2123

The same bug was with ipoe-server https://vyos.dev/T5283
It is the actual address x.x.x.0 for UNIX devices and PPP interfaces, but it could be issue work Windows clients
There is a simple fix https://github.com/vyos/vyos-1x/commit/8a79769bf447cb18d456f061afd6a7997b8264f8

I'm sorry.
I tested this is VyOS 1.3.3.
I tested mutliple configurations, from subnet /23 all the way up to /32 with the command "set service pppoe-server client-ip-pool subnet <x.x.x.x/x>"
After setting the subnet i'd connect multiple clients to VyOS and check wether all the available IP addresses were used, and they were.

PR: https://github.com/vyos/vyos-1x/pull/2121

Which version?
Which tested config? Which generated config?
It would be more clear if you provided tangible examples.

Just to sync this task to PR 2118:

As mentioned in https://vyos.dev/T5419 the offloading should not only apply for NAT.

Duplicate of the task https://vyos.dev/T4502
And there also a PR https://github.com/vyos/vyos-1x/pull/2062
It is waiting for merging firewall refactoring

This particular case was resolved by adding:

For "show dhcp client" command https://github.com/vyos/vyos-1x/pull/2120

I added this comment to PR 2118:

A not too uncommon workaround for this is to disable the lease-file (if possible) and give out leases based on option82 information instead.

Is this a limit of wireguard?

I'm using the *-parameters in isc-dhcp to manage ddns updates to an external nameserver. This way dns-entries supplied by dhcp-server will be kept in sync, even when using dhcp-failover.
I would love to still be able to keep this functionality with Kea in some way. Either by providing corresponding custom-parameters, or adding native support for this scenario.

I have submitted PR 2118 for this issue.

PR: https://github.com/vyos/vyos-1x/pull/2117

You skip this warning and delte version number line

// Warning: Do not remove the following line
// vyos-config-version: "bgp@4:broadcast-relay@1:cluster@1:config-management@1:conntrack@3:conntrack-sync@2:container@1:dhcp-relay@2:dhcp-server@6:dhcpv6-server@1:dns-dynamic@1:dns-forwarding@4:firewall@10:flow-accounting@1:https@4:ids@1:interfaces@29:ipoe-server@1:ipsec@12:isis@3:l2tp@4:lldp@1:mdns@1:monitoring@1:nat@5:nat66@1:ntp@2:openconnect@2:ospf@2:policy@5:pppoe-server@6:pptp@2:qos@2:quagga@11:rip@1:rpki@1:salt@1:snmp@3:ssh@2:sstp@4:system@26:vrf@3:vrrp@4:vyos-accel-ppp@2:wanloadbalance@3:webproxy@2"
// Release version: 1.4-rolling-202307090317

I've recently migrated from a PCEngines APU2C4 to a Wyse 5070 with a X520 card, as well as upgrading to VyOS 1.4-rolling-202305081003
After which I was unable to reproduce this issue. Roaming now works fine without the ICMP check.

PR:
https://github.com/vyos/vyos-1x/pull/2116

It is a bug that it’s on by default, see other task. Will be fixed after new firewall refactor is merged.

From the VyOS documentation and https://community.openvpn.net/openvpn/wiki/DataChannelOffload

Then how come conntrack modules are loaded (and there is content in the ruleset "sudo nft -s list ruleset") when I have no firewall rules configured?

CLI adjusted to:

Conntrack should be disabled by default https://vyos.dev/T5080

It is not a bug.
It is the implementation of TACACS authentication https://github.com/vyos/vyos-1x/pull/2038
https://github.com/vyos/vyos-1x/blob/fa07179ae7f1dc07e6ccc1b20d2b81384b6efe07/debian/vyos-1x.postinst#L47-L52

Tested and verified as described in the pull request:

Thanks for testing and submitting PR

Pull request created: https://github.com/vyos/vyos-1x/pull/2112

There is this line in the code https://github.com/vyos/vyos-1x/blob/688755a988e233e221bf920e391e35d5ddc9cb56/src/op_mode/show_ntp.sh#L21

https://github.com/vyos/vyos-1x/pull/2111

@c-po just added the sudo on a live box to test the changes and I can confirm that fixes it. No auth prompt when doing a load config.
Now I did notice that every time I do a load config it runs that migration script which stops/starts the container which is not ideal.

I can confirm that altering line 21 as suggested fixes this issue.

We probably wan't to load/unload the Kernel Module given what the user want's to do

https://github.com/vyos/vyos-1x/pull/2110

Out of the blue it seems like "network namespaces" would solve alot of current VRF compatability issues within VyOS:

Workaround until "system name-server" becomes vrf aware seems to be to change context into vrf INTERNET and then do a ping with VRF syntax like so:

I would vote for:

PR: https://github.com/vyos/vyos-1x/pull/2108
PR: https://github.com/vyos/vyos-build/pull/372

Can you check changing