Talk:Separate LAN and WLAN
From DD-WRT Wiki
(Difference between revisions)
Revision as of 19:16, 20 June 2006 (edit) Atzekalle (Talk | contribs) m (Reverted vandalism) ← 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) |
||
(18 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> | ||
+ | |||
+ | == 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)