##------ troubleshoot iptables -Z to reset the counter then apply the connection test check which counter of what chain didn't get increased or matched. also log the problematic rule. #wc -l /proc/net/ip_conntrack 81 /proc/net/ip_conntrack this means we have 81 connection being tracked through your firewall. ##------ commands route -Cn will list how current packet get routed. iptables -L -t nat --line-numbers # show the line number for NAT table. iptables -D PREROUTING 1 -t nat # delete the line number 1 in PREROUTING chain in table nat ##----- filter open port from port scan when packect is droped for certain port, running `nmap` we will see it be 'filtered'. to make it invisible, change DROP to -j REJECT --reject-with tcp-reset' ##------ forward port 8888 on gateway to a internal machine. gateway : 65.48.28.33 internal : 192.168.0.3 this allow incoming traffic to port 8888 at 65.48.28.33 DNATed to 192.168.0.3 on port 80. $iptables -t nat -A PREROUTING -p tcp -d 65.48.28.33 --dport 8888 \ -j DNAT --to-destination 192.168.0.3:80 we could replace the '-d $extern_IP' to '-i $external_IF' i.e -i eth1 add the appropriate rules to the FORWARDing chain to allow the packets through firewall after they've been NATted by the above rule this allow the traffic going through FORWARD chain for 192.168.0.3 at port 80 to be accepted. $iptables -A FORWARD -p tcp --dport 80 -d 192.168.0.3 -j ACCEPT ##------ general knowledge in NAT, If you omit the source address option, then any source address will do. If you omit the destination address option, then any destination address will do. iptables -A INPUT -s 0/0 -j DROP == iptables -A -j DROP Packets traversing the INPUT chain don't have an output interface, so any rule using `-o' in this chain will never match. Similarly, packets traversing the OUTPUT chain don't have an input interface, so any rule using `-i' in this chain will never match. Only packets traversing the FORWARD chain have both an input and output interface The INPUT chain is for packets addressed to the firewall itself. The FORWARD chain is for packets going through the firewall to some other machine. 1. The INPUT chain is *only* for packets which terminate on this machine. 2. The FORWARD chain is *only* for packets which are going through this machine. 3. The OUTPUT chain is *only* for packets which originate on this machine. almost all packets dropped by netfilter rules are SYN packets (ie the first part of the TCP three-way handshake) and the very purpose of dropping them is so that the 3-way handshake does not complete, and the session does not start transmitting data. ##------ packet reply -- Antony Stone The *original* packet (the first one) in what is going to be a natted connection gets to the firewall, enters the PREROUTING chain, and the destination address gets changed(DNAT). The packet then goes on to the FORWARD chain (where it might get blocked, but in this example is allowed through), goes on further to the POSTROUTING chain, where nothing happens to it in our example, and it then exits the machine and goes to the real destination. Something which is not obvious happened in the middle of that - when the packet went through the PREROUTING chain and the destination address got changed, an entry got placed in the connection tracking table to say where the packet came from and where it was going to, so that reply packets (which have the source & destination addresses the other way round) will get recognised when they come back through the firewall..... So, sometime a little later on, a reply packet comes back. Immediately it gets to the PREROUTING chain (before it traverses any rules) it gets recognised as a reply packet to an existing connection, and it simply bypasses the nat rules in the PREROUTING chain, goes through the normal rules in the FORWARD chain (hopefully gets matched by the first rule, which is for ESTABLISHED,RELATED packets), and then gets automagically reverse-natted instead of going through any rules you might have put in the POSTROUTING chain, so that the source address is now whatever the destination address of the first packet was. Basically what this all means is: 1. You do not have to specify nat rules to process reply packets - the reverse of the rules you specified for the outgoing packets will automatically be applied. 2. You *cannot* specify nat rules to process reply packets - because they bypass the rules in the nat chains as soon as they are recognised as reply packets by the entry in the connection tracking table. Destination NAT (which is what I've assumed is going here - maybe incorrectly) is done in the PREROUTING chain. Source NAT (which maybe is what you're doing ?) is done in the POSTROUTING chain. However, apart from that difference, everything else I said is correct for either situation: 1. Reply packets for NATted connections always bypass any rules in both the PREROUTING and POSTROUTING chains, and simply get automagically reverse-natted according to whatever the original nat rule was. 2. If the original packet got DNATted in the PREROUTING chain, then the reply packet gets automagically SNATted at the POSTROUTING stage (ie after going through the FORWARD chain). 3. If the original packet got SNATted in the POSTROUTING chain, then the reply packet gets automagically DNATted at the PREROUTING stage (ie before going through the FORWARD chain). 4. The FORWARD chain should always contain rules whcih relate to the "real" source & destination addresses, no matter what DNAT may have already occurred, or what SNAT may be about to occur. The nat table should be used to changes soruce and destination of packets - no more. The mangle table should be used to change packets only, e.g TOS settings. The filter tables shoyld be used to accept and drop packets (filter packets). This tables is the one must people should use. ##-------- PPPoE masquerade problem problem: server can access internet, internal can't. Check the MTU on your PPPoE and eth1 - I've heard about people using PPPoE having a problem with different MTUs on either side of the firewall - I think the solution was to clamp the larger one down to be the same value as the smaller one. This is how i have it # Allow masquerading for internal boxes ### iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE #Make sure mtu is never changed iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu ##--------- bandwidth usage Netfilter will help you track the number of packets & bytes sent to/from a specific IP address, but you'll have to check the numbers at regular intervals (eg a cron job once a minute ?) in order to convert this to bandwidth. Just create some rules such as: iptables -A FORWARD -s a.b.c.d iptables -A FORWARD -d a.b.c.d (Yes, that's correct, you don't have to have a target to jump to if you don't want one...) where a.b.c.d is the IP address you're interested in, and then use iptables -L FORWARD -n -v -x to see the packet & byte counters. ##---------- prerouting connection Once traffic got DNET'ed, all the subsequent stream is translated. so it won't go throught the PREROUTING anymore as long as the connection keey alive. ##---------- how packet traverse Packet from LAN enters eth1 Packet goes through PREROUTING chain Packet goes through FORWARD chain Packet goes through POSTROUTING chain (where the SNAT happens) Packet exits from eth0 to the Internet Packet come back from Internet enters eth0 Packet goes through PREROUTING chain (SNAT reversed automagically) Packet goes through FORWARD chain Packet goes through POSTROUTING chain Packet exits eth1 to the local network ############ E.G iptables -N mychain iptables -A INPUT -j mychain iptables -A mychain -s 192.168.0.2 -j RETURN iptables -A mychain -s 192.168.0.3 -j RETURN iptables -A mychain -j DROP This creates a user-defined chain called mychain, the INPUT chain calls the user-defined chain, where packets with source address 192.168.0.2 return to the INPUT chain and continue processing, as do packets with source address 192.168.0.3, all other packets get DROPped. dnstrace any www.aol.com a.root-servers.net > AOL & dnstracesort < AOL | less ############ small gadget notes. if we have DNAT rule in iptables, then that means the port is being listening. ############ ip alias > How should I handle the alias interfaces? For the INPUT chain, specify the destination address. For the FORWARD chain, it doesn't matter anyway.