12/26/2023 0 Comments System log unrepliedIf you want some clients on internet to reach linux-srv using a DNAT rule on linux-router, then for the affected connections (eg: a web server on linux-srv tcp port 80), everything will work without disruption. So I explained what happens when you remove 1.1.1.6: doesn't affect linux-srv as an internet client, but creates some minor disruption between M10i and linux-router for unrelated ingress packets. The destination IP is now changed to 10.99.99.50, and the packet reaches the first route decision: it gets routed to linux-srv. tcp 6 432000 ESTABLISHED src=10.99.99.50 dst=8.8.8.8 sport=57490 dport=80 src=8.8.8.8 dst=1.1.1.6 sport=80 dport=57490 Īt some pre-routing point, conntrack will handle "de-SNAT" (as a reminder, this packet will never even traverse again iptables' nat table, this is also written in the previous schematic: "nat" table only consulted for "NEW" connections). If incoming packet does match a previously flow NATed and tracked by conntrack.Without Strict Reverse Path Forwarding, this would have caused a loop between M10i and linux-router until the packet's TTL was decremented to 0 and the packet then also dropped. ![]() If it had been M10i (or any system in the 1.1.215.32/27 LAN), linux-router would also have added ICMP redirects from time to time, as this can tell: # ip route get from 1.1.215.60 iif eth0 1.1.1.6ġ.1.1.6 from 1.1.215.60 via 1.1.215.60 dev eth0Īnyway, for packets coming from internet, packets will be sent back to M10i, which is probably implementing Strict Reverse Path Forwarding: this routed-back packet will be dropped by M10i, since its source (198.51.100.101) is on the wrong side of its routing table and thus filtered by Strict Path Forwarding. If the packet is not related to previous activity from linux-srv, this packet will reach the first route decision, as seen in this schematic. if incoming packet doesn't match a previously created conntrack entry. ![]() That means that the existence of this IP won't matter: linux-router will always receive traffic for 1.1.1.6. So linux-router never gets an ARP request for this IP: the ARP request coming from M10i is always 1.1.215.48 (and to tell the same, M10i's ARP table will only have cached 1.1.215.48, not 1.1.1.6). Removing this entry won't prevent to receive packets for 1.1.1.6 as M10i has a specific route to reach 1.1.1.6: using 1.1.215.48 which belongs to linux-router. The interface where this IP was added to didn't really matter as Linux is following the weak host model: it can answer queries to this IP received on any interface. That's again the routing stack job (including outside routing where linux-router has no control).īefore being deleted, 1.1.1.6 was an IP of linux-router. It's not netfilter's job to ensure that replies will really come back. If SNAT sees an IP matching the given criteria, it will add a conntrack entry to handle replies. SNAT happens at POSTROUTING, after any routing decision. Also to avoid multiplying cases to address, I'm assuming there's no other system to consider beside linux-srv (and linux-router) in the 10.99.99.0/24 LAN (it wouldn't be difficult to address them too). I'm assuming below that linux-router has no additional firewalling rule (in the default iptables filter table), because it was never mentioned in the question. ![]() netfilter doesn't do route decisions itself: that's only the role of the routing stack. netfilter's NAT handling alters addresses, and in some cases, when this is done before a route decision, this in turn alters the route decision. That's the important thing that explains what happens below.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |