https://github.com/vyos/vyos-build/pull/306
https://github.com/vyos/vyos-1x/pull/1817
https://github.com/vyos/vyatta-cfg/pull/60
https://github.com/vyos/vyos-http-api-tools/pull/3

Then lets close it

I have prepared a configuration example using one of the latest 1.4 images, where more features were introduced.
Scenario and requirements:

• One vyos router
• 3 Uplinks to internet (eth0, eth1 and eth2). Static IP used on three links
• 2 VLANs
  • vif 2: + New Connections from vif-2 routed through WAN-2 + Server on vif 2 should accept ssh connections from internet, through dnat on 3 WAN interfaces (outside port 122)
  • vif 4: + NewConnections from vif-24routed through WAN-2 + Server on vif 4 should accept ssh connections from internet, through dnat on 3 WAN interfaces (outside port 222)

Don't see any issue with 1.3

vyos@r1:~$ monitor bandwidth-test initiate 192.168.122.14
------------------------------------------------------------
Client connecting to 192.168.122.14, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.122.11 port 58042 connected with 192.168.122.14 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  6.37 GBytes  5.47 Gbits/sec
vyos@r1:~$ 
vyos@r1:~$ show version

Everything works on version 1.4

In T4774#142529, @c-po wrote:

Please note the WireGuard crypto Key routing concept: https://www.wireguard.com/#cryptokey-routing

Keys should not be re-used

Please note the WireGuard crypto Key routing concept: https://www.wireguard.com/#cryptokey-routing

@sdev @c-po @Alfa80 Can we look at rolling this back until it works fully, or fixing it so that it allows the above scenario please? Newer versions of 1.4 are unusable for me for a few months due to this. Let me know if I should file a separate bug.

Everything just worked fine.

Sorry about the trouble - fixed in next rolling release.

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

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

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

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

okay, so with https://vyos.dev/T4997 in place (tested via my custom build https://github.com/b-/vyos-build-action/releases/tag/v1.4-rolling_bri_add-dhcp-user-hooks ) and the following file in /config/scripts/dhcp-client/post-hooks.d/set-addrgroup

#!/bin/sh
#
# /config/scripts/dhcp-client/post-hooks.d/set-addrgroup

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

Reading more of the fancy internal scripting going on inside VyOS, there's already both a place to put this script (that would cause it to automatically be called by dhclient upon a new address), _and_ it sets a bunch of variables for us so I don't have to hac hac hac parse output that really isn't intended to be parsed. https://github.com/vyos/vyos-1x/tree/current/src/etc/dhcp/dhclient-exit-hooks.d

This is quiet interesting as container memory defaults to 512.

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.

Take a look at this T4165
Maybe the same issue but per rule. Different order of "comment"

Thanks for reporting.
We will take a look at it.

I have the same issue

@zsdc @v.huti this requires your attention

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