On Monday 14 May 2012 15:35:16 carlopmart wrote: > Sorry If you have misunderstood me, but I only want to allow that host > to access to a specific LAN, not this LAN access to this host > (http://marc.info/?l=netfilter&m=133697780513851&w=2) ... Allow me to restate the rules in a slightly different format. At least four rules are required if you wish to absolutely restrict a host to communicating with some other LAN. And these four rules must be the first rules in the FORWARD chain in order to be guaranteed to work regardless of other rules you may later add after them in the chain. Definitions: 'the host': the host you wish to restrict. 'the LAN': the only LAN 'the host' is allowed to access. It is specified symbolically as you did not specic an address for it. 'conn': an established TCP/IP 'relation' between two hosts, whether it is using a connection-oriented protocol like TCP or SCTP or a connectionless protocol. 'NEW': the first packet of a new, not-yet-established conn. 'RELATED': the first packet of a new, not-yet-established conn that a helper module has determined is related to an existing conn between those two hosts. 'ESTABLISHED': a packet belonging to a conn that has seen traffic in both directions. Once established, there is no way to determine if a conn started out as NEW or RELATED (well, without resorting to CONNMARKs). The first two and last two rules below together guarantee that 'the host' may communicate ONLY with nodes on 'the LAN', regardless of any rules you may add after. Do note that rules you add *before* these six rules may affect 'the host' if they are not written with great care. -------------- # The first two rules explicitly allow traffic between 'the host' and # 'the LAN'. You must explicitly allow packets travelling in each # direction. Once a packet is ACCEPTed, no further rules are processed. # Allow 'the host' to access 'the LAN' using NEW and RELATED initial # packets and packets in ESTABLISHED conns iptables -A FORWARD -s 172.24.50.3/32 -d a.b.c.d/netmask \ -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT # Allow nodes on 'the LAN' to access 'the host' using RELATED initial # packets and packets in ESTABLISHED conns iptables -A FORWARD -s a.b.c.d/netmask -d 172.24.50.3/32 \ -m state --state RELATED,ESTABLISHED -j ACCEPT # The next two rules log traffic from 'the host' to anywhere else # and from anywhere else to 'the host'. Rule processing continues # after the packet has been LOGged. # Log packets from 'the host' to anywhere else iptables -A FORWARD -s 172.24.50.3/32 -j LOG \ --log-prefix "FORWARD found packet from 172.24.50.3 to somewhere else: " iptables -A FORWARD -d 172.24.50.3/32 -j LOG \ --log-prefix "FORWARD found packet to 172.24.50.3 from somewhere else: " # These last two rules explicitly drop traffic between 'the host' and # anywhere else. They preclude unintended consequences of new rules # you may add to the end of the chain in the future. iptables -A FORWARD -s 172.24.50.3/32 -j DROP iptables -A FORWARD -d 172.24.50.3/32 -j DROP -------------- The first two rules allow traffic between 'the host' and 'the LAN' as you require. 'The host' may access any node on 'the LAN' at any time using any IP protocol. Nodes on 'the LAN' may send all return traffic and may open RELATED conns as detected by a netfilter helper module (such as FTP's DATA channel) but may not otherwise initiate unsolicited conns to 'the host'. The second two rules are optional if you don't want to track attempts by 'the host' to access other nodes. The last two rules are optional if you will never add more rules to the end of the chain because the chain's policy, DROP, will drop those packets. If you plan to add more rules to the end of the chain, I strongly suggest you use these last two rules to ensure that your added rules don't interfere. Again, the two ACCEPT rules and the two DROP rules together guarantee that 'the host' may communicate only with nodes on 'the LAN' even if you add more rules to the end of the chain. But remember that carelessly written rules you insert *before* these four rules can change the restrictions you've placed on 'the host' and negate that guarantee. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
