On 06/12/2005 04:22:52 AM, Tib wrote:
Caveat to what I just said - if you are doing masquerading behind a single IP, then you don't need to worry about the FORWARD ruleset. Only packets associated with connections that are being masqueraded will get sent on to internal networks - unless you have specific ports that are translated to internal services. <EOL> Tib
Actually that isn't quite correct. With ip_forward on, network bridging is enabled. Running NAT does not disable the bridging function. If a box on the outside port sends a packet addressed to a box on the inside port, using the firewall as its gateway, the packet will get through NAT. NAT runs on top of the bridging function, so bridging still works, though only in one direction
since in the other direction packets will get NATed. You need to specifically use rules in the firewall to stop unsolicited packets from getting through, like ESTABLISHED/RELATED etc. The idea that running NAT disables bridging is a common and dangerous misconception. Showing this isn't so is a simple experiment, and one I have done many times to the astonishment of onlookers. You can block packets addressed to the inside of a firewall by a rule in your PREROUTING chain like so: -A PREROUTING -i eth0 -d 10.1.1.0/24 -j DROP Where 10.1.1.* is the inside range and eth0 is the outside port. Basically this DROPs anything appearing on the outside interface addressed to something on the inside interface. Technically though this rule is unnecessary if the rest of your firewall is set up right, since you would ordinarily be using rules to ensure that only response packets get back through the FORWARD chain. For example: -A FWD_INBOUND_TCPUDP -m state --state RELATED,ESTABLISHED -j ACCEPT Ian PS - Another misconception some have is that setting rp_filter stops this, it doesn't, since rp_filter works on a packet's source IP, not destination IP. However, I for one would be in favor of another kernel flag that *would* work on the destination IP.
