[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: IPTABLES rule for separating users

erikmccaskey64 put forth on 3/5/2011 2:58 AM:
> I have an OpenWrt 10.03 router [ IP: ], and it has a DHCP server pool: - clients are using it through wireless/wired connection. Ok!
> Here's the catch: I need to separate the users from each other.
> How i need to do it: by IPTABLES rule [ /etc/firewall.user ]. Ok!
> "Loud thinking": So i need a rule something like this [on the OpenWrt router]: 

This likely won't work because all hosts are on the same subnet, and
only traffic destined outside the subnet is forwarded to the gateway
address, which is the LAN port of the firewall in this scenario.
Traffic within the same subnet will bypass the OpenWrt IP stack.  This
is simply how TCP/IP is designed to function.  You _might_  be able to
get around this with some funking client stack masking and some bizarre
iptables rules, however I've never attempted nor heard of such a thing.

The way your goal is accomplished in high security environments in the
real world is with MAC address filtering at the ethernet switch level,
but more often with VLANs.  Usually this is used to separate
departments, but not the hosts within a given department.  The
integrated switch in your consumer router probably does not offer this
level of capability.

Also, due to the built in switch chip and ARP discovery, the private
ethernet interface chip of the router device won't even see the ethernet
frames in which the subnet IP packets are transported.  In layman's
terms, the kernel won't have any clue such subnet traffic even exists,
due to the switch.  Simplified functional diagram:

              Switch Chip
Wired--------|           |----------Wireless
                   <--- Intra-subnet traffic barrier
                 -----        ------        -----
       Eth0 LAN |     |------|      |------|     | Eth1 WAN
                 -----        ------        -----
                           Linux Stack

If you shared your *reasoning* behind this with us we might be able to
offer you alternative solutions.


Reply to: