/dev/rob0 put forth on 11/27/2009 3:13 PM: > I am equally at a loss, and could turn the question back at you: is > there any reason why I would want to run Postfix behind NAT?
Inbound NAT/PAT are often confused, because they're implemented (from an admin's standpoint) in an almost identical way. Depends on your firewall/router and its language and/or config GUI. Very few people actually implement a full inbound NAT these days, almost exclusively using selective PAT instead. Many/most, those using the technology, do implement a full outbound NAT however, selectively closing often abused outbound ports. I should have stated inbound PAT only, omitting NAT from my original statement, since it is what is applicable in this discussion. The major benefit is the same as with other systems: NAT/PAT acts as a natural inbound packet filter/firewall. There's nothing else to configure except to punch PAT holes into it for internal servers. Many admins don't have the time or skill to become real firewall monkeys, pounding out dozens or hundreds of lines of access control rules to accomplish the same thing with live address networks. > Perhaps there are different assumptions about NAT and its place in > our world. For me, it's always ugly, but sometimes a necessity to > work around the scarcity of IP addresses. For you it seems to be > desirable as an end in itself. I find NAT/PAT quite an elegant solution to multiple issues. Today NAT/PAT is more about network edge security setup ease of use than it is about saving IP addresses, esp for small orgs, although the latter is a concern for many sites. You also have to look at portability. If your org doesn't have its own ARIN netblock, and switches from one pipe provider to another, losing one set of IPs and gaining another set, then you have to renumber your entire network, both inside and out. CEOs would readily fire CIOs and managers for creating a cost of this magnitude. Again, any org without a direct ARIN netblock assignment should be using RFC 1918 space internally. Period. If you're a small outfit with just a few colo'd machines to readdress, that's a different story, and much more manageable. Your only real issue here would be TTLs on your dns records. > By all means, if you gain a benefit from having your Postfix behind > NAT, run it behind NAT. Do note that a few more non-default settings > are needed, but indeed as you observed, not a big deal. Also note > that routers vary, and some, like the Cisco PIX, are proxying your > SMTP traffic, not doing NAT. Consult your router documentation and > vendor for support, and then Postfix documentation for workarounds > should they prove necessary. I'm running my Postfix firewall behind NAT/PAT and the setup didn't require any non-default Postfix settings to make it work. I port forwarded TCP 25 from my router to my internal Postfix host IP and all worked without issue. What settings are you referring to? I concur with your router/firewall statement above. NAT/PAT implementations can and do vary, so one should read up on the docs and be ready for possible functionality oddities. For instance, I've seen a few NAT/PAT implementations that mask the real source IP in the packets, replacing it with the internal private interface IP of the router. This obviously wreaks havoc on Postfix smtpd, making client IP checks impossible, and making connection logging useless, amongst other things. So, if you run across a router with such a NAT implementation, toss it and get one that passes source IPs correctly (IIRC this came up not all that long ago, and Wietse's advice was the same--ditch the crappy router). That said, even many of the cheapest consumer broadband routers handle this correctly these days, most have since at least 2004, so I can't imagine you'd run into this today. Anything's possible though. -- Stan
