op-mode: https://github.com/vyos/vyos-1x/pull/2242

100% agree. If this isn't too big of a hassle to implement, I would very much appreciate the approach/workaround of @Apachez, until nftables supports this feature ootb...

Checked with #netfilter irc-channel.

I just tested this with a firewall config with no connection tracking config enabled, still the conntrack modules are loaded and used.

The same situation as @svd135 . The passive FTP data connection now is stopped by the problem with FTP ALG.

I was thinking about N/D and personally I would prefer "None" to be listed for the various "show firewall" commands instead of N/D.

Resolved by: https://vyos.dev/T5564

This can be put to resolved when the backports are confirmed aswell.

N/D == not defined

In T5564#159459, @Apachez wrote:

Confirmed working with VyOS 1.5-rolling-202309110651

A question before setting this to resolved:

What does N/D mean?

Shouldnt it be N/A instead?

Confirmed working with VyOS 1.5-rolling-202309110651

Im a bit allergic to have stuff automatically created which clearly is not enabled by the config.

pim6reg is created by FFR's pim6d. It seems to me that it will create such as interface for each VRF. Does this interface have any functional impact on your setup?

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

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

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

set protocols static proxy-arp 192.0.2.1 interface eth0
set protocols static proxy-arp 192.0.2.1 interface eth1
set protocols static proxy-ndp 2001:db8::1 interface eth1

I dont know if its related to this task but I noticed recently that even if I have no IPv6 configured on any interface and have IPv6 disabled for forwarding:

set system ipv6 disable-forwarding

I can in VyOS 1.5-rolling-202309080021 see an additional pim6reg interface!?

vyos@vyos:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master MGMT state UP group default qlen 1000
...
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master INTERNET state UP group default qlen 1000
...
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master INTERNET state UP group default qlen 1000
...
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq master INTERNET state UP group default qlen 1000
...
6: pim6reg@NONE: <NOARP,UP,LOWER_UP> mtu 1452 qdisc noqueue state UNKNOWN group default qlen 1000
    link/pimreg 
7: INTERNET: <NOARP,MASTER,UP,LOWER_UP> mtu 65575 qdisc noqueue state UP group default qlen 1000
...
8: MGMT: <NOARP,MASTER,UP,LOWER_UP> mtu 65575 qdisc noqueue state UP group default qlen 1000
...

Its also visible when running:

monitor bandwidth interface *

Latest run https://github.com/vyos/vyos-rolling-nightly-builds/actions/runs/6138721359/job/16655876943

table ip raw {

ct helper rpc_tcp {
        type "rpc" protocol tcp
        l3proto ip
}

Oh sorry, I missed that this commit was for LTS 1.3.x series.

@Apachez I am running kernel 6.1.49-amd64-vyos and this works fine with my local setup.
The patch is already in linux kernel since at least 4.3 (you can confirm with https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/include/net/netfilter/nf_conntrack_zones.h?h=linux-4.3.y), but it was added to nft command only since Feb 2017: https://git.netfilter.org/nftables/commit/src/ct.c?id=ed66d9966294a3bab6c8611e369861ba57374743

Fix by @sever regarding those failing conntrack smoketest: https://github.com/vyos/vyos-1x/pull/2234

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

@vfreex the referenced netfilter patch is from 2015, is that really valid for current version thats included in the Linux 6.1 LTS kernel?

You can test this approach on a running VyOS router using following commands:

I created a PR to fix this issue by using direction parameter of conntrack zones: https://github.com/vyos/vyos-1x/pull/2236
I have a very basic VRF setup and it works fine. It would be much appreciated if someone could test this with more complex VRF setup.

Sorry to bother you @sdev , the latest releases of 1.5-rolling-202309080021 and 1.4-rolling-202309070021 still have this problem.

Added backport for FRR 7.5 https://github.com/FRRouting/frr/pull/14381

I guess we should use the current ip neighbor xxx instead of old arp. I hope it does the same.

sudo ip neighbor add proxy 192.0.2.1 dev eth0
sudo ip -6 neigh add proxy aa::1 dev eth0

Show

vyos@r1# sudo ip neighbor show proxy
192.168.122.11 dev eth0  proxy
192.0.2.1 dev eth0  proxy
aa::1 dev eth0  proxy
[edit]
vyos@r1#

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

The failed smoketest test_interfaces_ethernet.py can be seen at:

The failed smoketest test_protocols_pim6.py seems to have been taken care of by:

Regarding the failing smoketest test_system_conntrack.py (test_conntrack_ignore):

https://github.com/vyos/vyos-1x/pull/2233 to fix the smoketest.

In T5518#159341, @Apachez wrote:

Something is broken in smoketest test_protocols_pim6.py:

https://github.com/vyos/vyos-rolling-nightly-builds/actions/runs/6133954453/job/16646294279

See "Run smoketests" line 28676 and forward.

Something is broken in smoketest test_protocols_pim6.py:

Still errors in: