Talk:Separate LAN and WLAN

From DD-WRT Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 14:33, 20 June 2006 (edit)
222.103.208.192 (Talk)

← Previous diff
Current revision (20:54, 14 February 2020) (edit) (undo)
Tag (Talk | contribs)
(iptables vs. ebtables? - Add an alternative leaving the wireless interfaces unbridged)
 
(19 intermediate revisions not shown.)
Line 1: Line 1:
 +Improvements that are not yet included on this page:<br>
 +1. DHCP issue resolved<br>
 +2. WPA/WPA2 didn't work with the steps I posted originally - Works with the updated instructions.<br>
 +3. Firewall rules tightened up a bit. (The router is arguably "more secure" from the Wireless clients than with my last set of instructions)<br>
-24868202788540219865+ 
 +== No update yet ==
 + 
 +Almost a yearand still no update of the page... [[User:Towsonu2003|Towsonu2003]] 23:21, 7 Sep 2006 (CEST)
 +:obviosly dead, need some input on this --[[User:Whiteboy|whiteboy]] 05:26, 14 Dec 2006 (CET)
 + 
 +== dnsmasq errors out with Can't bind 192.168.1.1 socket already in use ==
 + 
 +== iptables vs. ebtables? ==
 + 
 +Is there any reason that isolation of (bridged) wireless interfaces can't be achieved with ebtables? As far as I can tell, I have been able to isolate both wireless interfaces with the following startup script:
 + 
 + insmod ebtables
 + insmod ebtable_filter
 + insmod ebtable_broute
 + insmod ebt_ip
 +
 + #DHCP
 + ebtables -t filter -I INPUT 1 -p IPv4 --ip-proto udp --ip-dport 67 -j ACCEPT
 + #DNS
 + ebtables -t filter -I INPUT 2 -p IPv4 --ip-proto udp --ip-dport 53 -j ACCEPT
 + ebtables -t filter -I INPUT 3 -p IPv4 --ip-proto tcp --ip-dport 53 -j ACCEPT
 + #PROTECT ROUTER
 + ebtables -t filter -I INPUT 4 -p IPv4 -i eth1 --ip-dst 192.168.0.0/16 -j DROP
 + ebtables -t filter -I INPUT 5 -p IPv4 -i eth2 --ip-dst 192.168.0.0/16 -j DROP
 +
 + #ISOLATE
 + ebtables -t filter -I FORWARD 1 -i eth1 -j DROP
 + ebtables -t filter -I FORWARD 2 -i eth2 -j DROP
 + ebtables -t filter -I FORWARD 3 -o eth1 -j DROP
 + ebtables -t filter -I FORWARD 4 -o eth2 -j DROP
 +
 + #DHCP
 + ebtables -t filter -I OUTPUT 1 -p IPv4 --ip-proto udp --ip-sport 67 -j ACCEPT
 + #DNS
 + ebtables -t filter -I OUTPUT 2 -p IPv4 --ip-proto udp --ip-sport 53 -j ACCEPT
 + ebtables -t filter -I OUTPUT 3 -p IPv4 --ip-proto tcp --ip-sport 53 -j ACCEPT
 + #PROTECT ROUTER
 + ebtables -t filter -I OUTPUT 4 -p IPv4 -o eth1 --ip-src 192.168.0.0/16 -j DROP
 + ebtables -t filter -I OUTPUT 5 -p IPv4 -o eth2 --ip-src 192.168.0.0/16 -j DROP
 + 
 +--[[User:Tag|Tag]] 08:06, 14 February 2020 (CET)
 +: Or, after removing from br0, why is it necessary to attach to a new bridge? Leaving the wireless interfaces unbridged leads to a nice, succinct startup script:
 + iptables -I FORWARD 1 -i eth1 -o ! vlan2 -j DROP
 + iptables -I FORWARD 2 -i eth2 -o ! vlan2 -j DROP
 +: --[[User:Tag|Tag]] 21:54, 14 February 2020 (CET)

Current revision

Improvements that are not yet included on this page:
1. DHCP issue resolved
2. WPA/WPA2 didn't work with the steps I posted originally - Works with the updated instructions.
3. Firewall rules tightened up a bit. (The router is arguably "more secure" from the Wireless clients than with my last set of instructions)


[edit] No update yet

Almost a yearand still no update of the page... Towsonu2003 23:21, 7 Sep 2006 (CEST)

obviosly dead, need some input on this --whiteboy 05:26, 14 Dec 2006 (CET)

[edit] dnsmasq errors out with Can't bind 192.168.1.1 socket already in use

[edit] iptables vs. ebtables?

Is there any reason that isolation of (bridged) wireless interfaces can't be achieved with ebtables? As far as I can tell, I have been able to isolate both wireless interfaces with the following startup script:

insmod ebtables
insmod ebtable_filter
insmod ebtable_broute
insmod ebt_ip

#DHCP
ebtables -t filter -I INPUT 1 -p IPv4 --ip-proto udp --ip-dport 67 -j ACCEPT
#DNS
ebtables -t filter -I INPUT 2 -p IPv4 --ip-proto udp --ip-dport 53 -j ACCEPT
ebtables -t filter -I INPUT 3 -p IPv4 --ip-proto tcp --ip-dport 53 -j ACCEPT
#PROTECT ROUTER
ebtables -t filter -I INPUT 4 -p IPv4 -i eth1 --ip-dst 192.168.0.0/16 -j DROP
ebtables -t filter -I INPUT 5 -p IPv4 -i eth2 --ip-dst 192.168.0.0/16 -j DROP

#ISOLATE
ebtables -t filter -I FORWARD 1 -i eth1 -j DROP
ebtables -t filter -I FORWARD 2 -i eth2 -j DROP
ebtables -t filter -I FORWARD 3 -o eth1 -j DROP
ebtables -t filter -I FORWARD 4 -o eth2 -j DROP

#DHCP
ebtables -t filter -I OUTPUT 1 -p IPv4 --ip-proto udp --ip-sport 67 -j ACCEPT
#DNS
ebtables -t filter -I OUTPUT 2 -p IPv4 --ip-proto udp --ip-sport 53 -j ACCEPT
ebtables -t filter -I OUTPUT 3 -p IPv4 --ip-proto tcp --ip-sport 53 -j ACCEPT
#PROTECT ROUTER
ebtables -t filter -I OUTPUT 4 -p IPv4 -o eth1 --ip-src 192.168.0.0/16 -j DROP
ebtables -t filter -I OUTPUT 5 -p IPv4 -o eth2 --ip-src 192.168.0.0/16 -j DROP

--Tag 08:06, 14 February 2020 (CET)

Or, after removing from br0, why is it necessary to attach to a new bridge? Leaving the wireless interfaces unbridged leads to a nice, succinct startup script:
iptables -I FORWARD 1 -i eth1 -o ! vlan2 -j DROP
iptables -I FORWARD 2 -i eth2 -o ! vlan2 -j DROP
--Tag 21:54, 14 February 2020 (CET)