Re: [LARTC] NAT: multiple route lookups; local use of NAT IP

[Julian Anastasov <ja@ssi.bg>]

	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@ssi.bg>

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/