diff options
author | Yuxiang Zhu <vfreex@gmail.com> | 2023-09-10 16:22:02 +0000 |
---|---|---|
committer | Yuxiang Zhu <vfreex@gmail.com> | 2023-09-10 18:46:42 +0000 |
commit | ded55a82a00dbfd3425cec63ed08114957241683 (patch) | |
tree | bf307058afd1d60423e555fe125e7b4626b2df3e /src/validators/bgp-large-community-list | |
parent | b2383561158a3a78e2db8fefb37f1137147642ba (diff) | |
download | vyos-1x-ded55a82a00dbfd3425cec63ed08114957241683.tar.gz vyos-1x-ded55a82a00dbfd3425cec63ed08114957241683.zip |
T3655: Fix NAT problem with VRF
Linux netfilter patch https://patchwork.ozlabs.org/project/netfilter-devel/patch/d0f84a97f9c86bec4d537536a26d0150873e640d.1439559328.git.daniel@iogearbox.net/
adds direction support for conntrack zones, which makes it possible to
do NAT with conflicting IP address/port tuples from multiple, isolated tenants on a host.
According to the description of the kernel patch:
> ... overlapping tuples can be made unique with the zone identifier in
original direction, where the NAT engine will then allocate a unique
tuple in the commonly shared default zone for the reply direction.
I did some basic tests in my lab and it worked fine to forward packets
from eth0 to pppoe0.
- eth0 192.168.1.1/24 in VRF red
- pppoe0 dynamic public IP from ISP VRF default
- set vrf name red protocols static route 0.0.0.0/0 interface pppoe0 vrf 'default'
- set protocols static route 192.168.1.0/24 interface eth0 vrf 'red'
`conntrack -L` shows something like:
```
tcp 6 113 ESTABLISHED src=192.168.1.2 dst=1.1.1.1 sport=58946 dport=80 zone-orig=250 packets=6 bytes=391 src=1.1.1.1 dst=<my-public-ip> sport=80 dport=58946 packets=4 bytes=602 [ASSURED] mark=0 helper=tns use=1
```
It would be much appreciated if someone could test this with more
complex VRF setup.
Diffstat (limited to 'src/validators/bgp-large-community-list')
0 files changed, 0 insertions, 0 deletions