Nov 1 2024
Oct 30 2024
No. It's not applicable for 1.4/1.5
@n.fort, is this applicable to 1.4/1,5?
Oct 10 2024
Firewall is completely rewritten in 1.4 and p2p in its old form is not there.
Oct 8 2024
Sep 15 2024
Sep 5 2024
May 13 2024
May 7 2024
Mar 4 2024
@paigeadelethompson it is another issue, open a separate bug report
table inet vrf_zones { map ct_iface_map { typeof iifname : ct zone elements = { "HE" : 132, "WAN" : 128, "eth0" : 128, "tun0" : 132, "eth1" : 256, "eth2" : 384, "veth0" : 132, "veth1" : 256, "VMNET" : 256, "FASTNETMON" : 384 } }
Feb 10 2024
Jan 20 2024
Dec 17 2023
Oct 4 2023
@rherold Could you re-check it?
for me , it's ok . I didn't see another issue related it . we can close
Can we close it?
Sep 14 2023
@fernando This is really nice. Thank you for the testing!
Sep 12 2023
command on 1.5 :
@vfreex I've tested in my labs related this issues , I can confirm that it work as expected . this original zone solved the problem when there was a src-nat /dst-nat with different VRFs or leaking with them ,Thanks you for this contribution .
Sep 10 2023
Oh sorry, I missed that this commit was for LTS 1.3.x series.
@Apachez I am running kernel 6.1.49-amd64-vyos and this works fine with my local setup.
The patch is already in linux kernel since at least 4.3 (you can confirm with https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/include/net/netfilter/nf_conntrack_zones.h?h=linux-4.3.y), but it was added to nft command only since Feb 2017: https://git.netfilter.org/nftables/commit/src/ct.c?id=ed66d9966294a3bab6c8611e369861ba57374743
@vfreex the referenced netfilter patch is from 2015, is that really valid for current version thats included in the Linux 6.1 LTS kernel?
You can test this approach on a running VyOS router using following commands:
I created a PR to fix this issue by using direction parameter of conntrack zones: https://github.com/vyos/vyos-1x/pull/2236
I have a very basic VRF setup and it works fine. It would be much appreciated if someone could test this with more complex VRF setup.
Aug 25 2023
Jul 12 2023
Jun 22 2023
I'm also encountering this issue on the latest rolling release.
Jun 8 2023
I have been able to get NAT to work with VRFs with 1.4-rolling-202306080317. However:
May 17 2023
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:
May 16 2023
May 12 2023
May 8 2023
Mar 7 2023
Mar 4 2023
Mar 3 2023
it doesn't seem the same problem as here, this logic that was applied over this version was vrf not on the table . Could you share full configuration ? there is some point over vrfs / vrf default /leaking that are not clear. So I can replicate the scenery and we see what is going on .
I have almost same problem here. Can't NAT between two VRFs correctly. The outgoing packet has been NATed correctly but the incoming packet seems be dropped, can't reach the source, it seems the return packet can't be tracked correctly.
Feb 28 2023
Feb 21 2023
Oct 3 2022
At least on my lab, with one of the latest 1.4, this is working for me:
Oct 1 2022
Is there a way to isolate a NAT rule to operate within a VRF?