Joined: 02 Mar 2020
|Posted: Wed Feb 17, 2021 14:45 Post subject: Re: Dumb Q2: How to get DHCP IP's w/ bridged VLAN+VAP?
|MrPete wrote: |
a) When I create the bridge, it wants me to assign an IP. Doesn't that 'break' obtaining it via DHCP (and telling the upstream switch/router that I'm here?)
Please attach screenshots to get a better understanding of your setup.
Look here for DNSmasq and iptable configuration: https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=720863
Additionally, here is my iptable setup.
iptables -I FORWARD -i br1 -d `nvram get lan_ipaddr`/`nvram get lan_netmask` -m state --state NEW -j DROP
iptables -I FORWARD -i br2 -d `nvram get lan_ipaddr`/`nvram get lan_netmask` -m state --state NEW -j DROP
iptables -t nat -I POSTROUTING -o br0 -j SNAT --to `nvram get lan_ipaddr`
iptables -I INPUT -i br1 -m state --state NEW -j DROP
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 -m state --state NEW -j DROP
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
iptables -t mangle -A PREROUTING -s 192.168.1.6 -j TEE --gateway 192.168.1.7
Joined: 18 Sep 2010
|Posted: Wed Feb 17, 2021 17:52 Post subject:
|This is a classic case of not fully appreciating the intent of the router as seen by the developer.
YOU are trying to use the router as a layer-2 device (managed switch), whereas the intent (from the developers perspective) is to support a layer-3 device (i.e., routing). As such, the developer treats any new bridge as an IP addressable network interface on the router, w/ its own DHCP server, capable of being firewall'd from other networks, and routable over the WAN.
IOW, you and the developer are solving different problems, and that difference is reflected in what the GUI expects and demands for its proper configuration. Yes, sometimes you can sort of, kind of, w/ some difficulty, make it work as just a managed switch. But again, that's NOT the intent for most third-party firmwares. In some cases (e.g., Merlin), user-defined VLANs, VAPs, and bridges aren't supported at all. And when you do find it (dd-wrt, tomato, etc), it's still designed for the purposes of routing.
All that said, that's not to say you can't make it work as you want, at least sometimes. As you've configured it, the IP/network assigned to the bridge is superfluous. And presumably you have NOT created a DHCP server for it either (those requests will be forwarded upstream to the primary router). But don't be confused by what appear to be oddities (like having to define an IP and network for a given bridge) given what problem the router is intended to solve. Truth be told, a more appropriate device would be a wireless managed switch, and NOT a wireless router (which incidentally has a marginally manageable integrated switch). The former would be more consistent w/ your expectations given its intent is purely switching.
ddwrt-ovpn-split-basic.sh * ddwrt-ovpn-split-advanced.sh * ddwrt-ovpn-kill-switch.sh (new) * ddwrt-ovpn-watchdog.sh (new) * ddwrt-ovpn-remote-access.sh * ddwrt-ovpn-client-backup.sh * ddwrt-mount-usb-drives.sh