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

Glad to hear it @svd135 @swanduron

@svd135 can you try on latest rolling?

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

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

Not an issue on 1.5 with Kea.

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

This does seem to be new behaviour introduced with Kea. ISC dhcpd did previously assume local distribution of a subnet based on the interface having an address within the subnet, Kea has changed to require this being explicitly defined.

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

In T5835#172989, @dylanneild wrote:

@sdev Quick question on this issue.

In order to make miniupnpd work with the VyOS firewall as it is presently configured (dedicated ip and ip6 tables), I've had to make a fork of miniupnpd. This is due to the miniupnpd folks effectively declaring that inet tables are "the way it's all going" and effectively removing any ip and ip6 table use in the daemon.

I've tested with the stock miniupnpd to try to implement all rules in a single inet chain, but this creates a problem where, per my comment above, the default-action drop steps on the miniupnpd table, and I'm back to square one.

Using my fork of miniupnpd, I've tested extensively and can see everything working with VyOS IPv4. Rules can be added, checked, and removed without issue. Secure mode works, etc. The fork itself is a fairly small patch; it just reverts some calls in the nftables code to use NFTPROTO_IPV4 rather than NFPROTO_INET for filter and NAT rule changes so as to target the correct table variants.

I can test IPv6 pinhole, which I think can still work using the ip6 tables as-is (my patch doesn't change this at all), but I'd have to setup some tunnelling to validate it as I don't have native IPv6 at my house.

So, my question is: how open is VyOS to using forks of packages as opposed to just pulling them in from Debian?

If not at all, this patch may be at a dead-end unless someone has a clean way to avoid the default-action drop using only priorities (the nftables documentation maintains this can't work)? I considered using meta marking but that would also involve patching miniupnpd to apply the marks to rules matched by it's firewall additions and then modifying VyOS to not apply the default drop when the mark is matched; but that seems a lot less clean.

Sounds like a great solution to me, happy to review your PR.

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

In rVYOSONEXee494c3a1dbf#958480, @workingagain wrote:

In rVYOSONEXee494c3a1dbf#958479, @sdev wrote:

Are you able to provide the dhcp config that fails migration? I wasn't able to re-create any migration problem in my tests

set service dhcp-server hostfile-update
set service dhcp-server shared-network-name LAN option name-server '192.168.1.1'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 lease '86400'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option default-router '192.168.1.1'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option domain-name 'localdomain'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 option name-server '192.168.1.1'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 start '192.168.1.9'
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range 0 stop '192.168.1.254'

same as whats in the old quickstart guide

In rVYOSONEXee494c3a1dbf#958453, @workingagain wrote:

when migrating from pre subnet-id builds to a subnet build will cause migration failed during initial startup due to missing subnet id.

During a boot that raises the migration error, can you alter the grub boot command to add vyos-config-debug? See https://docs.vyos.io/en/latest/contributing/debugging.html#kernel

Backported: https://github.com/vyos/vyos-documentation/pull/1237

Closing this as resolved, please re-open if any further issues found.

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

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

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

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

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

PR for scoped options and bugfixes: https://github.com/vyos/vyos-1x/pull/2785

Is this still an issue on newer rolling images? This PR addresses ownership issues in /config on system update: https://github.com/vyos/vyos-1x/pull/2731

Can you provide your DHCP server config?

In T3316#167382, @indrajitr wrote:

• with set service dhcp-server hostfile-update the file /etc/hosts doesn't get update with any entry from dhcp at all

Thanks, will investigate this.

@sdev, this will require adjusting on-dhcp-event.sh. I have a hacky local version that writes to /etc/hosts that partially works -- the $domain part is not picked up (which I suspect could be related to how kea-dhcp4.conf is generating the FQDN).

Do you want me to raise a draft PR for you to review?

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

@Zen3515

• dhcp server doesn't start automatically after reboot, and due to the next problem, I'm forced to use set service dhcp-server disable then delete service dhcp-server disable after each boot

Could not reproduce this:

Welcome to VyOS - vyos ttyS0
...
vyos@vyos:~$ ps aux | grep kea
_kea        1818  1.6  0.9  67384 20324 ?        Ssl  00:14   0:00 /usr/sbin/kea-dhcp4 -c /run/kea/kea-dhcp4.conf

I think this regex needs to be made more strict to prevent this issue.