I have network A (remote) and network B (local).
Network B needs to be able to access network A, but nobody should be able to access network B. How would I go about putting an IPTABLES rule in the router for network B to do this?
I have network A (remote) and network B (local).
Network B needs to be able to access network A, but nobody should be able to access network B. How would I go about putting an IPTABLES rule in the router for network B to do this?
try adding an inbound rule to drop the subnet's traffic:
# iptables -A INPUT -s 192.168.100.0/24 -j DROP
INPUT
table to your router will drop all traffic from that network, period.
POLICY DROP
in your INPUT
chain and this is the last rule, then it's superfluous. 2. This will only drop traffic directed at the router itself, not between two networks; you need the FORWARD
chain for that.
Mar 14, 2013 at 9:09
FORWARD
chain and the default policy was ALLOW
, this would kill all the reply packets.
It's possible to do this with iptables
, but you need to be mindful of connection states. You have to allow reply packets from Network A without allowing them to initiate new connections into Network B.
Something like this should do:
iptables -A FORWARD -i eth_netA -o eth_netB -s 10.1.2.3/24 -d 10.4.5.6/24 -m state --state=established,related -j ACCEPT
# if your default policy is ALLOW:
iptables -A FORWARD -i eth_netA -o eth_netB -s 10.1.2.3/24 -d 10.4.5.6/24 -j DROP
# if your default policy is DROP:
iptables -A FORWARD -i eth_netB -o eth_netA -s 10.4.5.6/24 -d 10.1.2.3/24 -j ACCEPT
Note that we're using the FORWARD
table here, not INPUT
. This is because your machine is routing packets between networks, and you're wanting to catch packets that aren't bound for the router itself. You can leave off the -s
and -d
statements if you simply want to apply these rules to all traffic being forwarded across those two interfaces.
Be advised that this relies upon the connection tracking features of iptables (which is already loaded if you have any -t nat
rules), and you may need to do some tuning of ip_conntrack
parameters if you're sending a heavy load of packets back and forth. The most common warning sign is the table full, dropping packet
message in syslog.