In T2196#125917, @lue30499 wrote:

This feature would be very helpfull for hairpin nat as we can see from the mentions.
Might also be helpfull for ipv6 as well.
I am aware its a different product but edgeos from ubiquiti does something like this (looks to be a managed address group that populates dynamically) for nat and fw:

destination {
    group {
        address-group ADDRv4_eth0
    }
}

I just want to really strongly second this issue — if this feature isn't added and I can't find a good workaround, I won't be able to stick with VyOS :(

Thanks @Viacheslav, that makes sense.

Some adjustments made for command output; re-testing for PR.

Running smoketests; PR's to follow:

eth0 -> PPPoE (Primary link)
eth1 -> DHCP (Backup link)

if I use default-route 'auto' for pppoe then default route via pppoe is not getting configured. That's why I am defining the static default route for pppoe with default-route 'none' option.

I have two wan links as following-

It looks like mine issue with wan load balancing - reply for dnat-ed packets from secondary interfaces was sent by vyos from "primary" https://phabricator.vyos.net/T4587 . Could you dump traffic and check that possibility

@fernandolcx Will be present in the next rolling release, could you test it (after 20230209)?

@c-po Do you have any idea for CLI?

@skoenman Could you write some examples of configuration?

@Usman there is a root task for op-mode rewriting https://phabricator.vyos.net/T4564
https://github.com/vyos/vyos-1x/blob/1042fc32c371a74f048ffaf9a551b5d13c227f45/src/op_mode/bgp.py#L77-L80

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

@Viacheslav Thanks, that works great!

@Usman You have to update to the latest rolling.
https://vyos.net/get/nightly-builds/

Thanks for the reply.

Hi perhaps it is better to get JSON format

I would prefer a different syntax, in order to avoid the necessity attaching it to an interface. Maybe something like:

Error detected in forum: https://forum.vyos.io/t/unable-to-query-snmp-anymore-in-a-more-recent-1-4-version/10388/3
Fix for that bug: https://github.com/vyos/vyos-1x/pull/1805

PR 1.4 https://github.com/vyos/vyos-1x/pull/1804
PR 1.3 https://github.com/vyos/vyos-1x/pull/1806

Why did you delete this option and add a static route? Is there any use case?

This option has more priority than others.

Got it; it is impossible for now after this migration https://phabricator.vyos.net/T3090
We are working on the re-design firewall CLI

I built a 1.4 ISO after my change was merged and deployed it to my home network. Setting a restrictive allow list works as expected, only the allowed IPs/subnets are able to use NTP. Removing all allow IPs prevents chrony/ntp from even listening to port 123. I don't think the "deny all" is needed in the code at all, but it is also not preventing the service to run as expected so I'll leave it.

@c-po is this an S3 bucket policy issue, or do the files not exist?

Setting it configurable will be a good solution.
Just like it is done in OpenVPN

vyos@r14# set interfaces openvpn vtun0 tls tls-version-min 
Possible completions:
   1.0                  TLS v1.0
   1.1                  TLS v1.1
   1.2                  TLS v1.2
   1.3                  TLS v1.3

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

We also need to increase opened file descriptors (ulimit -n) to listen limit + some margin.
And consider adding a warning about increasing net.core.optmem_max for systems with a limit of more than 100 peers.

It is a problem with mapping user to radius_priv_user
This problem began after https://github.com/vyos/vyos-1x/commit/765f84386b6e94984ff79db2eab36d51f759159b#diff-0ab0ed71ce757261c4a6ae2f3a5bc441d6257d477bfb5435ae38f230777ff81cR51
If I set in sshd_config

I'm not free now. I'll check it when I'm free

@Viacheslav unfortunately I am not too familiar with your build system, but basically you need to clone the ovpn-dco repository (https://github.com/OpenVPN/ovpn-dco.git) and compile it against your kernel, as you would normally do for any other out-of-tree kernel module.

PR for alternative completion helper. This provides the same args/output of the Python script, with a speedup of 1--2 orders of magnitude; testing needed.
https://github.com/vyos/vyos-utils/pull/11

@c-po @ordex Do you know how to integrate sources with our build system?

A basic implementation: https://github.com/vyos/vyos-1x/pull/1800

when an incompatible option is found, OpenVPN will simply disable DCO and go back to tun (this info will be logged). Therefore the limitations should not be a reason for not including DCO in VyOS.

PR for 1.3 which makes the change available for every config subsystem https://github.com/vyos/vyos-1x/pull/1798

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

In T3871#141847, @jestabro wrote:

Before adopting the approach mentioned above, there was development of an alternative using pyudev within an 'interface-monitor' daemon; the following branches contain (a version of) the rebased code. It would need a few hours of attention to check the logic and add the is_persistent check from vyos-interface-rescan.py; it could use some refactoring as well.

https://github.com/vyos/vyos-1x/compare/current...jestabro:vyos-1x:interface-monitor
https://github.com/vyos/vyatta-cfg/compare/current...jestabro:vyatta-cfg:interface-monitor
https://github.com/vyos/vyos-build/compare/current...jestabro:vyos-build:interface-monitor

Before adopting the approach mentioned above, there was development of an alternative using pyudev within an 'interface-monitor' daemon; the following branches contain (a version of) the rebased code. It would need a few hours of attention to check the logic and add the is_persistent check from vyos-interface-rescan.py; it could use some refactoring as well.

@daniil Could you update the PR?

Could you send the full accel-ppp working configuration that you expect?

@Jimz Show please the file cat /config/dhcpd.leases
I cannot reproduce it even if no any leases

vyos@r14:~$ show dhcp server leases 
IP Address    MAC address    State    Lease start    Lease expiration    Remaining    Pool    Hostname
------------  -------------  -------  -------------  ------------------  -----------  ------  ----------
vyos@r14:~$

The approach in commit rVYOSONEXee02ca93ec7b of vyos-1x was considered a reasonable workaround for all but a few corner cases. However, the issue pointed out in

PR for 1.3: https://github.com/vyos/vyos-1x/pull/1796