Hello.

Even if the "rules"-list tells me not to post "can anyone help me?" topics I'll dare it now because my question seems to be not that simple
And if this topic somehow already exists - sorry: didn't use the right search terms.

What I have:
2 WRT54Gv2.2 with OpenWRT whiterussian RC2 and a set up WDS-bridge with WPA (like in Jean-Michel Smith's HowTo). Works perfectly till now.
Nothing else (concerning OpenWRT )

What I want:
On one of the two WRTs I'd like to have the 4 LAN-ports 'separated' from each other that means e.g.:
client on port1 can't connect to client on port2, and so on.
BUT: each of the 4 LAN-port-clients should be able to access the other WRT and/or its internet-connection.
That would be just like what AP-isolation is in wireless-mode.

Can anyone tell me where to look or what to setup?

The best would be a detailed step-by-step HowTo, for sure.

Would be awesome if someone could help me. I desperately need a solution...

Thanks!

First enable vlan separation as described here :

http://openwrt.org/OpenWrtDocs/Configur … 37c5318626

Then disable ipv4 forwarding between each interface of the vlan, for that edit /etc/sysctl.conf

net.ipv4.ip_forward=0

finally set up your internet connection, this should do the trick

Thanks for the advice!

I tried but it didn't work as I wanted.

What I did:
On both WRTs (I wanted port1 and 2 to be 'normal' connected and ports 3 and 4 separated)

nvram set vlan0ports="1 2 5*"
nvram set vlan0hwname=et0
nvram set vlan1ports="0 5"
nvram set vlan1hwname=et0
nvram set vlan2ports="3 5"
nvram set vlan2hwname=et0
nvram set vlan3ports="4 5"
nvram set vlan3hwname=et0

might that be correct??

What happend:
only on ports 1 and 2 I have connection, ports 3 and 4 are "dead", no pinging to anywhere.
setting net.ipv4.ip_forward to 0 doesn't change a thing.

Any further idea?

Ok I see, let's use iptables for that :

iptables -A forwarding_rule -i <vlan1_port> -o <vlan2_port> -j DROP
iptables -A forwarding_rule -i <vlan2_port> -o <vlan1_port> -j DROP
iptables -A forwarding_rule -i <vlan1_port> -o <vlan3_port> -j DROP
iptables -A forwarding_rule -i <vlan3_port> -o <vlan1_port> -j DROP
iptables -A forwarding_rule -i <vlan2_port> -o <vlan3_port> -j DROP
iptables -A forwarding_rule -i <vlan3_port> -o <vlan2_port> -j DROP

This should to the trick : deny forwarding from vlan1 to vlan2 and vlan3 and same thing for each vlan you have (vlan2 and vlan3).

A kind person with the name of fxd0h just enlightened me on a parallel thread -- try using the vconfig command:

vconfig add eth0 2
vconfig add eth0 3

It worked for me (the vlan2/3 interfaces should now appear, and you can assign ip addresses to them).

Good luck!

Netfetz: Can you post the output of ifconfig? What ip addresses/netmasks are you using for vlan 2 and vlan 3?

RitalMan: Why disable IP Forwarding?  Netfetz wants all the LAN segments to be able to access the Internet.  If IP Forwarding is turned off, doesn't the unit cease to be a router?  Your iptables solution seems to be a much better idea.

Yeah danversj you are right about ip forwarding, it should be still set to on and let the firewall rules do their job.

Wow: MASSIVE support! Thanks!!

OK, net.ipv4.ip_forward is set back to 1.

RItalMan: In the iptables command I have to replave <vlan2_port> with the ip I assign to vlan2 (not with "vlan2" or anything else), right?

mgc8: I tried "vconfig add eth0 2", but where should the added vlan2 now 'appear'? In the output of ifconfig? There still are only vlan0 and vlan1 listed (see below).

And how can I assign an ip to a vlan? With "ifconfig vlanX x.x.x.x"?
What ip scheme should I use for that?
Do vlan0 and vlan1 already have an assigned ip?

danversj: Right now my ifconfig output looks like this:

root@host:~# ifconfig
br0       Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:x0  
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:38 errors:0 dropped:0 overruns:0 frame:0
          TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:3895 (3.8 KiB)  TX bytes:5451 (5.3 KiB)

eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:x0  
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:34 errors:0 dropped:0 overruns:0 frame:0
          TX packets:150 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4159 (4.0 KiB)  TX bytes:19611 (19.1 KiB)
          Interrupt:5 Base address:0x2000 

eth1      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:x2  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:17
          TX packets:106 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:370 (370.0 B)  TX bytes:6766 (6.6 KiB)
          Interrupt:4 Base address:0x1000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:168 (168.0 B)  TX bytes:168 (168.0 B)

vlan0     Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:x0  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:34 errors:0 dropped:0 overruns:0 frame:0
          TX packets:138 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:3547 (3.4 KiB)  TX bytes:12483 (12.1 KiB)

vlan1     Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:x0  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:7128 (6.9 KiB)

wds0.4915 Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:x2  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Another question: shouldn't I delete the "lo" (local loopback)?

Thank you all so much so far!!!

Hi all,

I managed to do that with adding the nvram variables xxx_ipaddr xxx_ifname xxx_netmask xxx_proto;
then in /etc/init.d/S40network just add the new interfaces xxx below the built-in lan, wan, wifi like that:

#!/bin/sh
case "$1" in
  start|restart)
    ifup lan
    ifup wan
    ifup xxx
    ifup wifi
    wifi up
(...)

Maybe you also have to configure routing - at least, if you do not have a single default gateway.

OK, very interesting solution.
But how do you assign a new interface to a lan-port? Or did I get that totally wrong?

I already read the other topic dealing with vlans http://forum.openwrt.org/viewtopic.php?id=2314 (why robocfg??) but am still confused about getting these things to work.

In my previous post there are still options I really don't know how to handle.

Any further advice?

Yes, in my case ifconfig vlan2 shows the added interface (before the "vconfig add" command it would display an error message).

Yes, that would be the right command. The IP scheme used should be depending on what you plan to connect to those ports... From the previous posts, I believe that you want to have 4 sepparate LAN's, is that correct? You could use a few subnets from the 192.168.x.x range, like for example:

ifconfig vlan1 192.168.10.1
ifconfig vlan2 192.168.11.1
ifconfig vlan3 192.168.12.1

And then the machines would get IP's in the corresponding subnets, depending on what port they connect (I am not sure if dnsmasq cand handle this, but I see no reason it shouldn't).
If you enable ip_forward then they would be able to communicate with each-another, otherwise they will simply be invisible. For finer-control you can use the firewall rules, of course.

No, you need to supply one to them via the corresponding xxx_ipaddr, xxx_proto etc. nvram variables (where xxx is the name you supply to ifup as in ifup xxx).

fyi:  ifconfig doesnt show "down" interfaces , so basically when you do

 
ifconfig

you woudnt get the new vlans

so why dont you try to show em all ?

ifconfig -a

and if they are in there you might try to set up em , assigning an ip address to 'em and  UP them

ifconfig vlan4 192.168.4.1
ifconfig vlan4 up

my .02 euros

From my previous post:

(...) add nvram variables xxx_ipaddr xxx_ifname xxx_netmask xxx_proto;
then in /etc/init.d/S40network just add the new interfaces xxx below the built-in lan, wan, wifi like that:

#!/bin/sh
case "$1" in
  start|restart)
    ifup lan
    ifup wan
    ifup xxx
    ifup wifi
    wifi up

Just add the following nvram settings to get a vlan (only port 4) called vlan2 that you assign the interface name xxx:

vlan2ports=4 5
vlan2hwname=et0
xxx_ifname=vlan2

Aaah, great: now I understand how this should work. I already thought it might work that way but didn't trust myself

I set it up like this, vlans are all up and have assigned ips etc.

BUT: it is still the same situation as I wrote in my second post:
I cannot ping ANYthing from LAN-port 3 or 4. Not even the corresponding vlan-ip itself.
Only when I'm connected to port 1 or 2 I can ping everything (as if I changed nothing).

Any idea what is wrong?

Please oost here the results of ifconfig -a, iptables -L -n -v and route -n after you make all the configurations.

OK, now I know what was wrong: I simply forgot to add the new vlans to the "lan_ifnames" variable!
It was set to "vlan0 eth1" and now I set it to "vlan0 vlan2 vlan3 vlan4 eth1" and so every port works perfectly.
Now it is just like I didn't change a thing: a regular 4port-switch but with IPs assigned to every port

I tried RItalMan's advice with the iptables but that doesn't seem to work: I still can ping every port from each other port.
What I did:
iptables -A forwarding_rule -i port1 -o port2 -j DROP
iptables -A forwarding_rule -i port2 -o port1 -j DROP
and so on for every combination.

Is there any other "bridge" (which connects the vlans to each other) that I have to 'drop'?

(Last edited by Netzfetz on 29 Aug 2005, 08:27)

Hmm, I think the iptables somehow don't take affect: e.g. if I make the rule "iptables -A forwarding_rule -s <IP of a network card> -d <IP of another network card> -j DROP" and vice versa, both cards still can ping each other perfectly (the network cards are installed on different PCs and connected to the same WRT).

So either something bypasses the iptables DROP-rules or on my setup there is something blocking the iptables.

Any idea for a rule to test that?
Or a solution?

Somehow on my setup the iptables DO NOT apply...
I tried any rule in every chain but nothing changed. I edited firwall.user but that didn't help either.

Is it because of the "br0"-bridge?? Is it "stronger" than the iptables???
Is it correct to include all the vlans in "lan_ifnames" (if not, nothing works...)??

So close to a solution but still that far from it...

How did you do that, WRT Shredder?

Any hint?

I would have to search for the link, but I think that the ebtables patch has been dropped which means that you can't use iptables to limit traffic on the bridge.  I think you just need to recompile having switched the patch back on, but I will have to look see what the option is.  Search the forum for ebtables and iptables and see if you can spot what I mean.

P.S. I want to do something similar to what you have done, but putting all the vlans in the same address pool.  ie I want a single address space, but ability to limit traffic from a given port to speak to other ports.  Can this be done?  I found that setting multiple vlans to have the same IP address just locked me out of the box...

The best way to separate traffic is to separate networks. Why dont you break the bridge, create a virtual interface
(xxx1 xxx2 xxx3 xxx4) on each port (including the wireless interface) with ip addresses in different subnets and use
a combination of ip routing and filtering?
This way you can use your outside (aka WAN) interface as the default gateway for all networks (functionality)
with the ability to restrict traffic between the networks (security).
You may have a look on fwbuilder (http://www.fwbuilder.org) to create your firewall - just replace the openwrt
firewall script (/etc/firewall.user) with the one installed by fwbuilder (/tmp/your_name_here.fw).

Yeah, that would be great!

But it seems iptables are not working at all on my WRTs...
I can write in there whatever I want, NOTHING changes!!

Did not try fwbuilder yet, had not enough time to get familiar with that tool

Did you read my post about how the ebtables patch is missing and hence how it's NOT going to work??!

I haven't yet got my build to install properly yet so I haven't tested it myself, but I think you need to wander along to the ebtables.sf.net site and grab the ebtables patch which lets you use iptables to influence the bridge.  Rename the patch and drop it into (from memory) ./target/linux/linux-2.4/generic/patches/

Then rebuild everything and it *touch wood* should be ok.  I have tested this and it compiles ok, but still working on getting it to install without going into an endless loop (this doesn't seem to depend on whether this patch is installed by the way, it's something else)

Good luck

SHURE, I read it.

But does that mean iptables does not work at ALL?? I thought the missing patch only concerns internal routing or whatsoever.

Well, I'll try to kick the bridge but I fear to be locked out of the Router.

So, did I get thet right: if the "br0" bridge is set up, iptables won't work. That means I have to set up my iptables, delete the bridge and cross fingers that it works?

iptables cannot influence traffic running across the bridge in kernel 2.4.  This is fixed by the patch I referred to, which also used to be in openwrt by the way, but was removed because it caused too much of a performance hit in general (apparently).  The patch is in kernel 2.6 by default

So you can "route" traffic and then iptables works again, but you can't use iptables to control traffic running across the bridge (but I see no reason why you can't limit the traffic entering and leaving the box itself, if you see the difference?)

I just noticed that when you do "make menuconfig" there is an option under the kernel config to have "ethernet bridge firewalling support".  I haven't tested to confirm, but this *may* apply the patch I just described above

Please let me know if you test it (I just applied the patch manually)