Hi there,
I have a very basic SNAT + physdev setup and I'm finding it wont work
and it would seem to be a obvious bug to me if this scenario is
supported, which I believe it is
Some of my versions here;
$ sudo iptables --version
iptables v1.8.9 (nf_tables)
$ uname -a
Linux us-sjc-eqnx-sv1-gw-0-5530 6.1.0-15-amd64 #1 SMP PREEMPT_DYNAMIC
Debian 6.1.66-1 (2023-12-09) x86_64 GNU/Linux
The relevant iptables configuration is this;
iptables -m physdev --physdev-out ens87f6 -t nat -A POSTROUTING -s
10.0.0.0/8 -j SNAT --to-source x.x.x.62 --persistent
The result is that SNAT works in the outbound direction but on the
reply direction when the packet is unNATed, the dmac is changed to be
the bridge mac which causes the packet to punt to routing instead of
being forwarded correctly
I know this because of the following packet logging I subsequently
added on the mangle prerouting and forward chains and can see whats
happening at the intermediate stages inside the system;
kernel: IPTABLES M-PR:IN=br_nat_in_3 OUT= PHYSIN=ens87f6
MAC=52:54:00:2b:95:c9:82:71:1f:83:80:b6:08:00 SRC=52.94.29.126
DST=x.x.x.62 LEN=84 TOS=0x00 PREC=0x00 TTL=241 ID=46108 DF PROTO=ICMP
TYPE=0 CODE=0 ID=54612 SEQ=408
kernel: IPTABLES M-F :IN=br_nat_in_3 OUT=br0 PHYSIN=ens87f6
MAC=a2:20:71:68:06:df:82:71:1f:83:80:b6:08:00 SRC=52.94.29.126
DST=10.117.117.91 LEN=84 TOS=0x00 PREC=0x00 TTL=240 ID=46108 DF
PROTO=ICMP TYPE=0 CODE=0 ID=54612 SEQ=408
$ ip link show br_nat_in_3
226: br_nat_in_3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP mode DEFAULT group default qlen 1000
link/ether a2:20:71:68:06:df brd ff:ff:ff:ff:ff:ff
Same problem is visible from ebtables logging
So I can imagine why in some of the use cases of different scenarios
rewriting the dmac is necessary to push the packet back up to routing
and get it forwarded to the correct place, but that behaviour becomes
a problem in the transparent nat scenario
Maybe its never worked or never been supported in the history of
nftables/iptables but some of the examples I found online led me to
believe otherwise. It does make sense to me that it never would work
because theres no toggle to turn off this behaviour and its required
for the other scenarios. It would need to be smart enough to turn off
that dmac mangle behaviour when the physdev module was in use for
bridged traffic, though possibly that would not always be the desired
behaviour
I did have a quick look into ntfables and whether it could do this but
1) i couldnt find any documentation for this scenario or examples of
people doing it and 2) I am understanding that both are just frontends
for the same underlying functionality anyway since I can get the
following output with the nft command for my iptables rule
$ sudo nft list table ip nat
# Warning: table ip nat is managed by iptables-nft, do not touch!
table ip nat {
chain POSTROUTING {
type nat hook postrouting priority srcnat; policy accept;
ip saddr 10.0.0.0/8 xt match physdev counter packets 10959
bytes 1033744 snat to x.x.x.62 persistent
}
chain PREROUTING {
type nat hook prerouting priority dstnat; policy accept;
}
}
