I already wrote it in the gentoo forum, but I was advised to file a bug report. There is a typo in the NAT string of the iptables firewall script in the Gentoo Security Handbook. The script defines the internal and the external area of a local network as following: Code: #inside IIP=10.0.0.2 IINTERFACE=eth0 LOCAL_NETWORK=10.0.0.0/24 #outside OIP=217.157.156.144 OINTERFACE=eth1 But when it defines the NAT (network address translation) part it confuses me a bit: Code: $IPTABLES -t nat -A POSTROUTING -o $IINTERFACE -j MASQUERADE What exactly is the point of masquerading the internal interface? I'm not very well-versed with Iptables yet, but as far as I know, the masquerading should happen on the external interface, namely $OINTERFACE. In my opinion, it should look like this: Code: $IPTABLES -t nat -A POSTROUTING -o $OINTERFACE -j MASQUERADE This typo renders the whole forwarding process useless, and those people who use it are mostly inexperienced with Iptables, thats probably a reason why no one reported it for such a long time. (As far as I know, this script has been around for at least a year.)
First, let me say that the example in the handbook strives to be a catch-all example; as close to a generic, safe config as we can provide. Setups will be different from one box to another though. Perhaps most people would want NAT only on their external interface (e.g. for a single shared IP/connection), but if you're doing a heckuva lot of routing, there are times when it's useful to masquerade the internal interface as well, that's why the example is here. It doesn't hurt; in case you're doing something fairly advanced (i.e. anything else besides what's in the doc, which is why we point you to http://www.iptables.org/documentation/index.html#HOWTO), it should be helpful. A couple of quotes from the iptables handbook link listed above: "You design your packet filtering completely ignoring any NAT you are doing. The sources and destinations seen by the packet filter will be the `real' sources and destinations. For example, if you are doing DNAT to send any connections to 1.2.3.4 port 80 through to 10.1.1.1 port 8080, the packet filter would see packets going to 10.1.1.1 port 8080 (the real destination), not 1.2.3.4 port 80. Similarly, you can ignore masquerading: packets will seem to come from their real internal IP addresses (say 10.1.1.1), and replies will seem to go back there." "Source NAT is when you alter the source address of the first packet: i.e. you are changing where the connection is coming from. Source NAT is always done post-routing, just before the packet goes out onto the wire. Masquerading is a specialized form of SNAT." You'd see the most benefit from the listed iptables command if you were doing some serious load-sharing or transparent proxying. Sorry that you don't understand the whys yet, but it's not a typo, as you suggested in the thread. Thanks for reporting though.
IF you are doing heckuva lot of routing and load balancing, you are already well versed on this field and don't need to read this very basic tutorial, in which, by the way, is nowhere mentioned why anyone would use MASQUERADING (something which is mainly used on dynamic internet addresses to let the interface forget a connection when the address changes) on an static internal interface. This script is for people who know not much about security and firewalls. Why would you put such a rare case of NAT-ing into a tutorial firewall script for noobies? And by the way, I don't think you, in all your arrogance, know the reason why NAT actually exists. Otherwise you would be aware that the provider drops all packets with an internal source-address, which in this case will happen if you use this script. That means, all outgoing connections will be dropped and not a single packet will come back to you. I does not work. And there is no way you can spin that around with all your proxying and load balancing explanations. Now the simple solution would be that you either change that string to $OINTERFACE or add a line with SNAT or MASQUERADE on the external interface and it would work OUT OF THE BOX. You are just being ignorant here.
For the record, I've no idea why you suddenly snapped. I'm used to discourteous users, but at least most of them have some slightly saner reasons for their words. Note: pissing off the people that you want to fix something is counterproductive!
Closing per above. We really should pay bug wranglers more for what they do; they have to deal with this stuff every day. :)
I apologize. However, despite my too offensive reaction, I urge you to look at it again and comment on the actual issues.
Reopening for re-evaluation.
(In reply to comment #5) > I apologize. However, despite my too offensive reaction, I urge you to look at > it again and comment on the actual issues. > Another member of the GDP contacted me to discuss this (thanks jkt). Anyway, while going over the report, I checked against the existing firewall script we have in home-router-howto.xml (http://www.gentoo.org/doc/en/home-router-howto.xml#doc_chap4). In it, the desired two-NIC setup is similar to the goals of the firewall in the security handbook, so I changed the firewall handbook to reflect the home-router-howto handbook; IINTERFACE for OINTERFACE, as you suggested. Sorry about the misunderstanding -- though what I said earlier is correct, you're right in that unless there are some more examples included (for example dnat/snat examples), masquerading an internal interface is kinda useless. Not necessarily harmful, but useless if it's not backed up by helper policies. Also, I do thank you for apologizing. It's very hard for any developer to want to help fix something if a user comes to him using insulting, provocative words delivered in an angry tone. Thanks for understanding. :) Anyway, this is fixed in CVS; thanks for reporting.
