Both unbridged WLANs are work great, devices receive an address, can access internet but neither can ping their gateway. (ping to 192.168.3.1 returns "request timeout")
Why is this a problem you ask? Well Belkin in their infinite wisdom coded their Wemo switch to ping its local gateway as a test for network connectivity. The Wemo device is on the WLAN, answers pings, and can be controlled by the Wemo app as long as it is on same WLAN. But the switch flashes amber light indicating "no connectivity" and the app will not allow remote access to be enabled.
I read and attempted guide at http://www.dd-wrt.com/wiki/index.php/Multiple_WLANs (Several times) Things worked great up to point where the WLAN ath0.2 is moved to its own bridge and DHCP server; connections to that WLAN no longer receive an address and instead adopt a link-local IP.
Help needed. Either a) get gateway to answer pings when in unbridged mode, or b) assistance with bridged configuration.
Joined: 12 Oct 2017 Posts: 2 Location: Houston, Texas, USA
Posted: Fri Oct 13, 2017 17:25 Post subject: [SOLVED] Virtual Interface WLAN works except can't ping own
OK, it turns out my issue of devices not getting an IP address when accessing the wireless network was self-inflicted. The netmask for each bridge was left as all zeros (my bad) which prevented the dhcp server from acting as expected.
In fact the contents of /tmp/dnsmasq.conf file had non-sense entries for br1 and br2 dhcp ranges.
dhcp-range=br1,0.0.0.100,0.0.0.149,0.0.0.0,1440m
dhcp-range=br2,0.0.0.100,0.0.0.149,0.0.0.0,1440m
So after adding netmask value of 255.255.255.0 to the two new bridges, devices connecting to wireless could obtain an IP address and access internet. The next step is to restrict access to each other and the router itself. Below is a list of iptables rules added under Administration->Commands with "Save Firewall" button. NOTE: Comments are added for clarity and are NOT to be entered in Adminstration->Commands window.
Code:
# Prevent access to AT&T Residential Gateway control interface
iptables -I FORWARD -d 192.168.1.254 -i br1 -j DROP
iptables -I FORWARD -d 192.168.1.254 -i br2 -j DROP
# Prevent "guest" type bridges from access primary LAN nor each other
iptables -I FORWARD -i br1 -o br0 -j DROP
iptables -I FORWARD -i br1 -o br2 -j DROP
iptables -I FORWARD -i br2 -o br0 -j DROP
iptables -I FORWARD -i br2 -o br1 -j DROP
# Prevent "guest" type bridges from accessing anything on router.
iptables -I INPUT -i br1 -m state --state NEW -j DROP
iptables -I INPUT -i br2 -m state --state NEW -j DROP
# Allow "guest" type bridges access to DHCP and DNS servers
iptables -I INPUT -i br1 -p udp --dport 67 -j ACCEPT
iptables -I INPUT -i br1 -p udp --dport 53 -j ACCEPT
iptables -I INPUT -i br1 -p tcp --dport 53 -j ACCEPT
iptables -I INPUT -i br2 -p udp --dport 67 -j ACCEPT
iptables -I INPUT -i br2 -p udp --dport 53 -j ACCEPT
iptables -I INPUT -i br2 -p tcp --dport 53 -j ACCEPT
# Allow "guest" type bridges to ping their own gateway since "drop all local
# router access" line will prevent pings from operating.
iptables -I INPUT -i br1 -p icmp -d `nvram get br1_ipaddr` -j ACCEPT
iptables -I INPUT -i br2 -p icmp -d `nvram get br2_ipaddr` -j ACCEPT
Hopefully this helps someone else from falling in the same hole I did. _________________ -- John P.
