@tjh If you have a test lab, can you check conntrack-sync in the latest 1.3?

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

@dongjunbo this is a very very basic PR for VyOS 1.4 with the goal to implement this into the main VyOS release.

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

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

Commands are implemented.

Thanks Chris I'll test it once available and let you know!!

Added command set service conntrack-sync interface <intrerface> port <port>

Fixed for 1.3 in commit https://github.com/vyos/vyos-1x/commit/21527ef4551613fe9b7eed9e4b2ce33ad46fe540

Fixed for 1.3 in commit https://github.com/vyos/vyos-1x/commit/21527ef4551613fe9b7eed9e4b2ce33ad46fe540 and T3535

I'm seeing the same behavior for the OSPF v2 configuration on the 1.4 train for an image built on April 26th 2021. Just a heads up.

PR for 1.3
https://github.com/vyos/vyos-1x/pull/904
https://github.com/vyos/vyos-world/pull/4

Source NAT Rules went Out of Range in VyOS 1.4-rolling-202107010320

Hi @c-po I hope you're doing great!

Should be resolved in PR: https://github.com/vyos/vyos-1x/pull/903

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

conntrack implementation changed form 1.3 -> 1.4 by a rewrite. Can you please tell us which version of VyOS you are using?

Looks good on 1.4-rolling-202107010537 and 1.3-beta-202106301443:

Should be addresses using the new vyos smoketest shim from 1.4 branch.

Please share your configuration.

Hi ruben

All of my neighbors are connected with me via wireguard interfaces (a different interface for every peering). I have no physical direct link with any peer.
All neighbors using IPv4 or ULA IPv6 addresses are working properly.

Please share your entire setup then somwe are able to help out.

i was referring to the FRR command as deprecated, not the corresponding VyOS command. The VyOS command is not even available in the last version of VyOS... I was able to try it only via vtysh...

please stop the idea of "deprecated" command. VyOS commands are in no relation to FRR commands.
If (and when) the FRR syntax changes, we will ensure it will still work by either migrating the VyOS CLI configuration dynamically on upgrade or by adjusting to the FRR configuration "under the hood" with our Jinja2 template.

PR https://github.com/vyos/vyos-1x/pull/902
PR https://github.com/vyos/vyos-documentation/pull/561

It seems that what I thought is true:

could this help https://patchwork.ozlabs.org/project/netfilter-devel/patch/776b8819c85c83088478b933a35691133055347a.1430733932.git.daniel@iogearbox.net ?

as I wrote on slack, from my point of view it is a kernel problem. It seems that the conntrack in the kernel detects the packets eben if they come in on an input interface in default and so
the nat code won'T match cause for conntrack the outgoing interface is still eth0 which is in vrf OOBM instead pppoe0.

Hi ruben,

upgraded to 1.4-rolling-202106290839 but still not working for my setup...

Is it worked in 1.3/1.2?

Hello @joeudes , it looks like without enabled ppp-option ipv6 it should not work

set service pppoe-server ppp-options ipv6 allow

the new build is already available. I am unsure if this works or is even supported by FRR.
Please consult FRR manual and try configuring this manually from vtysh.

@Viacheslav it is reproducible in 1.2.7

vyos@vyos:~$ touch file1
vyos@vyos:~$ touch file2
vyos@vyos:~$ touch file3
vyos@vyos:~$ ls
file1  file2  file3
vyos@vyos:~$ reset vpn remote-access user 
Possible completions:
  file1         Terminate specified user's current remote access VPN session(s)
  file2
  file3

looking at your configuration I see you set the neighbor using the interface name.
But in that case how does FFR know which IP address to connect to initiate a BGP session? Works in passive mode only?

PR is in: https://github.com/vyos/vyos-1x/pull/901

Bug confirmed and fixed,

I haven't access to the Cisco one because that is configured by another provider:

Should I hold out any hope for this to be implemented? Still willing to help test and do whatever I can to get this in.

I should soon have a PR ready for this, including an update to IPSec config to show how to port existing configs to use PKI.

I like the design!

In T3657#97243, @c-po wrote:

I wonder why you use ebgp multihop wirh link local addresses?

I used it only for testing (but this command increment ttl in two).