@tjh Any updates?
By the way there is a new option

vyos@r4# set service conntrack-sync disable-syslog 
[edit]
vyos@r4#

https://conntrack-tools.netfilter.org/manual.html#sync-aa

conntrackd allows you to deploy an symmetric Active-Active setup based on a static approach. For example, assume that you have two virtual IPs, vIP1 and vIP2, and two firewall replicas, FW1 and FW2. You can give the virtual vIP1 to the firewall FW1 and the vIP2 to the FW2.

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

In T6099#182627, @Viacheslav wrote:

@Giggum Can you check it in 1.5?

Yeah sure thing I can do that. Will I be able to roll back from the latest 1.5 to the version of 1.4 rolling I’m on after testing is complete or will the config mess up?

@Daya @trae32566 Any updates?

@indrajitr Can we close it?

@indrajitr Can we close it?

@Giggum Can you check it on 1.5?

It is easy to add
In FRR it looks like:

r4(config-rpki)# rpki cache 192.0.2.1 8888 
  SSH_UNAME   SSH user name
  preference  Preference of the cache server
  source      Configure source IP address of RPKI connection

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

set nat cgnat pool external ext1 external-port-range '1024-65535'
set nat cgnat pool external ext1 per-user-limit port '1000'
set nat cgnat pool external ext1 range 192.0.2.222/32
set nat cgnat pool internal int1 range '100.64.0.0/28'
set nat cgnat rule 10 source pool 'int1'
set nat cgnat rule 10 translation pool 'ext1'

For me personally this change makes sense: a router has multiple interfaces, the Source IP is selected in different ways, and especially for RPKI servers outside the network (public ones), this could even break connectivity. Vendors like Juniper had this issue and eventually added the option, which means probably VyOS will benefit too, especially since "it's just setting a value in FRR's config"™ (famous last words ;).

Yes and no. Even before I created this ticket, I tried a small test locally. Unfortunately, I was not able to get the tests to run (even without my changes).

@Loremo I think this contribution would be valuable. Have you made any progress with your PR?

Great 😃

Hi -- this works. The VTI interface is just another interface so you can add it to a firewall zone just as you would an Ethernet interface. This can be done with existing site-to-site ipsec VTIs today. I also do it with OpenVPN interfaces for remote access on some of my installations.

This would be really useful. As per: https://forum.vyos.io/t/other-than-console-how-to-pass-grub-parameter-pcie-aspm-off/14203

about vyos-1x:
current and sagitta don't use distutils, I found this only for equuleus
https://github.com/vyos/vyos-1x/blob/ae96118ec38c4064552889aea5e50023a66aac1e/src/conf_mode/nat.py#L21
https://github.com/vyos/vyos-1x/blob/ae96118ec38c4064552889aea5e50023a66aac1e/smoketest/scripts/cli/test_system_login.py#L23

We are currently using FRR segment routing set protocols segment-routing srv6
For now, it could be closed

fix for vyos-build: https://github.com/vyos/vyos-build/pull/549

They are signed with minisign now.

This will be handled by the redesigned flavor system soon (T3664).

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

Just wondering - is it possible to add a vti interface to a zone in the firewall?
How would one go about using this with the zone based firewall? 🙂

Does anyone have any thoughts on the best place to start adding this functionality / design ideas for this feature?

PR for Sagitta: https://github.com/vyos/vyos-1x/pull/3239

Try with:

Related to https://vyos.dev/T6080

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

this new command was merge in order to solved this problem :

vyos@vrf-test:~$ show configuration commands | match disable
set protocols bgp parameters disable-ebgp-connected-route-check

Always exclude this address from any defined range. This address will never be assigned by the DHCP server.

Ok, it will exclude in any range.
Forget about it

@ServerForge It is question for hsflowd
You can open the issue on their git repo

Its no longer failing to start, but it seems to be only capturing inbound traffic on the tunnel, no outbound. I'm also observing this behavior on vlan interfaces, IE bond0.10.

Proposed CLI:

set nat cgnat pool external <external> range 192.0.2.0/30 seq 1
set nat cgnat pool external <external> range 192.0.2.128-192.0.2.132 seq 2
set nat cgnat pool external <external> per-user-limit port 1024
set nat cgnat pool external <external> global-port-range 1024-65535
set nat cgnat pool internal <internal> range 100.64.1.0/24