Manuel Kasper wrote:
> Molle Bestefich wrote:
> > I hope it's not me you're trying to help with that? :-D
>
> I think Anders was indeed trying to help you with that picture -
> you've given us enough evidence of being confused by the interaction
> of NAT and filtering in m0n0wall.

Easy does it.

Where, concretely, do you think I'm confused?

> And no, m0n0wall doesn't have problems with doing normal
> destination-based routing on NATed packets,

Never said so, quite the contrary.

> and it doesn't support source-based routing anyway.

Oh.  Ok.

> > It doesn't show anything about how NAT works in m0n0wall, aside
>
> Yes it does - now you'd only have to add the traffic shaper as an
> additional shell between the filter and the kernel, and you'd have a
> nice and simple diagram that illustrates what happens to packets as
> they pass in or out of m0n0wall's WAN interface.

It mentions nothing about the WAN or indeed any other interface, which
makes it a bad representation of the very interface-centric NAT
processing in m0n0wall.

The kernel IP router, a major component, is missing from the diagram.

All in all, I retain that it's a very simplistic diagram which does
nothing to explain how things work in m0n0wall, beyond the extreme
basics.

> >> Almost every firewall and router works in this way.
> >
> > And?
>
> You said that you thought the current scheme (in m0n0wall) was "an
> unnecessarily complicated solution". However, you didn't explain how,
> in your opinion, it could be simplified. I don't see how it could, or
> how m0n0wall could be improved with respect to the NAT/firewall
> processing order. In my opinion, it's perfectly reasonable and
> intuitive the way it is now, and people rarely have issues with it.

Ok.