1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Isolate wireless users from wired side of network?

Discussion in 'DD-WRT Firmware' started by danr, Nov 6, 2005.

  1. danr

    danr Network Guru Member

    Is there any way so that machines connected wirelessly, can access the Internet, but can NOT access other machines on the network (for security reasons)?

    I used to use a second router connected to the wireless router, for this purpose (double NAT)
     
  2. cgondo

    cgondo Network Guru Member

    have a look at AP isolation. I am not exactly sure what it does. I think it only isolate wireless users from other wireless users.

    Or you could probably try VLAN?
     
  3. Toxic

    Toxic Administrator Staff Member

    AP isolation afaik isolates wireless users from each other.


    tbh this would be done via IPtables i guess, thugh i dont know much about them.

    http://www.netfilter.org/ should help you. ddwrt uses iptables 1.3.3 afaik in v23 at present time.
     
  4. 4Access

    4Access Network Guru Member

    I'll try to find time tomorrow to get some instructions up...
     
  5. cgondo

    cgondo Network Guru Member

    using iptables means that he has to know the IP of the wireless adapters? It would then require him to DHCP the wireless users? and gave them a range of IP that you will use to define the rules?

    Quite a hassle. Isnt VLAN easier?
     
  6. robmack

    robmack Network Guru Member

  7. danr

    danr Network Guru Member

    Thanks alot for getting the ball rolling. Some followup.

    The question about seperating them by IP address, is that my goal is, that if someone breaks into the wireless side of the router, they can't get into the PCs on the wired side. I wont know the IP address of an intruder in the future, in order to make rules keep them seperate - unless there is some way of telling the router to use distinct IPs for wireless vs wired clients.

    (I've heard the by specifying MACs for the router to allow, isn't a foolproof way of disallowing other machines onto your network (besides WPA security etc).)

    Thanks again.
     
  8. robmack

    robmack Network Guru Member

    iptables, DHCP and FWBUILDER

    Since there are only four ports on the wired side of the network, you could associate those machines' IP addresses with their MAC addresses, giving them unlimited time-limit leases (or use fixed IP addresses). Managing access for four machines on your router is doable. As for the Wireless machines, they would get normal DHCP leases.

    Then, instead of working with the standard iptables config that comes with DD-WRT, use some utility like FWBUILDER to construct your own customized iptables. That way you have complete control over who does and does not get access.

    A totally different approach to the problem sould be to abandon DD-WRT and go with OpenWRT which will give you much more flexibility at a cost of increased complexity...it's a trade-off.
     
  9. 4Access

    4Access Network Guru Member

    No need to switch to OpenWRT, DD-WRT will work fine.

    While it is true that by default the LAN ports are bridged with the wireless interface, the solution is to simply remove the wireless interface from the bridge, assign it a seperate subnet and then configure some iptables rules.

    Trying to filter simply based on IP or MAC address is not very secure since both can be easily spoofed.

    I'm about to start writing up a mini-HowTo for these proceedures and plan to post it to the Separate LAN and WLAN page in the DD-WRT Wiki which has been blank for quite a while. I'll post an update here when I've got it up.
     
  10. danr

    danr Network Guru Member

    4ACCESS -
    Thanks alot! That sounds great!
     
  11. 4Access

    4Access Network Guru Member

    UPDATED: Nov. 21st, 2005

    OK sorry for the delay, I ran into a number of difficulties but think I finally got it worked out:

    Note that these instructions were written with the following priorities in mind:

    1) Security - There are ways to "seperate" the wireless clients from the wired clients without "breaking the bridge" by using just iptables but these methods can be bypassed by people who know what they are doing. With the steps I've layed out in this tutorial your wired LAN clients should be just as safe from the Wireless network as they are from the WAN.

    2) Simplicity - Don't let the size of this post discourage you! It may look overwhelming but the steps are quite easy! All configuration is done from the GUI so no command line knowledge required and it should only take a few minutes to complete all the steps!!

    3) Compatibility - These instructions support as many hardware versions & network configuration options as possible. I tested these instructions using DD-WRT v23 beta2 build 11/1/2005 but I believe it should work with the stable v22 as well. The hardware I used was a WRT54G v2 but it should work with all WRT54G models from v2 - v4 as well as all current WRT54GS models. (v1 - v4)

    Getting this to work with WRT54G v1.x hardware is also possible but may require more tweaking. My only v1.0 WRT54G is in use so I can't test it right now. If someone has a v1.x and wants to test it for me the feedback would be welcome. The worst that can happen is you'll loose all access to the router and will have to reset to defaults by holding the reset button for 30 sec. (It won't "brick" your router.)

    Additionally I wanted a solution that would survive reboots but didn't require that the writable jffs file system be enabled.


    You need to do this configuration from a PC that is connected to a Wired port on the router as the wireless connection will go down several times during the configuration.



    OK enough with all that, now on to the good stuff!

    1. Create nvram variables to hold customizable options for the new Wifi subnet you are about to create:

    1a) Go to the 'Administration -> Diagnostics' page and click the 'Run' button.

    1b) Paste the following commands into the text box ONE AT A TIME, pressing the 'Cmd' button after each one. Note that you can customzie the green portions. (See notes below)

    Notes:
    - Set wifi_ifname to "eth2" if you are using a WRT54G v1.x
    - If you don't want to enable DHCP for wireless clients then you can remove the three "wifi_dhcp" lines
    - The wifi_dhcp_lease_time option is in minutes (1440 = 24hrs)


    2. Remove Wireless interface from the LAN bridge (br0):

    2a) Go to the 'Setup -> VLANs' page.
    2b) At the bottom of the page change the "Wireless" option from "LAN" to "None". Save.


    3. Configure the wireless interface:

    3a) Start by configuring the Wireless settings (SSID, Channel, Security) from the GUI like you normally would.

    3b) If you do NOT want to run DHCP on the wireless subnet then you can skip this step: Go to the 'Administration -> Management' page and add the option: "bind-interfaces" to the DNS Masq - Additional DNS Options text box. (Do NOT include the quotes & make sure "bind-interfaces" is on it's own line.) Also remember to Save.

    3c) Go back to the 'Administration -> Diagnostics' page and click the 'Run' button again.

    3d) Paste the following command into the text box (all 3 lines need to be added at once) and then click the 'Save Startup' button:

    The red placeholder text in the 2nd line above needs to be replaced with one of the commands below depending on what type of wireless security you want to use. (Note that the commands below are a single line that have simply been wrapped because they are so long. When copying the command you need make sure you get the entire command copied in one step.)

    # For No security:
    Remove the placeholder line

    # For WEP:
    Remove the placeholder line

    # For WPA-PSK TKIP use the following command:
    Code:
    /usr/sbin/nas -P /tmp/nas.lan.pid -H 34954 -i $(nvram get wifi_ifname) -A -m 4 -k $(nvram get wl_wpa_psk) -s $(nvram get wl_ssid) -w 2 -g $(nvram get wl_wpa_gtk_rekey) &
    # For WPA-PSK AES use the following command:
    Code:
    /usr/sbin/nas -P /tmp/nas.lan.pid -H 34954 -i $(nvram get wifi_ifname) -A -m 4 -k $(nvram get wl_wpa_psk) -s $(nvram get wl_ssid) -w 4 -g $(nvram get wl_wpa_gtk_rekey) &
    # For WPA-PSK TKIP or AES use the following command:
    Code:
    /usr/sbin/nas -P /tmp/nas.lan.pid -H 34954 -i $(nvram get wifi_ifname) -A -m 4 -k $(nvram get wl_wpa_psk) -s $(nvram get wl_ssid) -w 6 -g $(nvram get wl_wpa_gtk_rekey) &
    # For WPA2-PSK TKIP use the following command:
    Code:
    /usr/sbin/nas -P /tmp/nas.lan.pid -H 34954 -i $(nvram get wifi_ifname) -A -m 128 -k $(nvram get wl_wpa_psk) -s $(nvram get wl_ssid) -w 2 -g $(nvram get wl_wpa_gtk_rekey) &
    # For WPA2-PSK AES use the following command:
    Code:
    /usr/sbin/nas -P /tmp/nas.lan.pid -H 34954 -i $(nvram get wifi_ifname) -A -m 128 -k $(nvram get wl_wpa_psk) -s $(nvram get wl_ssid) -w 4 -g $(nvram get wl_wpa_gtk_rekey) &
    # For WPA2-PSK TKIP or AES use the following command:
    Code:
    /usr/sbin/nas -P /tmp/nas.lan.pid -H 34954 -i $(nvram get wifi_ifname) -A -m 128 -k $(nvram get wl_wpa_psk) -s $(nvram get wl_ssid) -w 6 -g $(nvram get wl_wpa_gtk_rekey) &
    # For WPA-PSK or WPA2-PSK TKIP use the following command:
    Code:
    /usr/sbin/nas -P /tmp/nas.lan.pid -H 34954 -i $(nvram get wifi_ifname) -A -m 132 -k $(nvram get wl_wpa_psk) -s $(nvram get wl_ssid) -w 2 -g $(nvram get wl_wpa_gtk_rekey) &
    # For WPA-PSK or WPA2-PSK AES use the following command:
    Code:
    /usr/sbin/nas -P /tmp/nas.lan.pid -H 34954 -i $(nvram get wifi_ifname) -A -m 132 -k $(nvram get wl_wpa_psk) -s $(nvram get wl_ssid) -w 4 -g $(nvram get wl_wpa_gtk_rekey) &
    # For WPA-PSK or WPA2-PSK TKIP or AES use the following command:
    Code:
    /usr/sbin/nas -P /tmp/nas.lan.pid -H 34954 -i $(nvram get wifi_ifname) -A -m 132 -k $(nvram get wl_wpa_psk) -s $(nvram get wl_ssid) -w 6 -g $(nvram get wl_wpa_gtk_rekey) &

    Make sure you pressed the 'Save Startup' button instead of the 'Cmd' button for step 3d above.


    4. Configure the necessary iptables rules:

    4a) Paste the following commands into the same text box used above (all of the lines need to be entered at once) but this time press the 'Save Firewall' button:

    Code:
    iptables -I INPUT $(expr $(iptables -L INPUT|wc -l) - 2) -i $(nvram get wifi_ifname) -p icmp -j logaccept
    iptables -I INPUT $(expr $(iptables -L INPUT|wc -l) - 2) -i $(nvram get wifi_ifname) -p udp --dport 67:68 --sport 67:68 -j logaccept
    iptables -I INPUT $(expr $(iptables -L INPUT|wc -l) - 2) -i $(nvram get wifi_ifname) -p udp --dport 53 -j logaccept
    iptables -I FORWARD $(expr $(iptables -L FORWARD|wc -l) - 2) -i $(nvram get wifi_ifname) -m state --state NEW -j ACCEPT
    iptables -t nat -I PREROUTING -i $(nvram get wifi_ifname) -d $(nvram get lan_ipaddr)/$(nvram get lan_netmask) -j DROP
    iptables -t nat -I PREROUTING -i br0 -d $(nvram get wifi_ipaddr)/$(nvram get wifi_netmask) -j DROP
    dnsmasq -z -i $(nvram get wifi_ifname) -I lo -F $(nvram get wifi_dhcp_start),$(nvram get wifi_dhcp_end),$(nvram get wifi_dhcp_lease_time)m -l /tmp/dnsmasq.wifi.leases
    Notes:
    - If you don't want to run DHCP on the wireless subnet remove the "dnsmasq" line. (It's the last command but has probably wrapped onto more than one line.)


    5. Reboot, give it a minute to initilize, enjoy!



    Breakdown of the iptables rules:

    The rule below allows wireless clients to ping the router.
    Code:
    iptables -I INPUT $(expr $(iptables -L INPUT|wc -l) - 2) -i $(nvram get wifi_ifname) -p icmp -j logaccept
    The rule below allows wireless clients to contact the router on UDP port 67 & 68 so they can lease an IP address.
    Code:
    iptables -I INPUT $(expr $(iptables -L INPUT|wc -l) - 2) -i $(nvram get wifi_ifname) -p udp --dport 67:68 --sport 67:68 -j logaccept
    The rule below allows wireless clients to contact the to router on port 53 for DNS.
    Code:
    iptables -I INPUT $(expr $(iptables -L INPUT|wc -l) - 2) -i $(nvram get wifi_ifname) -p udp --dport 53 -j logaccept
    The rule below allows wireless clients to access the internet. No filtering is done. They can use all ports & all protcols.
    Code:
    iptables -I FORWARD $(expr $(iptables -L FORWARD|wc -l) - 2) -i $(nvram get wifi_ifname) -m state --state NEW -j ACCEPT
    The rule below explicity blocks all traffic from the wireless subnet to the wired LAN subnet.
    Code:
    iptables -t nat -I PREROUTING -i $(nvram get wifi_ifname) -d $(nvram get lan_ipaddr)/$(nvram get lan_netmask) -j DROP
    And this rule blocks all traffic from the wired LAN subnet to the wireless subnet.
    Code:
    iptables -t nat -I PREROUTING -i br0 -d $(nvram get wifi_ipaddr)/$(nvram get wifi_netmask) -j DROP
    This last command isn't actually a firewall rule. It's what starts the DHCP server for wireless clients. For some reason it wouldn't run for more than a few seconds if I put it in the Startup Script...
    Code:
    dnsmasq -z -i $(nvram get wifi_ifname) -I lo -F $(nvram get wifi_dhcp_start),$(nvram get wifi_dhcp_end),$(nvram get wifi_dhcp_lease_time)m -l /tmp/dnsmasq.wifi.leases
    The above iptables rules are overly complex for a couple of reasons:

    1. I wanted to keep the organization of the rules as close to the DD-WRT default configuration as possible. This required some fancy footwork to get our rules inserted in the proper place.

    2. I wanted the rules to work regardless of what subnets you are using for the wireless network & your LAN ports.

    Another thing to note is that thanks to the changes BrainSlayer made in recent builds of v23 port forwarding to wireless clients should work without requiring any manual modifications to the iptables rules! (Although I haven't tested this and quite honestly I'm not sure why you'd want to forward ports to the WLAN in a configuration like this...) Port forwarding to the wireless subnet will NOT work with v22 without manually creating the necessary iptables rules.

    A few other things to note about the firewall rules
    1. Logging won't work properly for traffic going to/from the wireless subnet.

    2. QoS probably won't work either for wireless clients.

    3. Wireless clients cannot configure the router. This was done purposefully but it is very easy to add the necessary iptables rules if wireless clients neet to administer the router.



    To Do:
    1. Try and figure out why the nvram commands in step 1b) have the be entered one at a time. (If you enter them all at once apparently they don't get saved properly which results in "dhcp-range" errors from dnsmasq. You also get funny results from commands like: 'echo -n $(nvram get wifi_dhcp_start)'

    Status: I'm at a loss on this one... maybe a bug?

    2. Automate the detection of wireless security options so the user doesn't have to manually select the correct command for WPA.

    Status: I'm sure this can be done but my linux scripting skills aren't quite up to the task right now and I don't have the time to research it. (Remembering that we're looking for a solution that does not require the writable jffs file system be enabled.)

    3. Logging for the wireless subnet - test to determine how badly it has been broken by our changes & then try to fix.

    Status: Shouldn't be all that hard. I'd consider looking into this over the next weekend or two when I have some time if people are interested.

    3. Test QoS to confirm it's not working for wireless clients & then try to find a fix.

    Status: I have a feeling that this would require a lot more work than the logging and I'm not as framiliar with configuring QoS from the command line so this one will probably need someone else's input.


    Well that about does it for now. Enjoy, and please give feedback on whether this works for you. I'll try to get the Wiki updated after I've got some confirmation here that this works for most people. :thumb:


    [marq=left:45cdd7f6fe]Oh and this is way off topic but I just discovered this forum supports Marque text!!!! ................ It even supports smilies!!! --------> :D :grin:[/marq:45cdd7f6fe]
     
  12. itsmeohmy

    itsmeohmy Network Guru Member

    Hmm...

    Couldn't you just remove the wLAN interface (eth2) from the bridge and then do a:

    Code:
    ebtables -A FORWARD eth2 -j DROP
    wouldn't that be a hell of a lot easier?

    One could probably even add a few wired ports to a vlan (say vlan2)and then bridge that into a new bridge say br1:


    Code:
    brctl add br1
    brctl addif br1 eth2 
    brctl addif br1 vlan2
    ebtables -A FORWARD br1 -j DROP
    You could even use DNSMasq to provide DHCP services for the multiple Lans (Vlans) http://wiki.openwrt.org/OpenWrtDocs/dnsmasq
     
  13. danr

    danr Network Guru Member

    Thanks to both (all) of you.

    I've been waiting a bit for V23 to stabilize, so I haven't tried these out yet.

    It seems that while 4ACCESS's directions seem to be very comprehensive, the inability to use DNS Masq is an issue... especially since that is what Brainslayer is moving TOWARDS -- and is less buggy than the old DHCPd, which it seems will go away.

    As for itsmeohmy's comments- I am not yet knowledgable enough to fill in all of the blanks here.

    "just remove the wLAN interface (eth2) from the bridge"

    That is, do steps 1 and 2 from 4ACCESS's posting?

    I'm not sure I understand why we'd do one of these
    vs the other (since my goal is to have the WLAN isolated, I would think I just want the top... right?):

    ebtables -A FORWARD eth2 -j DROP

    vs

    brctl add br1
    brctl addif br1 eth2
    brctl addif br1 vlan2
    ebtables -A FORWARD br1 -j DROP


    RE: DNSMASQ - you were referring
    to implementing the directions at section:
    "1.1.4. Configuring dnsmasq to use different IP ranges for wired and wireless" ?


    So, to summarize:

    Do I just do steps 1 & 2 from 4ACCESS's info, then
    ebtables -A FORWARD eth2 -j DROP
    then follow section 1.1.4 from the DNSMASQ section of the DD-WRT WIKI?

    After doing this, how can I then see the configuration/status of the WLAN vs the Wired LAN?

    If I get messed up, is the best thing to do, a factory reset or do I need to reflash?

    Anything special I should test out? Just make sure that I get IP addresses from the right VLAN range for each device type?

    Thanks alot!
     
  14. knight14th

    knight14th Network Guru Member

  15. danr

    danr Network Guru Member

    As a follow up. 4Access updated the WIKI with his posting above and points the FAQ to this thread. He then notes:

    "Note that new developments have been discovered that have not yet been posted to that thread or below... I hope to find time to update things Nov 19th, 2005"
     
  16. 4Access

    4Access Network Guru Member

    Ok, sorry I'm a little late. I'm working on this now and should have something up in a few hours.
     
  17. danr

    danr Network Guru Member

    Thanks alot! No need to apologize - I very well wont get a chance to try it in the next few days anyhow.
     
  18. 4Access

    4Access Network Guru Member

    OK so another status update: I ran into a whole bunch of issues but I think I finally got everything worked out. Have put almost 8hrs into this between yesterday & today... Am about to reset to defaults and follow the instructions I've written up step-by-step and as long as it works one more time I'll post the instructions.

    Improvements:
    1. DHCP issue resolved
    2. WPA/WPA2 didn't work with the steps I posted previously - Does now.
    3. Firewall rules tightened up a bit. (The router is arguably "more secure" from the Wireless clients than with my last set of instructions)

    If you don't see an update shortly that means I found another problem and will have to keep working on this tomorrow.
     
  19. 4Access

    4Access Network Guru Member

    Done! :D

    I've updated my post above so please take another look and let me know if it works for you.

    As soon as we're sure it's working for most people I'll update the Wiki & then I want to work on writing up another HowTo for Creating a span/mirror port so all traffic that crosses the WAN port can be easily sniffed.

    :thumb:
     
  20. danr

    danr Network Guru Member

    I finally got a chance to test out the Wireless/Wired seperation.
    So far, so good! Cool!

    "My current" QoS concern is, that my wired network VOIP telephone gets priority - even with wireless network PCs using bandwidth. I use MAC based QoS.

    Currently, my wireless clients are all PocketPCs -- and for some reason, they always use less bandwidth than PCs, even using a speedtest - so I can't directly compare QoS on PC versus PocketPC.

    I did a speakeasy.net/speedtest from PocketInternetExplorer. From what I see, this set up seems to do "THIS TYPE OF" QoS properly. I do NOT get any dropouts. My upload on my pocketpc speakeasy.net/speedtest IS MUCH lower when I'm on the phone, than when I'm not.

    I see both networks on cat /proc/net/ip_conntrack and the proper MAC address' IP address gets the mark=10 and the other ones from both networks get mark=0. (I guess with MAC QoS, it's not surprising.)

    Hopefully, someone with another "type" of QoS setup can do some more extensive testing.


    Is there anything else I should test?

    Are there any UI settings I now have to stay away from?

    Will the router backup/restore, properly restore these settings?
    (of course, not across router firmware revisions).

    I gather, if I temporarily want the networks to see each other, I change the firewall rule?

    FYI - I'm using WRT54G version 4, with the November 24 version 23 beta firmware.


    Thanks alot!
     
  21. 4Access

    4Access Network Guru Member

    Good, I'm glad to hear it! Thanks for reporting back!

    That makes it sounds like MAC based QoS may still work properly. Great!


    Not that I can think of, just report if you run into any unexpected problems.

    The only ones you should be careful with are the ones you used during the configuration process.

    Great question! I haven't tested it but unfortunately I don't expect it to. Step 1b is going to be the problem since the backup/restore does not save custom nvram variables. (At least not with the current backup system in the v23 beta2 builds.) Everything else should get saved/restored properly though so you should only have to repeate step 1b afte a restore. (Actually it would probably be better to do step 1b and then restore.)

    Yup. To temporarily allow communication between the Wireless & LAN subnets enter the following two commands into Administration -> Diagnostic -> Run, pressing the 'Cmd' button after each:

    iptables -t nat -D PREROUTING -i $(nvram get wifi_ifname) -d $(nvram get lan_ipaddr)/$(nvram get lan_netmask) -j DROP

    iptables -t nat -D PREROUTING -i br0 -d $(nvram get wifi_ipaddr)/$(nvram get wifi_netmask) -j DROP

    This will only last until the router reboots, which is also the way to undo these changes. :thumb:
     
  22. EBAL

    EBAL Network Guru Member

    Thanks for a great article. What is the "latest version" of this implementation - the article on the Wiki dated Nov. 21, or the much more detailed post of 4Access on this thread? Sorry I am kinda confused by the 2 versions as they seem different in some areas.
     
  23. danr

    danr Network Guru Member

    Take a look earlier in this thread, at the post by:
    4ACCESS
    Posted: 2005-11-07, 08:30:46

    4ACCESS updated the original posting in-place. So, even though the original posting was made before the messages after it in the thread, it is now newer than alot of messages located later in the thread.
     
  24. 4Access

    4Access Network Guru Member

    Direct Link to the most recent version so far.

    I'll get the wiki updated soon, I promise.
     
  25. danr

    danr Network Guru Member

    Just to confirm, do all of the changes survive a power failure?
    I see much of it is done in NVRAM - but just want to be sure I'm ok.

    After a power reset, I still do seem to be getting the proper IP addresses served, for wired/wireless clients. So, things do seem ok.

    This question came up, as I accidentally killed dnsmasq. I was trying to send it a signal to dump it's cache... somehow I never typed the dash before the signal I wanted, so it killed the PID :)

    I tried a GUI based reboot and it didn't restart dnsmasq. So I pulled the plug and re-plugged.

    I still wasn't able to get a dump of the cache to the system log...
    I was sending signal SIGUSR1, which the dnsmasq webpage says is appropriate.
     
  26. EBAL

    EBAL Network Guru Member

    Thanks for your replies. What build of V23 works best with the above configs - Beta1 or Beta2? Also what build date?
     
  27. appuser99

    appuser99 Network Guru Member

    Wireless didnt work...

    Hi :)

    I'm using linksys wrt54gs v1.1. DD-WRT v23.

    I followed the config on this post (by 4Access) but the wireless just didn't work. Unable to get dynamic ip address from the wireless. Even if setting static ip also did not work.

    I tried 4 times, I did reset , reinstalling firmware, factory defaults, etc etc to clear the config and re-enter the config, but it just did not work.

    I have no problem with wired lan , I'm able to get dynamic ip and able to surf the internet.

    Help needed, please post comments :)

    Thank you.
     
  28. 4Access

    4Access Network Guru Member

    Resetting to factory defaults from the web GUI will not clear custom nvram variables so I suggest holding the reset button for 30 sec to clear everything and then starting over.

    Also if you are having problem I'd start with no wireless security.


    Yes all changes survive a reboot/power failure.
     
  29. danr

    danr Network Guru Member

    Re: Wireless didnt work...

    I probably should've posted this before, with my results.
    Quite honestly, I tested the WIFI using 2 pocketpcs.

    My Dell Axim X30 (WM2003SE) worked flawlessly built in WIFI and OS based connectivity..

    The other one, an Audiovox Maestro, with a 3rd party WIFI card and third party WIFI software initially, wasn't able to get an IP address. I then put the 10.0.0.1 as the default gateway and it was able to get an IP address just fine. I was then able to take out the manually set default gateway and from then on, it was able to get the IP address fine. For some reason, since it previously had 192.168.0.1 as the gateway, it seems it was still expecting to use that as the gateway. Maybe your issue is similar to this?

    The other issue is that DNSMasq is very slow in giving out IP addresses (if you're using it for DHCP). As per other forum posts, some people have devices which actually time out before they get IP addresses. Hopefully this will be addressed - but this has nothing to do with the instructions 4ACCESS posted.
     
  30. EBAL

    EBAL Network Guru Member

    Reposting my question - what build of V23 are you guys running to separate the LAN from WLAN?

    I just got a new unopened V4 and don't want to brick it so soon by loading the more recent builds that have caused others problems.

    What is the latest stable V23 build for separating LAN from WLAN, pls?

    Thanks!
     
  31. danr

    danr Network Guru Member

    I'm using the November 24th build on a V4. That's not to say that a more modern build wont work.
     
  32. appuser99

    appuser99 Network Guru Member

    I'm using dd-wrt.v23.std_beta2.zip.
    I'll try the suggestion by danr.

    Thank you
     
  33. danr

    danr Network Guru Member

    I'm now running it with the released v23 and it seems to work fine.
    EBAL - What have your experiences been? I don't see any followup.
     
  34. 4Access

    4Access Network Guru Member

    While I haven't tested it, there were no changes in the v23 final version (12/25/05) that should cause any problems. Everything should still work fine.
     
  35. EBAL

    EBAL Network Guru Member

    Danr, sorry I still haven't gotten around to install DD-WRT on my V4 - holidays keeping me busy. I will try the V23 final and post my experience.

    Maybe since V23 is final, the Wiki can be updated.
     
  36. EBAL

    EBAL Network Guru Member

    OK, I tried the "by-pass the bridge" method posted by 4Access. I couldn't get the wireless clients to connect although the wireless clients can see the router. I also discovered that I cannot disable wireless via the web GUI.

    As I don't have the time nor experience to tinker further, can someone guide me how to do the simpler "iptables method" mentioned in the Wiki. I understand it may be less secure but I need the web GUI to disabled wireless 90% of time time. I only enable wireless when I have guests in the house.

    The iptables method is summarized in the Wiki as:

    Enable a static route for 192.168.1.x to vlan0
    Enable a static route for 192.168.2.x to eth1
    Enable DHCP for 192.168.1.x for vlan0
    Enable DHCP for 192.168.2.x for eth1

    Anyone have a generic script to accomplish this? Thanks!
     
  37. danr

    danr Network Guru Member

    [You can ignore this posting and see what I replied later on... the second reply that I made]

    Well, my Pocket PCs fine with this setgup. I just tried with a Windows 98 machine on a borrowed WIFI card (No Zero Configution Wizard - I'm using Realtek's applet) and it was unable to get an IP address. If I specified the IP address on the machine directly I was fine. I then removed the static IP, it was a problem again.

    I then put a static DHCP lease for this PC in the router, the machine was able to access the network again. Once I did that, I was able to unset the static DHCP lease and connect fine thereafter... But, I have a feeling that it's the WIFI adaptor software which is caching it, as it shows an IP address prior to getting any association. (On the other hand, once I remove the static IP address from the PC, I was not able to get an IP)

    After all the fiddling, I wanted to get my pocket pc set up again (since I fiddled with it, as well) and it couldn't get an IP address. At that point, I noticed that the dnsmasq instance dealing with the 10.0.0.x network came down. I do KNOW that it was up during the initial attempts at connecting the PC -- but I have no idea what brought it down... For some reason, even rebooting the router doesn't bring it back... but I think that I may have accidentally erased nvram instead of viewing it... :-(

    Anyhow, I don't have more time to fiddle now... But, it does seem that there's just something not 100% in the way that DYNAMIC DHCP IP addresses are handed out to the wireless network (10.0.0.x). There already have been two other people who have been unable to get an IP on their PCs.

    4ACCESS Any ideas?
     
  38. EBAL

    EBAL Network Guru Member

    I was searching through the archives and found this thread

    http://www.linksysinfo.org/modules....wtopic&t=4565&highlight=seperate+wireless+lan

    the last post in the thread mentioned a single iptable rule

    iptables -P INPUT -i eth0 -o eth1 -j DROP

    is this enough to block the WLAN from connecting to LAN?

    Different subnets for WLAN and LAN are not critical to me as long as the WLAN clients cannot connect to the LAN clients.
     
  39. danr

    danr Network Guru Member


    I tried things from scratch and thought I proved that it was just the Realtek drivers.... but then I realized that I needed to rename the SSID, so that I'd be testing the right profile. I'm not doing that test tonight... and I may have to relinquish the WIFI card before I can check :-(


    The issue I did see with the RealTek driver, is that when I updated the network IP range, the PC associated with the router, but had the old IP address / gateway. I did an ipconfig /release_all ipconfig /renew_all (it's a Win98SE machine) - it then picked up the right IP address but it couldn't access the network. I rebooted and it accessed the network/Internet.

    So, it's using a cached value instead of trying to get a new IP address whenever it associates. When I did the test, I did it with the default SSID and then when I did 4ACCESS' procedures, I renamed the SSID, so that the RealTek card would be using the old profile, which still had the other IP address cached... So, the new test was faulty...
     
  40. danr

    danr Network Guru Member

    I just removed the configuration totally and did the same song and dance the Realtek utility normally requires (releasing / renewing / rebooting) and it works fine with 4ACCESS' procedures!

    I see that Realtek itself has newer drivers and a newer utility... maybe that will help.

    Again, I don't have a PC with Windows XP with a compatible WIFI card to be able test the reaction of Zero Config to such a network setup.
     
  41. EBAL

    EBAL Network Guru Member

    Reading through the archives of the OpenWRT forum, a simple solution that was mentioned a few times to secure LAN from WLAN is:

    iptables -I FORWARD -i eth1 -o vlan0 -j DROP
    iptables -I FORWARD -i vlan0 -o eth1 -j DROP

    I tried this on DD-WRT V23 Final. It doesn't give any error messages but it doesn't seem to have any effect either. Any ideas why?
     
  42. danr

    danr Network Guru Member

    2nd DnsMasq exiting

    4ACCESS:

    Once again, the DnsMasq which is manually kicked off by your procedures died. Yesterday, I was doing hours 1 second pings against the wireless gateway (10.0.0.1)... After a few hours, it seemed to lose the connection. But, I was able to tell it to reconnect without a problem (it wouldn't automatically reconnect).

    This morning, I wanted to reconnect and the wireless devices couldn't get an IP address (wired is ok). I do a 'ps' on the router and I only see the 'official' dnsmasq running and not the one we kicked off.

    The problem I first saw was when I was using v23 final. This time it was after I updated to the Jan 16 beta of SP1.


    If you remember correctly, you had to put the dnsmasq in with the firewall rules instead of the startup... I wonder if that has some unintended drawback?


    I started dnsmasq manually and it's giving out IPs to the wireless network again.
     
  43. danr

    danr Network Guru Member

    The second DnsMasq died again... What type of logging can I turn on to get more debugging information?

    Thanks
     
  44. iphostway

    iphostway Guest

    Is there a way I can make this work.

    I need the wireless 10.0.0.x to get to the lan network 192.168.2.x on port 21 on the LAN .. 4access setup is working great. I like to let the wireless have access to port 21 .. I tryed this but it did not work can you please check to see what I did . also I like port 80 same thing from wlan to lan.

    I only added the 1st line. 192.168.2.1 is the LAN IP. " iptables -t nat -A PREROUTING -i eth1 -m tcp -p tcp -d "

    Code: ‹ Select › ‹ Expand ›
    iptables -t nat -A PREROUTING -i eth1 -m tcp -p tcp -d 192.168.2.0/24 --dport 21 -j ACCEPT
    iptables -I INPUT $(expr $(iptables -L INPUT|wc -l) - 2) -i $(nvram get wifi_ifname) -p icmp -j logaccept
    iptables -I INPUT $(expr $(iptables -L INPUT|wc -l) - 2) -i $(nvram get wifi_ifname) -p udp --dport 67:68 --sport 67:68 -j logaccept
    iptables -I INPUT $(expr $(iptables -L INPUT|wc -l) - 2) -i $(nvram get wifi_ifname) -p udp --dport 53 -j logaccept
    iptables -I FORWARD $(expr $(iptables -L FORWARD|wc -l) - 2) -i $(nvram get wifi_ifname) -m state --state NEW -j ACCEPT
    iptables -t nat -I PREROUTING -i $(nvram get wifi_ifname) -d $(nvram get lan_ipaddr)/$(nvram get lan_netmask) -j DROP
    iptables -t nat -I PREROUTING -i br0 -d $(nvram get wifi_ipaddr)/$(nvram get wifi_netmask) -j DROP
    dnsmasq -z -i $(nvram get wifi_ifname) -I lo -F $(nvram get wifi_dhcp_start),$(nvram get wifi_dhcp_end),$(nvram get wifi_dhcp_lease_time)m -l /tmp/dnsmasq.wifi.leases




    Thanks Iphostway
     
  45. ints

    ints Guest

    I used Wiki instructions at http://wrt-wiki.bsr-clan.de/index.php?title=Separate_LAN_and_WLAN, but dont succeeded... :-(

    >Set wifi_ifname to "eth2" if you are using a WRT54G v1.x

    1. Is "eth2" also a right way for WRT54GS v1.1 ? How can i check it out?

    2. How can I check configuration files content via command interface? What are the names/locations for files with startup and firewall rules?

    3. I need also wireless client access for ports 80 and 25 inside wired network (web/smtp server is there). What rules should I apply additionally?

    Best Regards,
    Indrek
     
  46. danr

    danr Network Guru Member

    I just tried the steps with v23 SP1 RC2 on a WR850Gv2.
    The clients do get proper dynamic DHCP IP addresses, but if I put a static DHCP IP address, they don't get properly set.

    DNSMASQ is up and the dnsmasq.conf shows the 10.0.0.100 static lease

    tmp/var/log # ps -aef | grep masq
    519 root 604 S dnsmasq --conf-file /tmp/dnsmasq.conf
    682 root 592 S dnsmasq -z -i eth1 -I lo -F 10.0.0.100,10.0.0.200,144

    I do see the following in the syslog:

    00:10 DD-WRT daemon.info dnsmasq[119]: reading /tmp/resolv.dnsmasq
    00:18 DD-WRT user.crit syslog: unknown interface eth1
    00:18 DD-WRT user.crit syslog: FAILED to start up
    ...
    May 10 22:45:35 user.crit syslog: failed to bind listening socket for 10.0.0.1:
    May 10 22:45:35 user.crit syslog: FAILED to start up

    Looking here, it does seem that I should have eth1 as the WIFI Lan network... (if I'm not mistaken, v2 and v3 are the same chips other than the memory chips and the attached antenna)

    http://wiki.openwrt.org/OpenWrtDocs/Configuration

    I could try eth2, but I don't have the time right now.
     
  47. danr

    danr Network Guru Member

    On the other hand, I do see DHCP transactions on eth1
    when I turn on the wireless clients (I purposely cut off the right side of the log output)

    info dnsmasq[682]: DHCPREQUEST(eth1) 10.0.0.193
    info dnsmasq[682]: DHCPACK(eth1) 10.0.0.193 00:
    info dnsmasq[682]: DHCPREQUEST(eth1) 10.0.0.152
    info dnsmasq[682]: DHCPACK(eth1) 10.0.0.152 00:

    So, what are those errors telling me? Again, STATIC DHCP is not working when I put it in the standard UI window for doing so.

    I do see the following before the eth1 errors, so eth1 does seem right for the WR850G v2 as well. Again, the only problem I see now is that the static lease isn't working for the WLAN.

    Jan 1 00:00:09 DD-WRT user.emerg kernel: eth1: Broadcom BCM4320 802.11 Wireless
    ding WRT user.emerg kernel: Probing device eth0: No Robo switch in
    Jan 1 00:00:09 DD-WRT user.emerg kernel: Probing device eth1: [switch-robo.c:90
    Jan 1 00:00:09 DD-WRT user.emerg kernel: [switch-robo.c:90] SIOCGETCPHYRD faile
    Jan 1 00:00:09 DD-WRT user.emerg kernel: No Robo switch in managed mode found
    Jan 1 00:00:09 DD-WRT user.emerg kernel: Probing device eth2: No such device
    Jan 1 00:00:09 DD-WRT user.emerg kernel: Probing device eth3: No such device

    Thanks
     
  48. BigDog_UMG

    BigDog_UMG Network Guru Member

    I have had better luck running only one instance of DNSMasq. I just add the following to the GUI:

    Administration -> Management
    DNS Masq
    Additional DNS Options:

    listen-address=10.0.0.1
    dhcp-range=10.0.0.100,10.0.0.149,1440m

    Runs much smoother.
     
  49. danr

    danr Network Guru Member

    I kept the setup as was previously mention by 4ACCESS, removed the dnsmasq line from the firewall (really should be startup, but there was a bug) and entered what you said, yet maintained the "bind-interfaces" line as well. Then I rebooted the router.

    The one dnsmasq was able to serve both VLANs and was able to properly give out the static DHCP IP address (after I made sure that the clients weren't using cached IP addresses).

    I do get this error, right after "vlan0 entered promiscuous mode", but quite a bit prior to the dnsmasq loading - I don' t know what failed to start up, so I don't know if there are any issues.

    Jan 1 00:00:10 DD-WRT user.crit syslog: no interface with address
    10.0.0.1
    Jan 1 00:00:10 DD-WRT user.crit syslog: FAILED to start up


     
  50. BigDog_UMG

    BigDog_UMG Network Guru Member

    I checked my log and don't get any errors. If you haven't already, try rebooting with syslogd enabled, but not forwarded to any ip address. Then do a 'cat /var/log/messages' to see the log.

    If the interface eventually works, it sounds like a timing issue.

    When do you bring up the wireless interface? I do the following in rc_startup, not rc_firewall:

    ifconfig eth1 10.0.0.1 netmask 255.255.255.0
    wlconf eth1 up

    The only other dnsmasq command I enter is 'dhcp-authoritative'. I don't see how this command would solve the problem.

    Here is everything I do:

    Mod to create seperate sub-nets for LAN ports and wireless
    users and block traffic between the sub-nets.

    ** remove the wireless interface from the LAN bridge **
    On VLAN tab Change "Wireless" option fron "LAN" to "None"

    ** set DNSMasq additional options **
    dhcp-authoritative
    listen-address=10.0.0.1
    dhcp-range=10.0.0.100,10.0.0.149,1440m

    ** set nvram variable 'rc_startup' to the following: **
    ifconfig eth1 10.0.0.1 netmask 255.255.255.0
    wlconf eth1 up

    ** set nvram variable 'rc_firewall' to the following: **
    iptables -I INPUT 9 -i eth1 -p udp --dport 67:68 --sport 67:68 -j logaccept
    iptables -I INPUT 9 -i eth1 -p udp --dport 53 -j logaccept
    iptables -I FORWARD 11 -i eth1 -o vlan1 -m state --state NEW -j logaccept
     
  51. yodahome

    yodahome Guest

    Hi!

    I tried to modify your suggestion to accomplish the following scenario:

    eth1 and vlan2 are still bridged to br0 (vlan2 consists of the only wired port 4 - vlan2ports=4 5) and the remaining wired ports are vlan0. vlan0 is the internal lan and its ip is 192.168.5.1 while br0 is 192.168.3.1. dnsmasq only works for br0 which is ok since the internal lan is served with dhcp by another machine. However both subnets should be able to access the internet but NOT each other.
    Because br0 is more or less untouched everything works fine with ports 4 and wifi configured through the web interface.

    vlan0 is the problem because I can enter the router through 192.168.5.1 butI cannot reach 192.168.1.46 which is the wan if and any machine behind it (which simulate the internet). It's started like this:
    rc_startup (webif):

    Code:
    ifconfig vlan0 192.168.5.1 netmask 255.255.255.0
    wlconf vlan0 up
    
    rc_firewall (webif):

    Code:
    iptables -I INPUT 9 -i vlan0 -p all -j logaccept
    iptables -I FORWARD 11 -i vlan0 -m state --state NEW -j logaccept
    iptables -I FORWARD -i br0 -o vlan0 -j DROP
    
    I don't see the problem, so can you probably point me where I went wrong?

    Thx
     
  52. 86atc250r

    86atc250r Guest

    I got this setup to work as described by 4access - BTW, thanks for taking the time to type that great tutorial.

    Has anyone got this config to work with WDS? My WDS link comes up, but I can not seem to pass traffic over it.
     
  53. danr

    danr Network Guru Member

    Thanks alot.

    Your IPTABLES rules don't have icmp (thus pings wont work - if that's important to anyone reading this thread). The other thing I noticed, is that 4ACCESS has are EXPLICIT firewall rules to block cross network traffic other than those which we pass through.

    Would your rules require manual NAS setup to work for non-WEP security? (At the moment, I dont have a way to test it with a proper wireless client).

    Thanks
     
  54. BigDog_UMG

    BigDog_UMG Network Guru Member

    The type of wireless security you are using (WEP, WPA, etc) should not matter. iptables work on the interfaces. Nothing more needs to be done.
     
  55. rjt69

    rjt69 LI Guru Member

    4Access,

    I enjoyed "Separate LAN and WLAN", so thanks for the info.
    Do you have any plans to update your wiki anytime soon?
    Especially since DD-WRT v24 is just about out.
     
  56. wrt54gsnotfan

    wrt54gsnotfan Network Guru Member

    Hello,

    great job about this tutorial except it doesn't work for DHCP with v.23 sp1 on a WRT54GL and this is really a pity
    after having conciously followed your step on the dd-wrt wiki the result of the dhcp command
    Code:
    dnsmasq -z eth1 -F 10.0.0.100,10.0.0.200 -l /tmp/dnsmasq.wifi.leases
    is:
    Code:
    dnsmask: failed to bind listening socket for 192.168.100.254: Address already in use
    (192.168.100.254 is the router ip) this occurs before or after reboot.

    so your configuration works only if the wireless clients have statics ip, but they wont be able to have dhcp ip.
    please is that anyway to correct this?

    further more in the wiki you first wrote:
    a) Go to the 'Administration -> Diagnostics' page and click the 'Run' button. b) Paste the following command into the text box:

    I really don't understand the click the 'Run' button for the simple reason there is nothing to be run in the text box when you enter the administration->diagnostic page! There is therefore a popping alert box to inform you to type some command before clicking this button.
    So what is the background of you step a) ?
     
  57. kripper

    kripper LI Guru Member

    Use ebtables

    Hi:

    • By default, IPTABLES doesn't filter packets routed over a BRIDGE.
    • There is a kernel patch for doing this, but DD-WRT is not using it.
    • DD-WRT 24 provides EBTABLES for this.
    • Read my other post on this thread with an easy solution.
     
  58. kripper

    kripper LI Guru Member

    Simple Isolating with ebtables

    Hi people:

    I wanted to isolate WLAN from VLAN on a WRT54GL (ie. share my internet connection via WIFI and restrict those users to access my VLAN).

    Besides, I added two Virtual Wireless Interfaces, one with WPA2 and the other one unprotected...simplemente amo este pueblo y a mis vecinos de Quilpué.

    So I configured two virtual interfaces:

    Code:
    wl0.1 = (WPA2)
    wl0.2 = (unprotected) <--- With NO access to my VLAN
    
    I installed DD-WRT 24 (RC5) and just added this line in Administration > Commands > Startup :

    Code:
    (sleep 20 ; insmod ebtables ; insmod ebtable_filter ; ebtables -A FORWARD -i wl0.2 -j DROP) &
    
    This code waits 20 seconds (until the router finished to initialize), loads the ebtables modules and adds a bridge filtering rule which filters all packets from wl0.2 before going into the bridge.

    Wifi users connecting via the wl0.2 interface, still have access to Internet, but not to VLAN.
    Authenticated users accesing via the wl0.1 interface (using WPA2) have access to Internet + VLAN.

    Please send me comments.
    If I find any drawback, I will post it here.
     
  59. Bird333

    Bird333 Network Guru Member

    Can you explain to me how the 'drop' target works with ebtables as it relates to the router? In my mind (iptables mindset) the 'drop' target means the packet just gets deleted. Where does the packet go when it hits a 'drop' with ebtables?

    Thanks!
     

Share This Page