Posted: Mon Jun 03, 2019 2:39 Post subject: Trouble set up Guest Networking wl0.1 & wl1.1 with bridg
I have a R6700 with latest Kong dd-wrt firmware used as my main router/gateway at 192.168.1.1.
I am trying to setup a bridged pair of 2.4GhZ and 5.0Ghz wireless guest networks on 192.168.2.x that are isolated from my own, secured 192.168.1.x network.
After much browsing of forums, I am using the following constellation of configurations:
Code:
[Setup - Basic Settings]
Use DNSMasq for DHCP: Check
[Wireless - Basic Settings] Added virtual interfaces for wl0.1 and Wl1.1, with SSID Guest-2.4 and Guest-5.0 respectively, with each having the following configurations:
Wireless SSID Broadcast: Checked
AP Isolation: Unchecked
Optimize Multicast Traffic: Unchecked
Network Configuration : Bridged
[Wireless - Wireless Security]
Configured wl0.1 and wl1.1 with Security Mode set to 'disabled' for testing purposes (note the non-guest wl0 and wl1 networks are set to WPA2-PSK)
Note: I didn't add anything to the firewall
The SSIDs of both guest networks (wl0.1 and wl1.1) are broadcast.
However, I am not able to log into either network. It simply doesn't connect and the syslog shows no evidence of connecting. I tried both default dhcp and even connecting with a static address (192.168.2.100)
Note: the only mention of 'br1' in the syslog is the following duplicated entry at boot:
Code:
Dec 31 19:00:12 myrouter user.info : bridge : interface wl0.1 successfully added to bridge br1
Dec 31 19:00:12 myrouter user.info : bridge : interface wl1.1 successfully added to bridge br1
Dec 31 19:00:13 myrouter user.info : bridge : interface wl0.1 successfully added to bridge br1
Dec 31 19:00:13 myrouter user.info : bridge : interface wl1.1 successfully added to bridge br1
Similarly, /tmp/dnmasq.conf seems to indicate that br1 and dhcp are set up properly:
Joined: 18 Mar 2014 Posts: 12840 Location: Netherlands
Posted: Mon Jun 03, 2019 10:13 Post subject:
On a first glance your setup seems OK.
I would use the same encryption (WPA2/AES) in the past there were problems connecting if the encryption was different.
The latest build is not a very accurate description of the build number, in the latest Kong test build as of now 39855 VAP's are supposed to work better (but I have not verified that), in earlier builds VAP's were problemtatic and needed work arounds to start, from one of the build threads:
From approximately mid 2018 VAP's on Broadcom units are problematic, you cannot connect or do not get an IP address. There are workarounds :
1) When VAP is not working at boot; workaround startup command Administrationn/Commands, Save as Startup:
sleep 10; stopservice nas; stopservice wlconf; startservice wlconf; startservice nas;
2) Alternative way to get VAP working: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=317181
3) An other user reports the following workaround (save as startup):
sleep 4; stopservice cron; stopservice wlconf; wlconf eth1 up; wlconf eth2 up; startservice cron;
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=319412
4)This one is from @Redhawk (guaranteed to work ):
sleep 20; stopservice nas; wlconf eth1 down; wlconf eth2 down; wlconf eth1 up; wlconf eth2 up; startservice nas _________________ Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399 Install guide R7800/XR500:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614 Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
I would use the same encryption (WPA2/AES) in the past there were problems connecting if the encryption was different.
YUP - this is necessary for some reason!
egc wrote:
The latest build is not a very accurate description of the build number, in the latest Kong test build as of now 39855 VAP's are supposed to work better (but I have not verified that), in earlier builds VAP's were problemtatic and needed work arounds to start, from one of the build threads:
I am using DD-WRT v3.0-r38580M kongac from 02/05/19.
DD-WRT v3.0-r38580M kongac
The following startup command fixed it all...
egc wrote:
4)This one is from @Redhawk (guaranteed to work ):
sleep 20; stopservice nas; wlconf eth1 down; wlconf eth2 down; wlconf eth1 up; wlconf eth2 up; startservice nas
Note that perhaps not surprisingly, restarting eth1 makes wl0.1 work and restating eth2 makes wl1.1 work...
THANKS AGAIN... I WOULD NEVER HAVE FIGURED THIS OUT MYSELF
Posted: Tue Jun 04, 2019 3:50 Post subject: 2.4Ghz Guest fails after upgrading to r39855M
I just upgraded to the truly latest TEST version of Kong and now the wl0.1 2.4GHz guest network fails to connect but the wl1.1 5GHz one still works fine. Note that both the standard 2.4GHz and 5GHz networks (wl0 and wl1) work just fine
It seems to try logging in multiple times and then finally my phone returns with an "Incorrect Password" response.
Note that password is fine.
I also compared the pre- and post- NVRAM configs and I can't find anything relevant that has changed. There are just a few new parameters, a couple of the hardware MAC addresses have changed and both wl0_txbf_bfe_cap and wl0_txbf_bfr_cap have changed from 1 to 0 (but changing it back makes no difference).
Any idea what might have broken?
If not, I would like to downgrade but I can't find an old version of the r38580M binary for dd-wrt.v24-K3_AC_ARM_STD_128K.bin
Joined: 18 Mar 2014 Posts: 12840 Location: Netherlands
Posted: Tue Jun 04, 2019 5:36 Post subject:
The VAP bug is really frustrating.
Did you do an:
Code:
nvram erase && reboot
from the command line and put settings n manually?
When having problems it is good practive to start fresh.
It could well be that it is not helping and that you have to go back to on older build.
Normally we uses Vincent's repository for old Kong builds: http://ddwrt-kong.clonevince.fr/
But I took a quick peak and it could be that this version is missing (I can recall that the 38570 had a glitch and the same day Kong came with 38580, Vincent uses the date to track new builds so this one could have slipped).
But the good news is I have one for the R6400v2 and R6700v3.
Posted: Tue Jun 04, 2019 5:36 Post subject: What if any firewall rules should add?
Given that my bridged (br1) wl0.1 and wl1.1 guest networks are on a separate subnet from wl0 and wl1 (br0), do I need to add any other firewall rules to protect both my standard home network on br0 and the router itself?
from the command line and put settings n manually?
When having problems it is good practive to start fresh.
[\quote]
No I didn't... but I compared the before and after nvram settings and didn't notice any substantive changes other than a few added new parameters. So my assumption was that no need to erase.
It's a bit of a pain to erase and redo all the settings...
But I suppose I could do that...
egc wrote:
Normally we uses Vincent's repository for old Kong builds: http://ddwrt-kong.clonevince.fr/
But I took a quick peak and it could be that this version is missing (I can recall that the 38570 had a glitch and the same day Kong came with 38580, Vincent uses the date to track new builds so this one could have slipped).
But the good news is I have one for the R6400v2 and R6700v3.
I can you PM one if necessary
That would be great.
Note that I have the old r38580M version in the chk format (dd-wrt.K3_R6700V3.chk) but not in the binary version (dd-wrt.v24-K3_AC_ARM_STD_128K.bin).
And I can't get the 'chk' version to upgrade from the web interface, so I assumed I must need the 'bin' one.
Specifically, it acts like it is upgrading and flashing but nothing happens... it reboots to the same original version...
Would be easiest if I could figure out how to downgrade (and later upgrade) using chk versions.
If not, the would be great if you could pm me the binary version for r38580M
I have send you the version, but you really should try to reset with nvram erase etc.
I know it is a lot of work but it could be that it is working then.
The devs have been working on the VAP bug.
If you do an nvram erase please report your findings in the build thread so that we all know if it is working.
I will try when I have some spare time.
The challenge is I have a lot of settings especially around port forwarding and MAC filters. Now I have written scripts to upload them but still... a bit of a PITA.
egc wrote:
P.S. The .chk file only has a different header the rest is the same.
As DDWRT does not check the header I always assumed you could also use that, very strange, will test it out the next release.
Yes. It's strange...
For future reference, what is the size of the header so I can strip it off... (and hopefully not brick my router)...
I think it is the first 58 bytes (for Netgear routers like these), but do not take my word for it, you could brick your router tampering with the file.
I tested it on 2 different versions of Kong firmware -- and at least on those 2, stripping off first 58 bytes on the CHK file gives the same content as the corresponding BIN.
Posted: Fri Jun 07, 2019 3:24 Post subject: AP Isolation not working on the Guest Network
I just noticed that AP Isolation doesn't seem to be working properly between the two bridge arms (wl0.1 and wl1.1) on the guest network.
I checked the box for AP Isolation for wl0.1 and wl1.1
Interestingly, pings are properly blocked between 2 devices logged onto wl0.1 or between 2 devices logged onto wl1.1.
However, pings are not blocked between one device on wl0.1 and another on wl1.1.
I assume it's because iptables is only blocking traffic between devices on any given wireless network but not between networks.
I guess I really would like to enable AP Isolation at the level of the bridge (br1) so that no traffic would be allowed between any 2 devices on the same bridge. However, there is no such option.
Any thoughts on how to do this best perhaps manually using iptables?
Joined: 18 Mar 2014 Posts: 12840 Location: Netherlands
Posted: Fri Jun 07, 2019 10:12 Post subject:
If you tick AP isolation it isolates clients of that interface from each other so it works as it should.
However you create a new bridge and on that new bridge you also have to enable AP isolation, unfortuantely there is no radio button on BR1 to enable AP isolation so you have to do it manually.
AP islation and bridging is all taken place on OSI layer 2 (MAC layer) which is controlled by ebtables with a similar structure as iptables.
I might have the necessary rules somewhere in my notes but that will require some serious digging, I do not use ebtables, so I do no know it by heart.
If you tick AP isolation it isolates clients of that interface from each other so it works as it should.
However you create a new bridge and on that new bridge you also have to enable AP isolation, unfortuantely there is no radio button on BR1 to enable AP isolation so you have to do it manually.
AP islation and bridging is all taken place on OSI layer 2 (MAC layer) which is controlled by ebtables with a similar structure as iptables.
I might have the necessary rules somewhere in my notes but that will require some serious digging, I do not use ebtables, so I do no know it by heart.
It might be something like:
Code:
ebtables -I FORWARD -i br1 -o br1 -j DROP
But I could be totally wrong, not much of an ebtables expert
Thanks I will try the command later but your explanation is exactly what I was thinking.
Any reason why dd-wrt or at least Kong's version wouldn't include a notion of AP-isolation at the bridge level?
Indeed, in today's multi-radio routers, having AP Isolation at the interface level is almost useless, since all I need to do is to switch wireless bands to gain access to another wireless device.
The bridge seems to in general be the right level of abstraction as I imagine typically one would have a policy of plus/minus AP isolation across all devices accessing the bridge, regardless of interface.
If you tick AP isolation it isolates clients of that interface from each other so it works as it should.
However you create a new bridge and on that new bridge you also have to enable AP isolation, unfortuantely there is no radio button on BR1 to enable AP isolation so you have to do it manually.
AP islation and bridging is all taken place on OSI layer 2 (MAC layer) which is controlled by ebtables with a similar structure as iptables.
I might have the necessary rules somewhere in my notes but that will require some serious digging, I do not use ebtables, so I do no know it by heart.
It might be something like:
Code:
ebtables -I FORWARD -i br1 -o br1 -j DROP
But I could be totally wrong, not much of an ebtables expert
Thanks I will try the command later but your explanation is exactly what I was thinking.
Your code guess was close and enough to get me started... what works is:
Quote:
ebtables -I FORWARD --logical-in br1 --logical-out br1 -j DROP