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.

@SrividyaA Can you confirm this is working as you expect?

@a.apostoliuk Can you confirm this is working as expected?

If you don't use the firewall (statefully at least) then it will go through the FW_CONNTRACK chain and the NAT_CONNTRACK and/or WLB_CONNTRACK chains will be reached, or fall through to the notrack.

That is how the conntrack enabling system works. FW_CONNTRACK verdict is set to accept when it is determined the firewall needs conntracking (state rules, flowtable etc.), same for NAT_/WLB_ chains. If none require conntrack - all chains will be return and it falls down the chain to the final notrack and conntrack is not enabled.

Not sure what to do on this one. The firewall is depending on conntrack module, which updates the conntrack related sysctls. It'd be the same if someone defines custom sysctls used by other conf scripts.

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

PR removing zone-policy op-mode: https://github.com/vyos/vyos-1x/pull/2304

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

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

This is likely also the issue causing T5376

In T4502#160404, @Apachez wrote:

Perhaps a possible way to detect if the nic supports hardware flowtables or not.

Try to set sudo ethtool -K eth0 hw-tc-offload on.

If the result becomes:

Actual changes:
hw-tc-offload: off [requested on]
Could not change any device features

Then it doesnt support hardware flowtables.

Could also verify by reading the capability like so:

$ ethtool -k eth0 | grep hw-tc-offload
hw-tc-offload: off [fixed]

Fixed in PR: https://github.com/vyos/vyos-1x/pull/2276

https://github.com/vyos/vyos-1x/pull/2272 should fix this

@fernando See here: https://github.com/vyos/vyos-build/pull/297

Builds passing: https://github.com/vyos/vyos-rolling-nightly-builds/actions/runs/6142937552

current PR: https://github.com/vyos/vyatta-cfg-system/pull/205

Can we see the output of sudo nft list table ip raw on an affected router?

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

current PR: https://github.com/vyos/vyos-1x/pull/2217
1.4 PR: https://github.com/vyos/vyos-1x/pull/2218
1.3 PR: https://github.com/vyos/vyos-1x/pull/2219

@svd135 Can you provide a version string when you last had it working? Seeing the firewall config might also be helpful.

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

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

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

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

@csszep Yes it is expected, IPv6 has no sysctl and requires the nftables rule to function. The nftables execution is slightly slower, so there's no benefit to change it for IPv4.

@tjjh89017 This will need to be re-evaluated. The build from your PR was taking in excess of 8 hours on the build server - the defconfig likely needs to be brought down to only the minimum required modules/drivers for successful builds on target devices.

This does still need to be addressed in 1.4. Without a version string, the 2-to-3 migrator is adding the conntrack helpers to the default config.

Duplicate T3275

The kernel modules handle tracking of those, rpc/tns are userspace helpers.

They are only defined. Only when the VYOS_CT_HELPER chain is reached will they take effect - see links in my above comment. Being in the default config will have no effect on connection tracking if bypassed by the notrack rule.

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

They are created but unused by default (see VYOS_CT_HELPER chain)

Thanks for following up on this issue @rayzilt

Closing as dupe of T5080

PR to fix indentation: https://github.com/vyos/vyos-1x/pull/2171

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

I did start writing support for this but didn't have time to build and test it at the time. If anyone wants to test it out: https://github.com/sarthurdev/vyos-1x/commit/9199b75d75ceea3b7d49f0e3d71a19175b7b1326

In T5160#156025, @Apachez wrote:

2.2: Invalid shall ALWAYS be processed BEFORE established/related/other rules otherwise it will not serve it purpose.

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

@syncer Will address this after T5160 is merged

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

Should be possible when new refactor is merged: T5160

This would have to be handled with DNS and not in the firewall. Hostnames work on firewall because they are resolved prior to use in rules.

It might be a boot/slow DHCP lease issue.