How to prevent local traffic between two local interfaces?

There is a linux box with 3 network interfaces.
eth0 — inet
eth1 — lan1 — gw 192.168.1.1
eth2 — lan2 — gw 192.168.10.1

Users from both networks need to be Internet.

We want to make sure that none of lan2 could not see anything from lan1.

Prescribed:
iptables-A FORWARD -i eth2 -o eth1 -j DROP

But the user from the network lan2 safely gain access to the IP addresses on the eth1 interface is 192.168.1.1, which is not desirable.

upd. Helped the following:

iptables -L-v<br> Chain INPUT (policy DROP 21 packets, 1148 bytes)<br> pkts bytes target prot opt in out source destination<br> 9 488 DROP all -- any any 192.168.10.0/24 192.168.1.0/24<br / >

Thanks for the help!
October 8th 19 at 00:39
8 answers
October 8th 19 at 00:41
and route-n who will show? you never know what you have there heaped
Kernel IP routing table<br> Destination Gateway Genmask Flags Metric Ref Use Iface<br> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1<br> 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2<br> 10.128.32.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0<br> 10.128.32.1 0.0.0.0 0.0.0.0 UG 100 0 0 eth0<br> - ottis41 commented on October 8th 19 at 00:44
October 8th 19 at 00:43
you have eth1 and eth2 in one switch stuck?
eth1 and eth2 plugged into 1 server. - ottis41 commented on October 8th 19 at 00:46
October 8th 19 at 00:45
try to INPUT additionally Sweeney:
What should I INPUT? - ottis41 commented on October 8th 19 at 00:48
October 8th 19 at 00:47
It seems all right, it's hard to tell, but I would check
and in the FORWARD chain if there's a rule that comes before
iptables-A FORWARD -i eth2 -o eth1 -j DROP
and pass packets
and level switch all separated (although this question was already asked)
— but can the packages forwarded lan2 — lan0 — lan1, though like the normal route...
— by the way, on machines from lan2 — lan1 gateways are correct?
— try to log packets in iptables logs or look at them from a tcpdump-Ohm — to learn how they still leak
iptables -A INPUT-i lo -j ACCEPT<br> <br / > iptables -A INPUT -m state --state ESTABLISHED,RELATED-j ACCEPT<br> iptables -A INPUT -m state --state NEW-i ! $INET -j ACCEPT<br>
Before this rule.

Two wires plugged into 2 network cards: eth1 eth2.

12:46:15.417765 a0:88:b4:97:10:b8 > 00:0f:ea:51:5d:29, ether type, IPv4 (0x0800), length 74: 192.168.10.101 > 192.168.1.1: ICMP echo request, id 1, seq 14974, length 40<br> 12:46:15.417812 00:0f:ea:51:5d:29 > a0:88:b4:97:10:b8, ether type, IPv4 (0x0800), length 74: 192.168.1.1 > 192.168.10.101: ICMP echo reply, id 1, seq 14974, length 40<br> - ottis41 commented on October 8th 19 at 00:50
And in the FORWARD chain one rule? - ottis41 commented on October 8th 19 at 00:53
# Generated by iptables-save v1.4.On Sun 4 Apr 8 13:58:15 2012<br> *mangle<br> :PREROUTING policy ACCEPT [15110:3597713]<br> :INPUT ACCEPT [4015:689656]<br> :FORWARD ACCEPT [10538:2855605]<br> :OUTPUT ACCEPT [12374:1052019]<br> :POSTROUTING ACCEPT [22941:3912059]<br> COMMIT<br> # Completed on Sun Apr 8 13:58:15 2012<br> # Generated by iptables-save v1.4.On Sun 4 Apr 8 13:58:15 2012<br> *nat<br> :PREROUTING policy ACCEPT [2252:183531]<br> :POSTROUTING ACCEPT [12:1798]<br> :OUTPUT ACCEPT [4946:440981]<br> [6644:569427] -A POSTROUTING -o eth0 -j MASQUERADE<br> COMMIT<br> # Completed on Sun Apr 8 13:58:15 2012<br> # Generated by iptables-save v1.4.On Sun 4 Apr 8 13:58:15 2012<br> *filter<br> :INPUT ACCEPT [32:2065]<br> :FORWARD ACCEPT [0:0]<br> :OUTPUT ACCEPT [12374:1052019]<br> [11:1334] -A INPUT-i lo -j ACCEPT<br> [3863:666794] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT<br> [109:19463] -A INPUT ! -i eth0 -m state --state NEW-j ACCEPT<br> [0:0] -A FORWARD -i eth2 -o eth1 -j DROP<br> [4184:1675399] -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT<br> [6342:1178844] -A FORWARD -i eth1 -o eth0 -j ACCEPT<br> [6:976] -A FORWARD -i eth0 -o eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT<br> [6:386] -A FORWARD -i eth2 -o eth0 -j ACCEPT<br> [0:0] -A FORWARD -i eth0 -o eth0 -j REJECT --reject-with icmp-port-unreachable<br> [0:0] -A FORWARD -i eth1 -o eth1 -j REJECT --reject-with icmp-port-unreachable<br> [0:0] -A FORWARD -i eth2 -o eth2 -j REJECT --reject-with icmp-port-unreachable<br> COMMIT<br> - ottis41 commented on October 8th 19 at 00:56
Is that really going eth2-eth0-eth1.
Try this:

iptables-I 1 FORWARD -s 192.168.10.0/24-d 192.168.1.0/24 -j DROP - ottis41 commented on October 8th 19 at 00:59
I mean, this is a feeling that goes eth2-eth0-eth1 - Delbert_Bauch commented on October 8th 19 at 01:02
It does not work, unfortunately. - ottis41 commented on October 8th 19 at 01:05
And so iptables-I FORWARD 1-s 192.168.10.0/24-d 192.168.1.0/24 -j DROP - Delbert_Bauch commented on October 8th 19 at 01:08
I wrote in update that helped.
iptables -A INPUT -s 192.168.10.0/24-d 192.168.1.0/24 -j DROP
first rule. - Delbert_Bauch commented on October 8th 19 at 01:11
I mean
iptables-I 1 FORWARD -s 192.168.10.0/24-d 192.168.1.0/24 -j DROP
syntactically wrong. - ottis41 commented on October 8th 19 at 01:14
Yes, I fixed the campaign ) - Delbert_Bauch commented on October 8th 19 at 01:17
Then it should work, I give up :( - ottis41 commented on October 8th 19 at 01:20
But, read the update, well that works, but then I'm already in mysticism began to believe - Delbert_Bauch commented on October 8th 19 at 01:23
October 8th 19 at 00:49
Firewall rules work on a first match from top to bottom. If the above is a rule that falls under this traffic, all others will not be triggered.
So no. - ottis41 commented on October 8th 19 at 00:52
October 8th 19 at 00:51
Put MikroTik ROS and do not suffer if traffic is not very much.
Here are the rules from ROS, I think for iptables will think of how to rewrite

chain=forward action=drop src-address=192.168.1.0/24 dst-address=192.168.10.0/24
chain=forward action=drop src-address=192.168.10.0/24 dst-address=192.168.1.0/24

As already mentioned the rules to throw in the top
I understand it is a separate OS? I do not fit, unfortunately. - ottis41 commented on October 8th 19 at 00:54
By the way, Yes,
iptables-I 1 FORWARD -s 192.168.10.0/24-d 192.168.1.0/24 -j DROP
analogue of what is written for ROS - ottis41 commented on October 8th 19 at 00:57
it's not working. - ottis41 commented on October 8th 19 at 01:00
October 8th 19 at 00:53
192.168.1.1 belongs to the server, not the network behind it, so the rules for this case will be different.
What to do, how to prevent? - ottis41 commented on October 8th 19 at 00:56
As a normal incoming packet (INPUT/src/dst) - ottis41 commented on October 8th 19 at 00:59
October 8th 19 at 00:55
*deleted*

Find more questions by tags LinuxNetwork routing