NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/52074: -current npf map directive broken



Hi Robert !

On 05/10/17 00:45, Robert Elz wrote:
     Date:        Sun, 07 May 2017 23:07:42 +0200
     From:        Frank Kardel <kardel%netbsd.org@localhost>
     Message-ID:  <590F8C9E.3040102%netbsd.org@localhost>

   | From what I understand  this code originally attempted to avoid sending
   | from invalid/unusable local address (e. g. duplicate IP - error,
   | tentative and detached should just be dropped).

You also shouldn't be able to send from an address you don't own
(generally - a router has to be able to forward, as distinct from
originate, packets from anywhere of course).
You are correct - in this case (52074) we are looking at both aspects - the local machine and the router/NAT box. It is *not* about originating packets from anywhere. It is about redirecting packets for non local targets to a locally existing proxy.

Maybe you could explain what you're trying to achieve, rather than
worry too much (right now) at some particular kernel test which seems
to be defeating the way you are currently trying to accomplish that.
I am just reporting a regression that was introduced by the code related local address checks.

If your aim is to have machine "B" (the router/NAT box) from your
later e-mail example, intercept SMTP (and perhaps other) connection
attempts that your internal system (A) is attempting to make to
some external system (C) - so that the connection is handled by B
instead (acting as a proxy) then I suspect that someone can share
a config which accomplishes that ...
See man 5 npf.conf - there is an example. It also used to work with pf years ago but I used pf long ago and haven't retested it with last years address-check/tentative/detached changes. pf could
also be impacted by last years change.

Example from pf.conf(5)
     Note that redirecting external incoming connections to the loopback
     address, as in

           rdr on ne3 inet proto tcp to port spamd -> 127.0.0.1 port smtp

Example from npf.conf(5)
     map $ext_if dynamic proto tcp 10.1.1.2 port 22 <- $ext_if port 9022

Not necessarily a local address, but local addresses are not forbidden either.
  but I very much doubt it will
involve something so weird as attempting to NAT into the loopback address.
(Transparent) proxies might very well do that at boundaries between external and internal networks. Using any other local address instead of 127.0.0.1 wouldn't change a thing for the discussion as the original target address is redirected to the local address and needs to be rewritten back to the
original target address on the way back.

If you have some other aim, explain it, and someone can probably
show how to accomplish it.   But please explain the objective, not
the technique you believe you can use to meet that objective.
It is a proxy for a system C that is not always online. And the proxy is located at the gateway. The solution is a common redirect scenario. nothing special unless you have a regression in the stack.

I believe that the current local address check is just placed wrong. But I just uncovered that while analyzing why the NAT redirect broke - I am not responsible for the address check code which broke
NAT redirection to local addresses as an unwanted/unexpected side effect.

I think we have a discussion going on how to implement the address check properly. And I think there may be a better solution which needs to be found and implemented which enforces the local address
check more sensibly..

If we put the local address check before the packet filter call (doing the reverse NAT) then all would be fine, But I think it should be discussed (roy@, rmind@, christos@, ...) whether this is the right solution to have a valid local address check and the redirect
to local address NAT functionality.

Once we know what it is you want to do, it is still possible that
kernel (or other) changes might be needed to accomplish it (or it
might just not be possible at all), but if changes are needed the
right ones to make could be somewhere quite different from what
you have been concentrating on.
A proxy on a gateway is something that should work and it used to work with npf and pf.
Last year a regression was introduced breaking that functionality.

I am happy learn another way to configure a proxy using local addresses of the gateway *without* changing ip_output.c - we just need to fix our own documentation then,

Can you provide an alternative configuration to accomplish the above?
kre

ps: this issue is of course totally unrelated to the other question of
whether tentative addresses should be considered invalid, which certainly
has nothing to do with your problem.

Frank


Home | Main Index | Thread Index | Old Index