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

set interfaces virtual-ethernet veth10 peer-name 'veth100'
set interfaces virtual-ethernet veth10 vif 50 address '10.0.50.0/31'
set interfaces virtual-ethernet veth100 peer-name 'veth10'
set interfaces virtual-ethernet veth100 vif 50 address '10.0.50.1/31'

Check:

vyos@r14:~$ show interfaces virtual-ethernet 
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
veth10           -                                 u/u  
veth10.50        10.0.50.0/31                      u/u  
veth100          -                                 u/u  
veth100.50       10.0.50.1/31                      u/u  
vyos@r14:~$

Pings:

vyos@r14:~$ ping 10.0.50.1 source-address 10.0.50.0
PING 10.0.50.1 (10.0.50.1) from 10.0.50.0 : 56(84) bytes of data.
64 bytes from 10.0.50.1: icmp_seq=1 ttl=64 time=0.132 ms
64 bytes from 10.0.50.1: icmp_seq=2 ttl=64 time=0.085 ms
64 bytes from 10.0.50.1: icmp_seq=3 ttl=64 time=0.087 ms
^C
--- 10.0.50.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2064ms
rtt min/avg/max/mdev = 0.085/0.101/0.132/0.021 ms
vyos@r14:~$

It is a part of T3829
We should find a solution to check if the interface "neighbor" is in a separate netns. For now, we don't do this check.
veth pair should be in the local router only, VRF or NETNS and it won't work between 2 separate routers or 2 VMs.

So after a small test, I've come to the following:

I started working on a jool nat64 implementation at https://github.com/vyos/vyos-1x/pull/1993 for anyone that would like to try it out. Not everything is implemented yet, but I have been running this for the past few weeks with no issues. Any comments or feedback on the UX would be appreciated

@danhusan Could you check if the file /var/run/load-balance/wlb.out exists?
https://github.com/vyos/vyatta-wanloadbalance/blob/5a3ab6c426928644dc9ad9a70296263781523919/templates-op/show/wan-load-balance/node.def#L2C15-L5

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

vyos@r14# run show reverse-proxy 
Proxy name    Role      Status    Req rate    Resp time    Last change
------------  --------  --------  ----------  -----------  -------------
http          FRONTEND  OPEN      0
https         FRONTEND  OPEN      16
stats         FRONTEND  OPEN      0
bk-01         BACKEND   UP                    1 ms         1h34m45s
default-bk    BACKEND   UP                    0 ms         1h34m45s
bk-01         serv-01   UP                    1 ms         1h34m45s
bk-01         serv-02   DOWN                  0 ms         1h34m44s
default-bk    serv-03   no check              0 ms         1h34m45s
[edit]
vyos@r14#

Rule used for udev testing:

I successfully tested a udev rule to rename to wwan0.

Further testing reveals that re-connecting the interfaces after reboot solves the issue:

Please re-test with latest 1.4 release as the firewall was moved from iptables -> nftables

Hi @daniil and @NikolayP,

Does it fail on the client or on the server? I am unable to reproduce this given the instructions above.

Could you write and test an udev rule which renames the RNDIS usb0 device to wwan*?

There is the task T5169

PR listen-address fixes https://github.com/vyos/vyos-1x/pull/2013

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

In T5186#148568, @diodep wrote:

In T5186#148559, @c-po wrote:

Reverted Kernel back to 5.4.234 for upcoming 1.3.3. release.

Is it the same bug as T5048 ?

Draft until the dependency PR is merged:
https://github.com/vyos/vyos-1x/pull/1997

I've done test , regarding the original issues that it was nat+route-leaking (default + foo) , which is working on the last rolling (VyOS 1.4-rolling-202305140317). however, I've tried some test using two vrf+route-leaking and NAT , I can replicated the issue:

@ddominet the correct syntax

set protocols bgp neighbor 192.0.2.11 address-family ipv6-unicast allowas-in number 1

I've managed to adapt Alpine Linux patches to build Debian 11 StrongSwan 5.9.1 package, feel free to use it

In T3655#148609, @bbabich wrote:

In T3655#131502, @Viacheslav wrote:

I have NAT working with vrf in VyOS 1.4-rolling-202208290458 + custom nat offload

set interfaces ethernet eth0 address '192.168.122.14/24'
set interfaces ethernet eth1 address '192.0.2.1/24'
set interfaces ethernet eth1 vrf 'foo'
set protocols static route 192.0.2.0/24 interface eth1 vrf 'foo'
set system conntrack
set vrf name foo protocols static route 0.0.0.0/0 next-hop 192.168.122.1 interface 'eth0'
set vrf name foo protocols static route 0.0.0.0/0 next-hop 192.168.122.1 vrf 'default'
set vrf name foo table '1010'

Nftables

root@r14:/home/vyos# cat nat.nft 
flush ruleset

table ip filter {
	flowtable fastnat {
		hook ingress priority filter
		devices = { eth0, eth1 }
	}

	chain forward {
		type filter hook forward priority filter; policy accept;
		ip protocol { tcp, udp } flow add @fastnat
	}
}
table ip nat {
	chain POSTROUTING {
		type nat hook postrouting priority srcnat; policy accept;
		ip saddr 192.0.2.0/24 oif "eth0" snat to 192.168.122.14 persistent
	}

	chain PREROUTING {
		type nat hook prerouting priority dstnat; policy accept;
	}
}

Conntrack table

vyos@r14:~$ sudo conntrack -F
conntrack v1.4.6 (conntrack-tools): connection tracking table has been emptied.
vyos@r14:~$ 
vyos@r14:~$ sudo conntrack -L
tcp      6 431999 ESTABLISHED src=192.168.122.14 dst=192.168.122.1 sport=22 dport=44462 src=192.168.122.1 dst=192.168.122.14 sport=44462 dport=22 [ASSURED] mark=0 use=1
udp      17 src=192.0.2.2 dst=1.1.1.1 sport=33018 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=33018 [OFFLOAD] mark=0 use=2
udp      17 src=192.0.2.2 dst=1.1.1.1 sport=37517 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=37517 [OFFLOAD] mark=0 use=2
udp      17 src=192.0.2.2 dst=1.1.1.1 sport=59794 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=59794 [OFFLOAD] mark=0 use=2
udp      17 src=192.0.2.2 dst=1.1.1.1 sport=39288 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=39288 [OFFLOAD] mark=0 use=2
udp      17 src=192.0.2.2 dst=1.1.1.1 sport=39616 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=39616 [OFFLOAD] mark=0 use=2
icmp     1 29 src=192.0.2.2 dst=1.1.1.1 type=8 code=0 id=12387 src=1.1.1.1 dst=192.168.122.14 type=0 code=0 id=12387 mark=0 use=1
udp      17 src=192.0.2.2 dst=1.1.1.1 sport=41155 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=41155 [OFFLOAD] mark=0 use=2
udp      17 src=192.0.2.2 dst=1.1.1.1 sport=39829 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=39829 [OFFLOAD] mark=0 use=2
udp      17 src=192.0.2.2 dst=1.1.1.1 sport=33655 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=33655 [OFFLOAD] mark=0 use=2
udp      17 src=192.0.2.2 dst=1.1.1.1 sport=44835 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=44835 [OFFLOAD] mark=0 use=2
udp      17 src=192.0.2.2 dst=1.1.1.1 sport=40213 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=40213 [OFFLOAD] mark=0 use=2
udp      17 src=192.0.2.2 dst=1.1.1.1 sport=33729 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=33729 [OFFLOAD] mark=0 use=2
udp      17 src=192.0.2.2 dst=1.1.1.1 sport=48344 dport=53 src=1.1.1.1 dst=192.168.122.14 sport=53 dport=48344 [OFFLOAD] mark=0 use=2
conntrack v1.4.6 (conntrack-tools): 14 flow entries have been shown.
vyos@r14:~$

This works for me too on current rolling releases from Jan-2023 to now.

More PRs
https://github.com/vyos/vyos-1x/pull/2005
https://github.com/vyos/vyos-build/pull/349
https://github.com/vyos/vyatta-cfg-system/pull/202

I reproduced the problem.
I received the next logs

Version 1.4-rolling-202305150317 does not have the problem.

This can be closed now. I've submitted a Documentation PR

Fixing that causes this to also be logged. We should probably stop the socket too

frebib@vyos# commit
[ system syslog ]
DEBUG/COMMAND returned (err):
Warning: Stopping syslog.service, but it can still be activated by:
  syslog.socket
DEBUG/COMMAND cmd 'systemctl stop syslog.service'