TL-WDR3600One of our most popular posts was information on how to do VLANs and OpenVPN on DD-WRT, but I just recently discovered a couple of mistakes in the iptables rules due to come confusion over how DD-WRT handles interface names for the primary LAN.

I’ve been trying for a LONG time to get a couple of test machines on my bench VLAN to print to my main laser printers. Never could seem to get it working.

Turns out my rules above were a little bit off…

One of the things you HAVE to get familiar with when using DD-WRT is the interface nomenclature can change based on the device you use.

In my examples above – I used vlan1 as my primary LAN. In my firewall rules, I used that as well (vlan+ to specify ALL networks – how handy!) The problem is… it doesn’t always work. In the scope of VLANs, vlan1 is useful and recognized. But when it comes to the firewall… It’s not (and I thought it was). Instead, iptables looks at the bridge br0. This makes sense. A WiFi router by default has to bridge the LAN interface AND wireless. So in my hardware’s case – br0 contains eth0 (the main switch), ath0 (2.4GHz WiFi), and ath1 (5GHz WiFi). Looking at ifconfig, you’ll see that vlan1 exists, but has no IP address. The IP address is on br0.

That means my rules above will allow traffic from the other VLANs to the main vlan1/br0 because vlan+ is a wildcard only for VLANs.

So the firewall rules REALLY need to be as follows:

# Restrict RIP access from WAN
iptables -I INPUT -p udp -i vlan3 –dport 520 -j DROP
iptables -I INPUT -p udp -i vlan4 –dport 520 -j DROP
iptables -I INPUT -p udp -i vlan6 –dport 520 -j DROP
iptables -I INPUT -p udp -i vlan7 –dport 520 -j DROP

# OpenVPN Access
iptables -A INPUT -i tap0 -j ACCEPT
iptables -I INPUT -p udp –dport 1194 -j ACCEPT

# Block all traffic between VLANs
iptables -I FORWARD -i vlan+ -o vlan+ -j DROP
iptables -I FORWARD -i vlan+ -o br0 -j DROP
iptables -I FORWARD -i br0 -o vlan+ -j DROP

# Allow VLANs to communicate with WAN (vlan2)
iptables -I FORWARD -i br0 -o vlan2 -j ACCEPT
iptables -I FORWARD -i vlan2 -o br0 -j ACCEPT
iptables -I FORWARD -i vlan+ -o vlan2 -j ACCEPT
iptables -I FORWARD -i vlan2 -o vlan+ -j ACCEPT

Ironically – with my firewall mistake – I should have always been able to print to the printers (oops). But I couldn’t. Turns out – my local Windows firewall was blocking it. I use BitDefender AV and their firewall tends to be VERY picky. Especially on these machines – given it’s a ‘bench’ LAN often filled with infected machines, I have the interfaces set to ‘Public’. Well, despite traffic going out to the other subnet, it didn’t like the idea of return traffic coming from another private subnet (.5.x vs .7.x). When I added an exemption for the printer IPs in the firewall? Bang – worked wonders. So the iptables rules ARE simple…

# Allow printing from Bench LAN PCs
iptables -I FORWARD -p tcp -s -d -j ACCEPT
iptables -I FORWARD -p tcp -s -d -j ACCEPT

And repeat for each printer and Bench PC. Now – could I probably do something a bit tighter like…

iptables -I FORWARD -p tcp -s -d --dport 9100 -m state --state NEW -j ACCEPT
iptables -I FORWARD -p tcp -s -d --sport 9100 -m state --state ESTABLISHED,RELATED -j ACCEPT

Probably – but I had wasted so much time on this already – I didn’t have time to test this further, plus one printer allows for scanning and I may want to install the scan suite on a Test PC to scan. Experiment as you wish. I figured for now on two private LANs the IP tests were enough.

So sorry about that mixup. I used to use br0 in my firewall rules on Broadcom and when I could simplify with vlan+, I did it when I moved to Atheros. My testing indicated it worked – but apparently only because my local firewall was blocking stuff. Note to self – disable the local firewall when testing the router one. SMH.