Hello, On Sun, 2 Mar 2003, Martin A. Brown wrote: > Part I > - - - - - - > I am using a stateless (iproute2) NAT installation here as a concrete > example around which to ask my question about cases where route lookups > are required. > > I do not understand the entire sequence of route lookups required. > Intuition and observation suggest to me that there have to be two separate > route lookups. I would like confirmation and/or further explanation, if Yes, the source code shows more lookups :) > Here's my current understanding: > > 1 packet arrives from 192.168.14.2 on eth2 bound for 10.17.254.1 > 2 route exists in local routing table; rewrite packet for 172.17.254.1 > 3 ?? > 4 rewritten packet is transmitted on eth3 to 172.31.254.1 > > It seems that there must be a route lookup for 172.17.254.1 at step 3. > How does the kernel know to perform a second lookup? Currently, the kernel performs 2nd fib_lookup into the only ip_route_input call when the resulting route is from type NAT. Its goal is to find a real unicast route (route to the internal host) with valid outdev and gw because the NAT route contains only the NAT and the internal network (encoded in nh_gw). The 2nd lookup when SNAT is performed is avoided because the NAT/MASQ address is present in the ip rule. I assume, you know that Netfilter does not support anymore local address or 0.0.0.0 in ip rule nat. > Under what other situations would there be multiple route lookups for the > same packet? As for any other lookups during the packet traversal, Netfilter uses ip_route_output at many places with the goal to find nexthop when route key parameters are changed: addresses, fwmark, etc. > Part II > - - - - - - > Of less importance to me, but a peculiar side effect of the stateless NAT, > I find that I can never connect to IPs configured for NAT on the box in > question. The NAT addresses are not local ones. They can be used only from other hosts. This is one of the drawbacks. Also, playing with NAT addresses for servers introduces many problems when internal hosts talk to them after DNS name lookups. It is questionable whether using dumb NAT routes resolves the complexity in the routing rules. But there are cases where using stateless NAT is useful for the higer layers. > These commands were run on the NAT router in the above diagram. > > # ping -n 10.17.254.1 > connect: Invalid argument > # ping -I 192.168.0.13 -n 10.17.254.1 > PING 10.17.254.1 (10.17.254.1) from 192.168.0.13 : 56(84) bytes of data. > ping: sendto: Invalid argument > ping: sendto: Invalid argument > > --- 10.17.254.1 ping statistics --- > 2 packets transmitted, 0 packets received, 100% packet loss > > Is this a side effect of the NAT entry in the local routing table? Talking to NAT addresses is prohibited for output routes (originating traffic). "Invalid argument" is a good indication for this :) This is one of the drawbacks I already mentioned. Regards -- Julian Anastasov <ja@xxxxxx>
