Iptables config - want one way visibility but not vice versa

Sorry if this has been asked before, but I tried and searched for 2 days without success. Here goes:

First the setup:

One LAN, two gateways. One gateway is, and the other is These two gateway devices are linked via ethernet cable. Which means traffic flows freely between them. ONLY the one with is running Openwrt. The other runs stock firmware and config options are rather limited.

Hosts (clients) can be thought of as connecting either to the first or second gateway. The ones connected to all have 192.168.0.x/24 addresses, and likewise for the ones connected to, they all have 192.168.1.x/24 addresses. NOTE - subnet masks for these end devices are all 24 or I think this means to access machines on the 'other side', they will need to route packets through their respective gateways.

Now this is what I want to do:

All hosts (clients) on 192.168.0.x can see and communicate with clients on 192.168.1.x BUT NOT VICE VERSA. For example if I telnet from to, I can see login screen and be able to login etc. But not the other way around.

What I tried:

On gateway, I used iptables and added two rules to the FORWARD chain:

iptables -I FORWARD 1 -d -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD 2 -d -j DROP

What resulted:

Communication is cut BOTH WAYS. Machines on 192.168.0.x can't telnet to 192.168.1.x either. If the rules are deleted, then no problem. Telnet requests are accepted both ways.

I may have the wrong understanding of the --state option? Or is what I want to do even possible?

Thanks anyone in advance for your help !!!

Why are you using a /23 mask and not /24?

1 Like

... will they even see each other if i use /24?

First you need to split VLANs, this step is compulsory.

Then you have 2 ways:

  • Set up bridge firewall.
  • Use different subnets:
    • Split /23 into /24 subnets.
    • Assign them to different firewall zones.
    • Add a forwarding from one zone to the other.
    • Add a static route on the other router to the OpenWrt subnet or enable NAT on OpenWrt.


Was gonna avoid VLANs, as the gateway on stock firmware doesn't do VLAN, plus my OpenWRT gateway (TP-Link MR3420) has an issue with VLAN configurations.

If iptables (or ebtables etc) cannot accomplish what I want, then maybe I will have to shell out some $ to buy new OpenWRT capable routers.

Thanks for your help.

Solved ! (Someone at reddit gave me good pointers)

Turned out to be a matter of tweaking the iptables' parameters. Also you need "-m conntrack" not "-m state" for openwrt.

This is the only rule needed in iptables:

iptables -I FORWARD -p tcp -s -d -m conntrack ! --ctstate NEW,ESTABLISHED,RELATED -j DROP

This will cause traffic from 192.168.0.x to 192.168.1.x to be denied, and the other way around to be accepted (i.e. the opposite of what I stated in my original post, but the important thing is one way traffic can be achieved).

And another important thing to note is that the 'Masquerading' option must be turned on for the zone in question (in my case 'LAN').

Typically, a hardware switch does not forward traffic on the same VLAN to the OS. :thinking:

In a bid to not mislead anyone I will admit to my mistakes.

The IPTables command in my comment above simply has incorrect syntax. The way it is constructed above will simply not work. What inadvertently made it work for me (on hiding a section of the network from the other side) was actually the masquerading.

This article that I stumbled upon actually does a great job of explaining the state progression of packets as they get generated and transmitted across networks. With this info I tried tweaking my IPtables (with masquerading off) but no matter what I do there seems to be "packet leaks" where maybe 1 out of every 100 pings will get through to the other side etc. It is possibly due to my crazy setup of /23 on some of the routers making it possible for alternate routes to be dynamically formed, I don't know. But long story short, I ran into other technical challenges setting everything back to /24, and I gave up. So I turned masquerading back on for my LAN zone.

Now I have no clue why masquerading will make one side of the network become "hidden", but as long as it works I am not complaining. No need to even set any iptable rule.

Masquerading off, both sides can see each other.

Masquerading on, one side can see the other but not vice versa.

Looking back, I believe doing VLANs will make the setup more "orthodox" and will allow for the application of features as they are intended to be applied. But... If it ain't broke, why fix it?

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.