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.

Will the custom timeout feature also be implemented in the python code? This is an option in the perl flavour (but doesn't actually work in 1.3 RC4).

It seems after that commit
but it is not a root case

Extended scripts receive from PPPoE daemon the following variables:

$1 - Interface name
$4 - Tunnel GW IP address
$5 - Delegated IP address to the client
$6 - Calling Station ID (MAC)

For example, how to get received RADIUS attributes
note: In this case, Filter-Id attribute used as an indicator for block user adding to ipset

configure
set firewall group address-group blocked 
commit

Waiting for T3595 to clear up before I can test this on rolling release.

I cannot replicate this bug in a clean install of 1.4-rolling-202105291042.

vyos@vyos# set interfaces dummy dum0 address 192.168.201.1/24
[edit]
vyos@vyos# commit
[edit]

Either there's something in your config meddling with the interface creation or (most likely) this bug was solved in the main branch since then.

We upgraded to 1.3.0-rc4 last night and enabled enable-egress, which indeed sends out egress traffic as well. However, the macaddresses are all zero:

I can reproduce the issue on our productive route in following way:

Why not use the mentioned method of sysctl`

@shaferstockton can you please post your entire generated openvpn.conf file?

I can not reproduce the issue using the following command sequence using VyOS 1.4-rolling-202106010417:

Why you closing the issue? Bug or issue is not resolved.

@Viacheslav I seem to find a strange problem. If I run two containers of adguardhome and nginx, they seem to work normally in the same image. However, once I upgrade and boot the new system, these two containers will be abnormal and can only be restored manually (try to delete them first, then recommit them, and need to modify the program appropriately), This is a robustness problem, which needs to be confirmed. If there is a problem, it needs to be solved!

PR: https://github.com/vyos/vyos-build/pull/168

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

PR https://github.com/vyos/vyos-1x/pull/860
To provide the possibility to read RADIUS attribute by script, also need to define radattr=/run/radattr param

Note
ipsec-interface not deprecated. This option needed.

set vpn ipsec ipsec-interfaces interface 'eth1'

https://phabricator.vyos.net/T842

@Viacheslav
I can spin up a working example without VRF.

@mTx87 Do you have a working example in Linux?
Maybe it also needs OpenVPN >= 2.5.0
https://blog.sdn.clinic/2018/12/openvpn-and-vrfs/

Here are some kernel features we need to consider:

1. Disable kexec. The user should never need to swap the kernel.
2. Restrict access to /proc/kallsyms for regular users, which makes sense since we're using a custom kernel.
3. Set hidepid to prevent regular users from seeing process IDs. Might be too intrusive.
4. Harden BPF JIT. Might interfere with XDP. Testing necessary.
5. Set kernel lockdown mode. Disables kexec and unprivileged BGP commands. Again, might interfere with XDP.

An easy start would be adding

export DEB_BUILD_MAINT_OPTIONS = hardening=+all
export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed -Wl,-z,-defs

to debian/rules to harden our C programs (which is currently only VyShim and XDP). hardening=+all passes PIE and bindnow linker options to GCC.

just wanting to chime in here, I think I've been bitten by what appears to be a similar cause.

In T3578#95246, @fernando wrote:

Hi

I tried to replicate that issue with the same version but I couldn't , let me show

vyos@vipv6-lp# run show version

Version: VyOS 1.4-rolling-202104270417
Release Train: sagitta

Built by: autobuild@vyos.net
Built on: Wed 28 Apr 2021 01:17 UTC