Re: "NAT redirection", or NAT from inside to inside?

[Grant Taylor <gtaylor@riverviewtech.net>]

On 08/15/08 05:31, Philipp Periventas wrote:
> Hello Grant,

Morning.

> thank you very much for your mail and your effort! I finally solved the 
> problem with exactly the commands you wrote in your mail, plus a command 
> for letting the firewall itself getting access to the webserver by 
> manipulating the NAT output chain. I found this advice on the website 
> http://iptables-tutorial.frozentux.net/chunkyhtml/x4033.html - 
> unfortunately, I found it a bit too late!

*nod*

I'm glad that what I suggested worked as I had not had a chance to try 
it my self.

I *always* forget about the firewall its self being able to access 
things as I so seldom need it to be able to do so.

> The website also addresses the problem with "manipulated logs" - but I 
> guess by defining a source LAN address (like you did) I can live with 
> this constraint...

Yes.  I think who ever wrote that web page was working through things 
evolutionary (at least that's how it reads to me) and solved their 
problems as they came to them.  A simple TCPDump of unSNATed connections 
will show the problem which would prompt an SNAT rule.  After that 
looking at logs on the web server would it become obvious that you don't 
want to SNAT everything, just the LAN traffic.  This is one of the 
*many* reasons why having a DMZ be on a separate subnet is such a good ting.

> Damn! There should be special term for this kind of stupid - yet easy to 
> solve problem, because I was looking and asking for about a whole week 
> in forums, irc channels and so on...

Eh.  Most firewalling documentation is written around the idea that both 
the request and reply packets pass through the firewall (as opposed to 
some other route) and really one set of query / reply packets at that. 
When you start getting in to more complex things where the traffic might 
or might not pass through the firewall or you may want to deal with 
different IP addresses in subsequent query / reply sets or even 
different source / dest IPs in the query and reply (see the recent 
thread on SNMP and CUPS printing) the amount of documentation drops off 
and your need to truly understand what the packets are doing goes way 
up.  Try throwing hardware (switches) in there that do not like seeing 
the same MAC address on multiple VLANs and have to work around that...

> So, over again, thanks!

*nod*

You are quite welcome.  I'm glad that my ramblings helped.



Grant. . . .