@jingyun Can you describe steps on how to reproduce it? Or re-check it.
My test config after reboot works fine

set interfaces bridge br0 member interface tun0
set interfaces tunnel tun0 encapsulation 'gre-bridge'
set interfaces tunnel tun0 local-ip '100.64.0.1'
set interfaces tunnel tun0 remote-ip '100.64.0.254'

PR https://github.com/vyos/vyatta-cfg-quagga/pull/81

https://github.com/vyos/vyatta-cfg-quagga/blob/fef5870b764e6166b639043fadb9317c8a49881d/scripts/bgp/vyatta-bgp.pl#L621-L625
https://github.com/vyos/vyatta-cfg-quagga/blob/fef5870b764e6166b639043fadb9317c8a49881d/scripts/bgp/vyatta-bgp.pl#L802-L806

In the crux.

set system conntrack timeout custom rule 10 destination address '203.0.113.74'
set system conntrack timeout custom rule 10 destination port '80'
set system conntrack timeout custom rule 10 protocol tcp established '300'
set system conntrack timeout custom rule 10 source address '192.0.2.168'

commit

vyos@r2-lts# commit
[ system conntrack hash-size 32768 ]
Updated conntrack hash size. This change will take affect when the system is rebooted.

It looks like your assessment is correct. It also seems like next-hop IP would be sufficient as well if I wasn't dealing with dynamic WAN IPs. For the moment I'm sticking with interface instead of dhcp-interface. The related issue you sent seems exactly related to this.

Clarifying as requested by c-po:

I believe I have found out why modification/deletion of rules fails. This is the rule definition in iptables:

I think it is also related https://phabricator.vyos.net/T3522

I have checked that functionality , i can replicate the issues .although there is a workaround if you "set protocols static table 11 route 0.0.0.0/0 dhcp-interface " any interfaces , it doesn't see in your table ( table 10 /11 ) we can see theses routes in the default table , let me show :

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

Hi @francis the latest FRR version lacks support for Cisco authentication https://github.com/FRRouting/frr/blob/master/nhrpd/nhrp_peer.c#L1212

@c-po with this merge on FRR https://github.com/FRRouting/frr/pull/8153#event-4589485067 is migration possible? Possibly related to https://phabricator.vyos.net/T2326

I wonder why this is flagged only as refactoring bit you open an entire new CLI tree.

Hi Jack,

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

Sorry for confusing with the status of the ticket , I wanted to put in pending . I was trying to replicate the issues in a lab environment but it wasn't possible , let me show :

I got it to work with version 1.4-rolling-202105291042. Here's the configuration that works:

@tuxis-ie found the issue. Used the wrong iptables chain. See https://github.com/vyos/vyos-1x/pull/864

@tuxis-ie thanks for testing this out. Will check this.

Please, backport it to 1.3 rolling https://phabricator.vyos.net/rVYOSONEX4b646c1fb31a1a9f9c9d1658734d478fed5f19f1

This bag is present in VyOS version 1.3-beta-202105271929

I tried to create a custom timeout rule for tcp port 80. First I assumed that everything was fine since the first commit succeeded without error messages. But when I wanted to alter the rule, it failed. Below you see an example where I first create a rule, and then try to delete it. Afterwards any commits regarding custom timeouts fails.

Yes, also this part will be migrated in the next couple of weeks as we plan to get rid of all legacy code in the 1.4 release cycle.