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

[Frank Kardel <kardel%netbsd.org@localhost>]

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