Re: nftables / DHCP / NAT

[Pablo Neira Ayuso <pablo@netfilter.org>]

Hi Volodymyr,

On Mon, Oct 30, 2023 at 11:20:55PM +0100, Volodymyr Litovka wrote:
> Hi Pablo,
> 
> On 10/30/23 09:41, Pablo Neira Ayuso wrote:
> > Then, to forward packets to some other box from the 'netdev' family,
> > use the 'fwd' statement:
> > 
> >          udp dport 67 udp dport set 10067 counter fwd to 100.64.0.66 device "eth0"
> > 
> > This rule above is mangling your UDP destination port from 67 to
> > 10067, then it send the packet to 100.64.0.66 and device "eth0". The
> > destination MAC address is updated by the neighbour layer so you do
> > not have to bother with "ether daddr set ..."
> 
> This works, thanks. But - all packets are duplicated :)

I see no duplicates, see below.

> If I run on the receiving host the command (in short - extract what I'm
> interested in)
> 
> tshark -i enp1s0 -l -f 'port 10067 and ether[42:1]==2' -d
> udp.port=10067,dhcp  -V -Y 'dhcp.option.dhcp==5' -V -E "separator=|" -E
> "quote=n" -E "occurrence=a" -T fields -e
> "dhcp.option.agent_information_option.value" -e "dhcp.ip.client"
> 
> then when using the old version of rules (just to check and compare) -
> udp dport 67 meta pkttype set other ether daddr set 96:9f:7c:d3:c3:66 ip
> daddr set 100.64.0.15 udp dport set 10067 counter accept
> 
> then tshark shows everything is ok, but if using -
> udp dport 67 udp dport set 10067 counter fwd ip to 100.64.0.15 device enp1s0

I had to cleanup your snippet, it contains non-breaking space (0xc2
0x0a) which makes the parser unhappy:

test.nft:2:1-1: Error: syntax error, unexpected junk
    chain rewrit {
^

This is the cleaned up result:

table netdev inspan {
    chain rewrit {
       type filter hook ingress device "inspan" priority filter; policy drop;
       udp dport 67 udp dport set 10067 counter packets 9510 bytes 4137201 fwd ip to 100.64.0.15 device "enp1s0"
    }
}

> then every packet (same running tshark) is duplicated:
> 
> 64702...31333430|x.x.x2.238
> 64702...31333430|x.x.x2.238

I suspect this shows the packet coming in (ingress) and coming out
(egress) on the same device.

I can see this in tcpdump, I made a similar ruleset that matches on
udp dport 8000, it mangles it to udp 8888 and forwards it to the same
device:

14:52:32.753056 IP 192.168.210.137.51820 > 192.168.210.130.8000: UDP, length 4
14:52:32.753149 IP 192.168.210.137.51820 > 192.168.210.130.8888: UDP, length 4

The first packet is the packet shown by tcpdump at ingress, the second
packet is the packet that is forwarded and tcpdump shows it at egress.

On the collector, I can see one single packet with UDP port 8888.

> Any ideas why this can happen?

I think what you observe from tshark / tcpdump is the packet at
ingress and then (being reflected) at egress.