0
echo "200 rj45" >> /etc/iproute2/rt_tables
echo "201 WIFI" >> /etc/iproute2/rt_tables
ip route add default via 192.168.5.9 dev eth0
ip rule add from 192.168.5.8/24 table rj45
ip rule add from 192.168.61.128/24 table WIFI
ip route add default via 192.168.5.9 dev eth0 table rj45
ip route add default via 192.168.61.38 dev wlan0 table WIFI
iptables -t nat -A POSTROUTING -s 10.196.0.0/16 -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.196.0.0/16 -o wlan0 -j MASQUERADE
ip route flush cache

Hi. The above commands are entered upon Linux server 1 bootup.

In Linux server 1, there are 3 interfaces. 2 interface are WAN interface, eth0 with 192.168.5.8/24 IP and wlan0 with 192.168.61.128/24 IP. Another interface is LAN with 10.196.3.254/16 IP.

Linux server 1 eth0 is connected to Linux server 2 eth0 with 192.168.5.9/24 IP.

The above policy route commands are implemented for Linux policy route. Default route is rj45 but on some condition the default route is changed to WIFI.

I am facing a problem when the following NAT iptables commands doesn't take effect especially with the command ip rule add from 192.168.5.8/24 table rj45 . when the client IP 10.196.3.253/16 ping 192.168.5.9 which is the subnet of Linux Server 1 eth0. If 10.196.3.253 ping 192.168.3.9 which Linux server 2 alias IP, it can ping.

tcpdump -i eth0 icmp at Linux server 2 shows that it try reply icmp ping of 10.196.3.253 which means the ICMP ping is most likely not NAT. below is the output

12:31:14.519000 IP 192.168.5.8 > 192.168.5.9: ICMP echo request, id 4213, seq 155, length 64
12:31:14.519018 IP 192.168.5.9 > 192.168.5.8: ICMP echo reply, id 4213, seq 155, length 64
12:31:14.520018 IP 192.168.5.9 > 10.196.3.253: ICMP echo reply, id 4213, seq 155, length 64

Any idea why NAT doesn't work in this setup? Below is the network diagram for clarity.

enter image description here

1 Answer 1

1

Your ip rule matches with a subnet id instead of an address, because you have the prefix length /24 (instead of /32 or omitted) there.

Prefix length like /24 is only appropriate / necessary when you configure an IP on an interface, in which case it is used to signify the subnet mask/size. In other cases, you should not include it unless you actually want to match for a subnet (in that case you should use the correct address as well, e.g. 192.168.5.0 for /24).

While 192.168.5.8/24 isn't exactly valid / sensical as a subnet id, probably it result in 192.168.5.9 being covered by the rule anyway. Therefore, the "reverse DNAT'd" reply from 192.168.5.9 is routed/forwarded back to itself by the default route in rj45 on Server 1, instead of being routed/forwarded to 10.196.3.253.

6
  • Thanks Tom Yan for the prompt reply. I didn't realise 192.168.5.8/24 was a subnet range for ip rule add till you point it. That fix the issue of 10.196.3.253 can't ping 192.168.5.9. However, after further testing, 10.196.3.253 can't ping 192.168.5.8 which is also Linux Server 1 WAN IP. Seems either I would need to exclude the iptables MASQUERADE if destination IP is 192.168.5.8 and source IP is 10.196.0.0/16 or adding more ip rule. mmm.
    – Carve8851
    Nov 28, 2023 at 9:58
  • Tested the command iptables -t nat -A POSTROUTING -o eth0 -s 10.196.0.0/16 ! -d 192.168.5.8 -j MASQUERADE still doesn't allow client 10.196.3.253/16 to ping 192.168.5.8.
    – Carve8851
    Nov 28, 2023 at 10:12
  • It's actually a problem of the same nature of the original one. You probably want to add a rule that lookup the main table that has lower priority / higher precedence and make use of the suppress_prefixlength 0 magic (which ignores the default route in the main table in that lookup). Otherwise your other rules will "invalidate" all other routes in the main table you need.
    – Tom Yan
    Nov 28, 2023 at 10:47
  • I have tried the following 1) ip rule add from 10.196.0.0/16 to 192.168.5.8 table main and ensure it is lower number = highest priority 2a) iptables -t mangle -A PREROUTING -s 10.196.0.0/16 -d 192.168.5.8 -j MARK --set-mark 1 2b) ip rule add fwmark 1 table main Both doesn't resolve the issue. I thought it is due to packet from 10.196.0.0/16 to 192.168.5.8 is not using the main route? I am still not sure whether suppress_prefixlength is required.
    – Carve8851
    Nov 29, 2023 at 2:47
  • @Carve8851 The problem(s) you have been experiencing is about where the replies to 10.196.3.253 would be routed to. If you insist on having a to-match rule instead, the to-match should cover 10.196.3.253. Same applies to the (fw)mark approach here. (Your approach does not involve "connmark".)
    – Tom Yan
    Nov 30, 2023 at 4:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .