Why is ingress packet not getting DNAT 'edin NAT PREROUTING chain with nftables?

Question

I have a use case wherein I want to change the destination IP address of ingress packets based on certain packet attributes (source IP address, destination port, protocol, ingress interface name, etc.).

This is my configuration:

table inet raw {prerouting hook }
    chain PREROUTING {
        type filter hook prerouting priority -300; policy accept;
        iifname "vnfh0" tcp dport { 21053 } notrack counter packets 413936 bytes 24836160
    }
}

table ip nat {
    chain PREROUTING {
        type nat hook prerouting priority -100; policy accept;
        iif "vnfh0" counter packets 0 bytes 0 tcp dport { 21053 } dnat to 192.168.255.1
    }
}

table ip filter {
    chain INPUT {
        type filter hook input priority 0; policy accept;
        ip saddr 192.168.255.254 ip daddr 192.168.255.253 tcp dport 21053 counter packets 302318 bytes 18139080
        ip saddr 192.168.255.254 ip daddr 192.168.255.1 tcp dport 21053 counter packets 0 bytes 0
    }
}

We expect the rule in the NAT table to change the destination IP address of the received packets.

However in INPUT chain (hook input), we see that the packet still has destination IP address as the old one (192.168.255.253), which we expect to change post DNAT to 192.168.255.1.

What changes should be done to the above configuration?

Additional details:

vnfh0 is an interface on Linux host and it receives packets from another LXC-container.

=================================================================
    |HOST (root container)                                  |
        |      --------------------------------        |
    |    |                |        |
    |    |    lxc-container        |        |
    |    |    eth0 192.168.255.254    |        |
    |    ------------|--------------------        |
    |        vnfh0    (192.168.255.253)        |
    |          |                    |
    |        ethlmp0 (192.168.255.1)            |
    |                                                |
    |                            |
    |    daemon(192.168.255.1:981)            |
    =========================================================

cd ~
brctl show

Output:

bridge name     bridge id               STP enabled     interfaces
vnfh0           8000.02404380100f       no

1. We tried to trace packets in netfilters by putting counters, but we learnt by tracing packet in the INPUT chain that the packets have not been DNATed.

Answer 1

The configuration you've provided uses nftables for packet processing on a Linux host, aiming to change the destination IP of incoming packets under certain conditions. Based on what you've described, the DNAT rule in the nat table's PREROUTING chain should indeed modify the destination IP of packets matching the specified conditions. However, you observe that the destination IP remains unchanged when inspected in the INPUT chain.

Let's go through your configuration and identify potential issues or necessary clarifications:

Raw Table and Notrack: You're using the raw table to set notrack for specific packets. This prevents connection tracking for these packets, which could be why DNAT isn't being applied as expected. DNAT relies on connection tracking to modify the packet's destination and maintain this mapping for the duration of the connection. If notrack is set for a packet, its destination won't be altered by DNAT rules because connection tracking is bypassed.

table inet raw {
    chain PREROUTING {
        type filter hook prerouting priority -300; policy accept;
        iifname "vnfh0" tcp dport { 21053 } notrack counter packets 413936 bytes 24836160
    }
}

You might need to reconsider the use of notrack for these packets if you want DNAT to apply.

NAT Table and DNAT Rule: Your nat table and PREROUTING chain seem to be configured correctly for DNAT. However, ensure that no other rules are inadvertently bypassing or conflicting with this DNAT rule.

table ip nat {
    chain PREROUTING {
        type nat hook prerouting priority -100; policy accept;
        iif "vnfh0" counter packets 0 bytes 0 tcp dport { 21053 } dnat to 192.168.255.1
    }
}

Filter Table and Input Chain: The INPUT chain shows counters for packets destined to 192.168.255.253 and 192.168.255.1 on port 21053. If DNAT were working, you should see the counters for 192.168.255.1 incrementing. Since this is not happening, it further indicates that DNAT is not being applied as expected.

table ip filter {
    chain INPUT {
        type filter hook input priority 0; policy accept;
        ip saddr 192.168.255.254 ip daddr 192.168.255.253 tcp dport 21053 counter packets 302318 bytes 18139080
        ip saddr 192.168.255.254 ip daddr 192.168.255.1 tcp dport 21053 counter packets 0 bytes 0
    }
}

Suggested Changes:

Review Notrack: Reassess whether the notrack statement is necessary for your use case. If DNAT needs to apply, you should remove or adjust the notrack usage.

Debugging: Use nft list ruleset to get a comprehensive overview of all the nftables rules. Look closely at the order and specificity of the rules to ensure there's no unintended shadowing or precedence conflicts.

Monitoring and Logs: Increase the verbosity of nftables logs or use tools like tcpdump to monitor the packet flow and verify where the packets are being dropped or not altered as expected.

Testing Isolation: Temporarily remove the notrack rule and test if DNAT works without it. This can help isolate whether the issue is with DNAT itself or the interaction with notrack.

By addressing these points, you should get closer to identifying why DNAT isn't working as expected in your setup.