1

I have two virtual machines (router and client) ubuntu server 18 04, the router is the gateway for the client.Nftables are installed on the router and a NAT table is created with two chains pre and postrouting with a rule for the client.

table ip nat {
    chain prerouting {
        type nat hook prerouting priority -100; policy accept;
    }

    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        oif "enp0s3" ip saddr 192.168.2.100 snat to 192.168.1.10 comment "STATIC" # handle 4
    }
}

I turn on the ping from the client to the Internet - everything works well.

root@router:/home/router# conntrack -L -n
icmp     1 29 src=192.168.2.100 dst=8.8.8.8 type=8 code=0 id=13006 src=8.8.8.8 dst=192.168.1.10 type=0 code=0 id=13006 mark=0 use=1

but when you delete the rule, the session is not interrupted and the ping continues to go:

root@router:/home/router# nft delete rule nat postrouting handle 4
root@router:/home/router# nft list ruleset
table ip nat {
    chain prerouting {
        type nat hook prerouting priority -100; policy accept;
    }

    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
    }
}
root@router:/home/router# conntrack -L -n
icmp     1 29 src=192.168.2.100 dst=8.8.8.8 type=8 code=0 id=13006 src=8.8.8.8 dst=192.168.1.10 type=0 code=0 id=13006 mark=0 use=1
conntrack v1.4.4 (conntrack-tools): 1 flow entries have been shown.

I would like that when a rule is changed or deleted the current session from the client is terminated.

how can i get it?

1
  • By default, ping doesn't stop when a connection can't be made. It just continues trying. I think you can use the -w and -W options to change this behaviour. – berndbausch May 17 at 6:06
1

In addition to the Linux network stack, there's an additional "stack" intended to alter behavior but that is kept as much as possible separate from the network stack: Netfilter. This facility allows clients (still in kernel) to hook into it to intercept packets at various strategic places during its life in the network stack: that's used for firewalling and doing NAT. Among those clients but not only, there are iptables and nftables. Here's the corresponding Packet flow in Netfilter and General Networking schematic:

Packet flow in Netfilter and General Networking

While this schematic was created with iptables in mind it's also applicable to nftables. In this answer, nftables has the same role as iptables. Most things said here about nftables is applicable to iptables (legacy or nft version) and vice-versa.

As can be seen an other important client (really considered to be part of Netfilter) is conntrack which keeps track of all flows seen, and is also doing the bulk of NAT handling using the same flow bookkeeping. NAT is not really handled by nftables: as written in the center of the schematic, it will receive only the first packet of each flow to be able to give an altering rule that will determine the fate of the whole flow (rather than the single packet): once the information is stored in the conntrack lookup entry, conntrack will handle it standalone, and chains of hook type nat will not see following packets from this flow.

So it doesn't matter: once a flow is already handled by conntrack it won't be affected by any change in nat rules, even if there are no more rules, simply because those rules are not used anymore.

What can be done to affect this flow is to query directly the conntrack facility. The relevant tool for this is called conntrack (from https://conntrack-tools.netfilter.org/).

As OP wrote, it can be used to read information about conntrack entry, but can also be used to update, create, delete or flush (delete all) entries.

One can choose the granularity:

  • remove all entries:

    conntrack -F
    
  • remove all snat-ed entries (technically meaning that the reply destination address is not the same as the original source address in the lookup table):

    conntrack -D --src-nat
    
  • all the way to a surgical removal of OP's entry specifying all elements even including the precise ICMP id (so this wouldn't disrupt an identical ping command also started before the NAT rules were removed, since the id would most certainly be different):

    # conntrack -D -p icmp --orig-src 192.168.2.100  --orig-dst 8.8.8.8 --reply-src 8.8.8.8 --reply-dst 192.168.1.10 --icmp-type 8 --icmp-code 0 --icmp-id 13006
    icmp     1 28 src=192.168.2.100 dst=8.8.8.8 type=8 code=0 id=13006 src=8.8.8.8 dst=192.168.1.10 type=0 code=0 id=13006 mark=0 use=1
    conntrack v1.4.6 (conntrack-tools): 1 flow entries have been deleted.
    

    (there's no reason Ubuntu 18.04LTS's conntrack 1.4.4 behaves differently here)

Once this entry is removed, the next packet that was previously part of this flow will be seen as a new packet. Being in state NEW it will be given again a chance to be altered and will traverse the nat chains. As there will be no more any alteration, if it was egress it will traverse un-NATed to the next router which will probably drop it or pass it to a router which will drop it (because of Strict Reverse Path Forwarding or for specific routing rules for an RFC1918 address), if it was a late ingress reply from 8.8.8.8 it will be locally routed and ignored by the network stack: the ping command is disrupted and now times out.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.