Talk:Separate LAN and WLAN
From DD-WRT Wiki
(Difference between revisions)
| Revision as of 07:24, 12 July 2007 (edit) Devu6ka2 (Talk | contribs) (medecine) ← 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) |
||
| (5 intermediate revisions not shown.) | |||
| Line 12: | Line 12: | ||
| == dnsmasq errors out with Can't bind 192.168.1.1 socket already in use == | == 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)