Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

T3655: Fix NAT problem with VRF #2236

Merged
merged 1 commit into from
Sep 10, 2023
Merged

Commits on Sep 10, 2023

  1. 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.
    vfreex committed Sep 10, 2023
    Configuration menu
    Copy the full SHA
    aed71d4 View commit details
    Browse the repository at this point in the history