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 192.168.0.1/23, and the other is 192.168.1.1/23. These two gateway devices are linked via ethernet cable. Which means traffic flows freely between them. ONLY the one with 192.168.0.1/23 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 192.168.0.1 all have 192.168.0.x/24 addresses, and likewise for the ones connected to 192.168.1.1, they all have 192.168.1.x/24 addresses. NOTE - subnet masks for these end devices are all 24 or 255.255.255.0. 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 192.168.0.2 to 192.168.1.249, I can see login screen and be able to login etc. But not the other way around.
What I tried:
On gateway 192.168.1.1, I used iptables and added two rules to the FORWARD chain:
iptables -I FORWARD 1 -d 192.168.0.0/24 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD 2 -d 192.168.0.0/24 -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?
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.
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').
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?
