What is the best way to isolate one device from others without a subnet?

Discussion in 'Tomato Firmware' started by Trent Bates, Apr 22, 2013.

  1. philess

    philess Networkin' Nut Member

    Ok, this seems to work now.

    My setup:
    br0 is my main private network (wl0 plus lan-switch)
    br1 is connected to my guest network (wl0.1)
    I only want to isolate the clients inside wl0.1 from each other.

    In Administration, Scripts, Firewall:
    wl -i wl0.1 ap_isolate 1
    ebtables -I FORWARD -i wl0.1 -o wl0.1 -j DROP
    Save & reboot router.
    (I am sure there is a easy way to restart the wl driver, but thats not important right now).

    Now i have 2 clients, both connected to my wireless guest-network (wl0.1).
    Ping from Client1 -> Client2: FAIL
    Ping from Client2 -> Client1: FAIL
    Ping from Client1 -> Router: WORKING
    Ping from Client2 -> Router: WORKING
    Internet access from both clients: WORKING

    Moved the two clients to my private network (wl0):
    Ping from Client1 -> Client2: WORKING
    Ping from Client2 -> Client1: WORKING

    Exactly as it should be :) Guest-Clients cannot access each other but surf the web,
    private clients are not affected and can access whatever they want.

    Unfortunately i can only test ping right now, no other types of access (both my devices are ipads).
    But if ping fails, so should pretty much everything else.

    A very very huge THANK YOU to Trent Bates for investing so much time in finding the right commands!
    Holy_Hunter, gfunkdave and Elfew like this.
  2. Bird333

    Bird333 Network Guru Member

    If that's all you want to do you shouldn't need that ebtables rule.
  3. philess

    philess Networkin' Nut Member

    As we have discussed in this thread, isolation by the wireless driver alone is not enough (in theory).
    Because the router would route between the clients if they fail to access each other directly.
    In reality, the isolation alone should take care of most scenarios but for 100% isolation the ebtables is required.
    It will probably work fine without it tho.
  4. Bird333

    Bird333 Network Guru Member

    The way I understand it is that the ebtables rules are for stopping traffic between interfaces that are within the same bridge. For example, if you have both wl0.1 and wl0.2 within br1 and you didn't want wl0.1 and wl0.2 to 'see' each other you would need the ebtables rules. The whole reason that the wl driver isolation had to be used is because ebtables couldn't stop traffic between clients on the same interface (i.e. wl0.1). Well at least no one has shown how it can be done yet if possible.
  5. philess

    philess Networkin' Nut Member

    True, but i was/am under the impression that both are needed. ebtables & isolation.
    As i said, i dont have any actual notebooks here right now to better tests :(
  6. Trent Bates

    Trent Bates Serious Server Member

  7. Trent Bates

    Trent Bates Serious Server Member

    Bird333 and philess,

    You both know that I'm certainly no expert!!! My rudimentary understanding aside, I have come to understand that ebtables stands for ethernet bridge tables.
    It seems possible that in philess's situation, the ebtables rule might not be necessary, but I wonder if it might have some desired effect anyway.

    I wish I was further in my understanding of what happens in this command! I've got too many other things going on to focus on it like I'd like to.
    ebtables -I FORWARD -i wl0.1 -o wl0.1 -j DROP
    So, in trying to dissect this for my own understanding,
    the above line states that this rule will be "inserted" (-I) in ebtables.
    FORWARD indicates that the "frame is to be bridged".
    The "-i wl0.1" and "-o wl0.1" parts are the input interface and output interface of the FORWARD command.
    -j is jump... I don't get that yet.
    DROP indicates an action to take, but I'm not clear on that yet either.


    As I said, I certainly don't know this stuff well yet. One thing I would recommend to philess is the addition of a removal entry before inserting a new one. I have found that they build up with each iteration of the firewall script.
    I might suggest something like this:
    wl -i wl0.1 ap_isolate 1
    ebtables -D FORWARD -i wl0.1 -o wl0.1 -j DROP
    ebtables -I FORWARD -i wl0.1 -o wl0.1 -j DROP
    Is that necessary? I'm "flushing" ebtables before inserting to avoid this problem, but someone out there might have existing entries and it seems -D might be a better way to go.

    I'm noticing the absence of the "!" invert character in the example. It seems that this ebtables entry works differently than some examples I've seen.

    This might be interesting. http://ebtables.sourceforge.net/documentation/what.html
    Holy_Hunter likes this.
  8. Bird333

    Bird333 Network Guru Member

    Once again I am no expert in ebtables but from what I understand they basically work like iptables but only on interfaces. His rule is saying anything coming in from wl0.1 and going out wl0.1 drop the packet. Just think of 'jump' as 'goto'. As far as I know there is nothing special about '-j'. I don't think that ebtables rule above will work. It is attempting to do the same thing that the 'ap isolation' command does. Basically, I don't think traffic inside the wl0.1 interface ever leaves the driver to go to the kernel which is where ebtables would act on the packet. Someone with more kernel knowledge may correct me on that. BTW, I responded to your post on smallnetbuilder.
  9. Trent Bates

    Trent Bates Serious Server Member

    I can see how philess's entry seems to duplicate the isolate function of the driver. Maybe philess would be willing to try without ebtables and see if the ping test returns the same results?

    I read somewhere that DROP in ebtables isn't quite the same as DROP in iptables. I had the impression that it was an "if/otherwise" kind of thing. Maybe it was that DROP doesn't delete the packet, just acts on it or lets it move forward. (Nevermind, that applies to "brouting".)

    philess, are you running this on the RT-N16 that you recently got? I'm curious about the other interfaces that you have in play. Are those doing what you want in relation to wl0.1?
  10. philess

    philess Networkin' Nut Member

    No, i havent tried on a RT-N16 yet. This was on the E4200. And yes, the other interfaces behaved just normally like i said.
  11. Ab Origine

    Ab Origine New Member Member

    Hi Everyone,

    My first post in here.
    I know this thread has not been active for a while, but I have a situation where someone might be able to help me out with it.

    I have 3 routers with latest Tomato Shibby 1.32 installed.
    they are all hard wired and are respectively on channels 1,6 and 11.
    I have basically expanded wifi coverage this way in order to be able to roam between devices.
    All these routers are connected to main router (non wireless) which is connected to the internet.
    DHCP is being handled on the main router (let's call it Router 1), and all three wifi devices are acting as AP's, with ethernet cable connected to their LAN ports.
    I have one 2.4GHZ SSID, one 5GHZ SSID and one 2.4GHZ virtual wireless SSID - the last one is setup for guests.

    My goal is to separate guest SSID from accessing other wired/wireless devices on network. Basically I want guests to be able to browse internet only and nothing on internal LAN.
    I have a single subnet of
    WAN and DHCP options are disabled on all wireless AP's.

    I don't want to create separate subnet or vlan.
    Is there a way to disable guest access to local resources with these settings?

  12. Monk E. Boy

    Monk E. Boy Network Guru Member

    The only way you will be able to block traffic from one system on a LAN/WLAN from talking to another system on a LAN/WLAN is by putting a firewall rule on the target system that ignores traffic from one (or more) systems. However the traffic still goes between systems, it's just ignored by the system that's firewalled off.

    If you want to isolate a guest WLAN from your normal WLAN/LAN then you need to create a second network for guests to connect to. That network can then be isolated from the main network, or allowed selective access, or whatever rights you wish to give it.
  13. Ab Origine

    Ab Origine New Member Member

    Thanks, I guest I will stick with my current config then as I don't want to create additional vlans...
    Would have been a helpful feature though, something that is readily available on stock ASUS firmware.
  14. Bird333

    Bird333 Network Guru Member

    What feature are you talking about on the stock firmware? It might be possible to use ebtables to keep the virtual interface from the other systems. However, to keep clients from seeing each other that are on the same virtual interface; it will have to be done in the wireless driver.
  15. eibgrad

    eibgrad Network Guru Member

    @Ab Origine, I can understand the reluctance to create additional VLANs and/or networks *if* those guests had some reason to interact w/ the rest of the network. The obvious case is printers, or perhaps streaming media services that rely on network discovery. Network discovery doesn’t work across networks, so that can be a hassle. But if none of these apply, I just don’t get it. Who cares if it’s another VLAN and/or network? What’s the reluctance? What’s the real underlying concern or issue here?

    Frankly, if it was me, I would connect the router for the guest network over its WAN rather than LAN. In that sense you're using another VLAN and network, but it's not like you're mucking w/ the primary router; it's just the nature of using that router *as* a router. And it has its own network (e.g., 192.168.2.x), DHCP server, firewall, etc. All you need to do is add some firewall rules to prevent guests from accessing any private upstream networks. I even have a firewall script on PasteBin for such a router.


    IOW, once you have several routers at your disposal, you don’t really need to deal w/ VLANs, virtual SSIDs, and the rest of it. That only makes sense when you’re trying to stretch the functionality of a single router. But with all those routers, why limit yourself? Just assign routers to specific needs.

    This has the advantage of being able to manage the guest network entirely independently of the primary router. You can literally disable the guest network by pulling the plug (ethernet or power), or move it to a completely different primary router, as long as its local network doesn’t conflict w/ the primary router’s network. It also means that QoS service can be managed easily for guests by limiting the downlink/uplink speeds. You can have separate IP and bandwidth reporting, can use a captive portal, yada yada, all without any concern for the primary router.
    Last edited: Nov 13, 2015
  16. Ab Origine

    Ab Origine New Member Member

    The only reason I don't want VLAN or other subnet is in order to utilize roaming within three routers.
    If they are on different subnets, then the clients would need to get new IP address from DHCP everytime they move.
    I will just stick with two SSID's, 2.4 and 5ghz at the moment and disable guest.
    Thanks for your input though
    Last edited: Nov 13, 2015
  17. Monk E. Boy

    Monk E. Boy Network Guru Member

    If you wanted to utilize roaming between routers they should all use the same SSIDs & passkey. As it is right now, your systems aren't roaming, they are issuing a DHCP request every time they join a new network (which is determined by the SSID). Because you have a single DHCP server it seems to you that they don't, because they always get the same IP address due to their MAC address not changing, but to the device it is joining a new network every time you change SSIDs.

    You only need two subnets. One for your guest network, which your systems should never join, and another for your systems. Your systems never join the guest network, they never need to worry about changing IPs.
    eibgrad likes this.
  18. eibgrad

    eibgrad Network Guru Member

    Ah, I didn’t understand your original setup. I thought you were setting up two of the APs for the private network, and the third for guests. What you’re doing is establishing guest networks on every AP.

    Beware, roaming w/ these consumer routers is not true roaming anyway. It's not like the cellular network where there's a well-defined protocol and clean handoff from station to station. These routers merely hang on to the current AP until the signal becomes so weak, they jump to a stronger signal. When that happens, they drop their current connections and communicate w/ DHCP all over again. And as long as the lease is still active, they should use the same IP. It's just giving the "illusion" of roaming. If this was "real" wifi roaming, clients would be handed off from AP to AP w/ no further interactions w/ DHCP required, no lost connections, all context preserved, everything continues as if nothing happened. The APs actually pass data between themselves to manage the handoff. Ain't so w/ most wifi. Not unless the OEM/stock firmware is supporting it, which is rare.

    So I don’t see how having everyone using the same network, private or guest, really matters wrt DHCP and IP assignments. As long as guests remain guests and private clients remain private clients as they all change APs, it seems irrelevant if they use different networks. To whatever extent roaming is effective/ineffective, it remains equally effective/ineffective, regardless.

    I’d might have a completely different opinion if you could explain how guests could end up w/ different results than private clients just because they used a different network. But I’m just not seeing it.

    Btw, it’s not my intent to beat a dead horse if you’d made up your mind to move on to another solution. Feel free to not even respond if that’s the case.

    UPDATE: LOL, Monk E. Boy beat me to the punch!
  19. eibgrad

    eibgrad Network Guru Member

    @Monk E. Boy, now that I think about it, I can see a problem. If the guest VAPs are using their own DHCP servers (which is the usual config), then indeed as the guests jump from AP to AP they will end up w/ different IPs within their own network. We typically then NAT these guests over the private network of the private AP on that router. That's just a consequence of not having DHCP handled on the primary router for these guests. But perhaps DHCP can be forwarded to the primary router and have the clients configured there?? But that assumes the primary router is using third party firmware as well. That is where having the primary router manage the IPs over the same network for private and guest users comes into the picture.
  20. jerrm

    jerrm Network Guru Member

    He has one "gateway" router handling all DHCP. The Tomato units are functioning as access points. He should be roaming without getting a new IP on either SSID.

    What he wants could probably be accomplished with ebtables on each access point blocking access to all IPs (other than the router and maybe a few other selected hosts) from the guest SSID virtual adapter. Each access point would need the ebtables rules applied, and guests attached to AP1 may not be able to see guests on AP2 unless they could be configured to get specific IPs from the central DHCP server (not likely).

    I'm not recommending such a solution by any means, but it is doable with some limitations.
  21. Ab Origine

    Ab Origine New Member Member

    Thank you all for your inputs.
    Jerrm, is right about my setup...
    Now that I am thinking, it will make things complicated with 3 AP's with ebtables and etc...
    I will stick to two SSID per AP for the time being, without guest access...
  22. Monk E. Boy

    Monk E. Boy Network Guru Member

    I would assume if you want to setup a large area guest network, with the guest network defined on every AP, then you would need to implement VLAN tagging to tie the various VLANs together across multiple APs. That way no matter which AP they roam to, they end up on the same network, with the same DHCP lease. I've never done this in Tomato but the principle is sound, although it could entail some work since you'd have to reconfigure all the routers/APs.

    I was assuming that, for simplicity's sake, he'd just define the guest network on his main router and leave the APs on his main network. The guest network will work, it'll just be less than ideal in some areas.

    Roaming between APs is certainly hodge-podge with Tomato and is primarily determined, not by the router, but by the client. They latch onto a particular router and have a death grip on it long after it makes any kind of reasonable sense to stay there. When I see this happening I usually flip the wireless interface off then on, the equivalent of a slap in the face to the NIC, which promptly roams to the strongest AP. "Real" multi-AP networks have a central controller, which see which clients are connected to which AP and forcibly disassociate clients from a particular AP when they get too far out of range, at which point they roam to the hottest AP and all is well with the world. Multi-APs with Tomato isn't that level of nice, but it can work well enough.
  23. thydzik

    thydzik Network Newbie Member

    Can you please provide additional configuration info.

    Everything I have read is about using the guest as br1, but like you have said you don't get all the QoS on br1.
    Is it just a mater of changing reference to br1 to br0 in the configuration?
  24. Monk E. Boy

    Monk E. Boy Network Guru Member

    You can only have one DHCP server per network segment since DHCP is broadcast across the entire segment. That DHCP server will determine what subnet its clients are on.

    If you wanted to set up a bunch of systems with fixed IPs and then have the DHCP systems in a different subnet that might be possible but it's highly unorthodox. In addition things like broadcasts can be shared between the two networks ( broadcasts will, subnet-specific x.x.x.255 broadcasts will not) because again the network segment determines what traffic gets shared. A simple MAC lookup, which happens constantly and silently when you're on a network, will leak information between systems on the same network segment, even if they're in different IP ranges.

    If you want systems isolated from one another you should put them in different networks. If you don't care if they're isolated then they can be on the same network. There really is no in-between those two points without ignoring a very, very leaky boat of data that is going to flow between systems.

    If you're going to have two IPs on the same interface you're going to have to do it from the command line, you can't use the website. I could do it from Linux but busybox is a whole other can of worms.
  25. Bird333

    Bird333 Network Guru Member

  26. Sean B.

    Sean B. LI Guru Member

    I'll assume you're referring to clients that are connected to the routers LAN ports: No, those rules will have no affect on client to client communications when the clients are connected to the same switch ( IE: the LAN ports of the router ) and the ports in use are within the same subnet/VLAN. When clients are connected to a switch, and the ports they're using are within the same subnet/VLAN, communications between them never leave the switch. So "indirect" communication doesn't exist in this context: client -> switch -> bridge ( router ) -> switch -> client, sense it would just end up being client -> switch -> client. As a result, the router ( CPU ) never see's these packets.. therefor no routing or bridge policy can control them.

    A context of which "indirect" communications would exist may be something such as client1 connects to client2 via the WAN IP + port forwards, or NAT loopback: client -> switch -> CPU -> WAN -> CPU -> switch -> client. However, in this instance it would be much more case fitting to use routing policy ( iptables ) rather than bridge ( ebtables ). Hopefully this gives you an idea of the concept.

    **NOTE** In the case of NAT loopback rather than port forwards, an accurate flow description would be client -> switch -> CPU -> switch -> client. With port forwards the packets would still traverse the WAN chains ( I believe ) whereas loopback would be DNAT/SNAT'd prior to them. If anyone finds I'm incorrect on these specific details, please correct me.
    Last edited: Jun 30, 2018
  27. Bird333

    Bird333 Network Guru Member

    No I was talking about wireless clients. Notice the rules reference a wireless interface.
  28. Sean B.

    Sean B. LI Guru Member

    My apologies, I skimmed over the exact rules you stated as having seen " client1 -> bridge -> client2 " I auto-piloted to LAN for some reason. However, my reply still applies. A bridge and switch are very similar in functionality ( plenty of good documents online for specifics ), which is an important fact to note. When interfaces are enslaved to a bridge, they no longer have an IP layer address of their own, this can be easily seen via ifconfig. The bridge itself is the "bridge" to the other layers and takes over having an IP address. This means all interfaces that are enslaved to a bridge are connected at the link layer, and just as with the LAN switch and routing, their communications between eachother do not "enter and exit" the bridge where ebtables could then enforce policy.

    Something to note in regards to this area of topic: The "AP Isolate" function which provides the ability to prevent client-to-client communications when said clients are connected to the same wireless AP is a feature coded by Broadcom into the wireless driver. It operates "above the law" so to speak and is not accomplished via networking principle. It manipulates the traffic on its own, as the wireless driver is the middleman between the hardware level and the firmware.
    Last edited: Jul 1, 2018
    Monk E. Boy likes this.
  29. eibgrad

    eibgrad Network Guru Member

    Yes, although Broadcom isn't alone when it comes to operating above the law.

  30. Monk E. Boy

    Monk E. Boy Network Guru Member

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice