Hello, On Sun, Jan 26, 2025 at 06:19:23AM +0000, Sunny73Cr wrote: > > 193.72.186.128/26 dev enp2s0.300 proto kernel scope link src 193.72.186.130 > New reply (and now public): '193.72.186.128/26' does not cover all of > '193.72.186.0/24', and some packets will not get routed. Why should it? The firewall 193.72.186.130 on which the DNAT is done is connected to 193.72.186.128/26 because this is how the router 193.72.186.129 on the other side of the VLAN 300 defined that VLAN: 193.72.186.128/26 dev enp5s0.300 proto kernel scope link src 193.72.186.129 Indeed, the addresses 193.72.186.128 (reserved, subnet) to 193.72.186.191 (reserved, subnet broadcast) correspond to a 193.72.186.128/26 aka 32 - 26 = 6 free bit, so 64 addresses. On the same VLANs there are other machines, such as 193.72.186.190 that I used for my test. BTW, those (193.72.186.129, 193.72.186.190) are ping-reachable from the Internet (193.72.186.130 is currently down, as it is a test machine). The setup works, it's just the DNAT that routes wrong for some reason (I am an nftables beginner). Do not try random connections to those IP addresses (ping is ok), you might trigger the IDS. The DNAT problem is that when a machine from 193.72.186.128/26 (e.g. 193.72.186.190 in the example) sends a TCP datagram on port 8080 of 193.72.186.130, this gets correctly DNATted to 192.168.202.10 port 80, however, then the routing entry: > 192.168.202.0/24 dev enp2s0.202 proto kernel scope link src 192.168.202.2 is not respected, and the datagram is sent on enp2s0.300. In another case, which is 46.140.72.218:8080 (on enp2s0.400), the DNAT correctly works and sends to 192.168.202.10 on enp2s0.202. As said in the mail, the reply packet won't work on 193.72.186.128/26, that's expected (not default route, and no conntrack/mark set yet), but it's the initial packet which is routed wrong. Thank you & have a nice day.
