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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 24 2023
May 23 2023
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@vyos-1:~$ cat /var/run/load-balance/wlb.out cat: /var/run/load-balance/wlb.out: No such file or directory
@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.
May 22 2023
Further testing reveals that re-connecting the interfaces after reboot solves the issue:
May 21 2023
Please re-test with latest 1.4 release as the firewall was moved from iptables -> nftables
Hi @daniil and @NikolayP,
May 20 2023
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*?
May 19 2023
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
May 18 2023
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 ?
May 17 2023
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
May 16 2023
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.
May 15 2023
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
May 14 2023
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'
May 13 2023
May 12 2023
We should make the ssl-bind ciphers and ssl-bind-options configurable (<multi/> node) by the user
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:~$