Re: npf forwarding <-

[Dima Veselov <kab00m%lich.phys.spbu.ru@localhost>]

On Tue, Nov 20, 2018 at 12:23:00PM +0000, Patrick Welche wrote:
> > > 
> > > map iwn0 dynamic any -> 10.111.65.65 pass family inet4 from 10.168.204.0/24 # id="1" 
> > > map wm0 dynamic 10.111.65.4 <- any pass family inet4 to 128.232.132.8 # id="2" 
> > 
> > I got your setup working and now have to explain something:
> > typical pub->priv redirect always works with priv->pub mapping, 
> > because NAT have to allocate outleading port when inside server
> > replies. In your setup there is no rule for mapping replies.
> > 
> > You have to NAT replied packet and it will work with that:
> > map $int_if static 172.20.27.7 -> 128.232.132.8
> > map $int_if static 172.20.27.7 <- 128.232.132.8
> > map $ext_if dynamic $int_net -> $ext_v4
> > 
> > (172.20.27.7 is the outside webserver you are trying to reach).
> 
> Interesting: this gets me 172.20.27.7 if I aim for 128.232.132.8 as
> requested, but given the other rule, if I aim for 172.20.27.7 I don't
> get 172.20.27.7...

I think it happens because replies will be NATed and client will get 
answer from 128.232.132.8 instead.

> > I also converted "dynamic" to "static" and have no idea why it works,
> > maybe npf architector can tell us.
> > 
> > As for previous note about stateful - recently I got same problem.
> > It seems NAT will never work if inside->outside connection is stateful.
> 
> According to http://rmind.github.io/npf/nat.html
> 
>    It should be
>    remembered that dynamic NAT, as a concept, relies on stateful
>    filtering, therefore it is performing it implicitly.
> 
> I expected the return rule not be necessary, as I expected the reply
> packet to match the connection state. How is this meant to work?

I have no answer right now, but I will try to find out.

-- 
Sincerely yours,
Dima Veselov
Physics R&D Establishment of Saint-Petersburg University