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

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

[Martin A. Brown]

Hello all,

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
possible.

Here's a simple map describing my working configuration.

                      +---------+
         10.17.0.0/16 |   NAT   | 172.17.0.0/16
     -----------------+ router  +--------------------
                 eth2 +---------+ eth3

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?

Under what other situations would there be multiple route lookups for the
same packet?


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.

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?


Thank you in advance for any answers,

-Martin


 Notes:
 - - - - - - - - - - - - -
 - there are more interface on the box, but no traffic relevant to my
   question traverses any of these interfaces
 - aside from the NAT entry, there are no RPDB entries
 - # ip rule show | grep 10.17
   310:    from 172.17.0.0/16 to 10.10.0.0/16 lookup main map-to 10.17.0.0
 - # ip route show table local | grep '^nat 10.17'
   nat 10.17.0.0/16 via 172.17.0.0  scope host

 routing cache entries
 - - - - - - - - - - - - -
 192.168.14.2 from 172.17.254.1 via 192.168.0.251 dev eth2  src 172.31.254.254
     cache <src-nat>  mtu 1500 rtt 300 iif eth3
 10.17.254.1 from 192.168.14.2 via 172.31.254.1 dev eth3  src 192.168.0.13
     cache <dst-nat>  mtu 1500 rtt 300 iif eth2

-- 
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com

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

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

[Julian Anastasov]

	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/