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.
> > 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 simplistic diagram which does little
to explain how things work in m0n0wall beyond the extreme basics
(which I'm not having a problem understanding - thank you :-)).
> >> 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.