DD-WRT IPTables

Discussion in 'DD-WRT Firmware' started by smitty870, May 4, 2018.

  1. smitty870

    smitty870 Networkin' Nut Member

    So I am having mild success in getting firewall rules to work in DD-WRT on the RT-N66U and now the RT-AC68U. I sure it's user error and even with google searching I seem to be having issues find the right answers. I've come up with what should be good examples and they just do not seem to work.
    I've also tried the DENY/BLOCK Rules as last on my list which then devices on BR1/BR2 would not pick up DHCP. I also have issues with devices on BR1/BR2 once in a while saying no internet. Any recommendations would I would be grateful for!

    ##################### DENY / BLOCK RULES #####################
    #
    # Block all BR1/BR2 from BR0
    iptables -I INPUT -i br1 -m state --state NEW -j DROP
    iptables -I INPUT -i br2 -m state --state NEW -j DROP
    #
    # Block BR1/2 from being to access br0. br1-br2. br2-br1
    iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP
    iptables -I FORWARD -i br2 -o br0 -m state --state NEW -j DROP
    #
    # Block br1/2 from WebGUI
    iptables -I INPUT -i br1 -d 192.168.10.1 -j DROP
    iptables -I INPUT -i br1 -d 192.168.20.1 -j DROP
    iptables -I INPUT -i br1 -d 192.168.30.1 -j DROP
    iptables -I INPUT -i br2 -d 192.168.10.1 -j DROP
    iptables -I INPUT -i br2 -d 192.168.20.1 -j DROP
    iptables -I INPUT -i br2 -d 192.168.30.1 -j DROP

    #
    ##################### Allow Rules #####################
    #
    # Allow br2 devices access to br0 Devices
    # Device #1
    $
    # FTP
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 64021 -j ACCEPT
    iptables -I FORWARD -d 192.168.30.22 -s 192.168.10.9 -p tcp --sport 64021 -j ACCEPT
    # Plex
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 32400 -j ACCEPT
    iptables -I FORWARD -d 192.168.30.22 -s 192.168.10.9 -p tcp --sport 32400 -j ACCEPT
    # PRTG
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 8009 -j ACCEPT
    iptables -I FORWARD -d 192.168.30.22 -s 192.168.10.9 -p tcp --sport 8009 -j ACCEPT
    # Router Interface
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.1 -p tcp --dport 443 -j ACCEPT
    iptables -I FORWARD -d 192.168.30.22 -s 192.168.10.1 -p tcp --sport 443 -j ACCEPT
    # SMB
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 445 -j ACCEPT
    iptables -I FORWARD -d 192.168.30.22 -s 192.168.10.9 -p tcp --sport 445 -j ACCEPT
    #
    # Device 2
    #
    # FTP
    iptables -I FORWARD -s 192.168.30.21 -d 192.168.10.9 -p tcp --dport 64021 -j ACCEPT
    iptables -I FORWARD -d 192.168.30.21 -s 192.168.10.9 -p tcp --sport 64021 -j ACCEPT
    # SMB
    iptables -I FORWARD -s 192.168.30.21 -d 192.168.10.9 -p tcp --dport 445 -j ACCEPT
    iptables -I FORWARD -d 192.168.30.21 -s 192.168.10.9 -p tcp --sport 445 -j ACCEPT
    #
    # Allow ALL access to HP printer
    iptables -I FORWARD -i br1 -d 192.168.10.15 -j ACCEPT
    iptables -I FORWARD -i br2 -d 192.168.10.15 -j ACCEPT
    #
    #All BR1 Ping Testing for Iptable rules
    iptables -I FORWARD -i br1 -d 192.168.10.161 -p icmp -j ACCEPT
    #
    # OpenVPN
    #
    #iptables -I INPUT 1 -p udp -dport 1194 -j ACCEPT
    #iptables -t nat -I PREROUTING -p udp --dport 443 -j ACCEPT
    iptables -I INPUT -p tcp --dport 443 -j ACCEPT
    iptables -I FORWARD 1 -source 10.1.1.0/24 -j ACCEPT
    iptables -I FORWARD 1 -source tun2 -j ACCEPT
    iptables -I FORWARD -i br0 -o tun2 -j ACCEPT
    iptables -I FORWARD -i tun2 -o br0 -j ACCEPT
    iptables -I FORWARD -i tun2 -o br1 -j ACCEPT
    # iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -j MASQUERADE
    iptables -t nat -A POSTROUTING -o `get_wanface` -j MASQUERADE
    #
    # All BR0 to other BR Clients
    #
    iptables -I FORWARD -s 192.168.10.0/24 -d 192.168.20.0/24 -j ACCEPT
    iptables -I FORWARD -s 192.168.10.0/24 -d 192.168.30.0/24 -j ACCEPT
    #
    # Allow access to DCHP/DNS Servers
    #
    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 br1 -p udp --dport 67 -j ACCEPT
    iptables -I INPUT -i br1 -p tcp --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 -I INPUT -i br2 -p udp --dport 67 -j ACCEPT
    iptables -I INPUT -i br2 -p tcp --dport 67 -j ACCEPT
    #

    Settings as reconfigured are attached in screenshots.
     

    Attached Files:

  2. eibgrad

    eibgrad Network Guru Member

    My overall impression is that you've made this overly (and unnecessarily) complex. Some of it is just simply redundant.

    For example, once you block access to the router w/ the following ...

    Code:
    # Block all BR1/BR2 from BR0
    iptables -I INPUT -i br1 -m state --state NEW -j DROP
    iptables -I INPUT -i br2 -m state --state NEW -j DROP
    ... the following is redundant.

    Code:
    # Block br1/2 from WebGUI
    iptables -I INPUT -i br1 -d 192.168.10.1 -j DROP
    iptables -I INPUT -i br1 -d 192.168.20.1 -j DROP
    iptables -I INPUT -i br1 -d 192.168.30.1 -j DROP
    iptables -I INPUT -i br2 -d 192.168.10.1 -j DROP
    iptables -I INPUT -i br2 -d 192.168.20.1 -j DROP
    iptables -I INPUT -i br2 -d 192.168.30.1 -j DROP
    You're doing the same thing w/ the FORWARD chain. Although the following is fine (it prevents br1 and br2 from accessing br0) ...

    Code:
    # Block BR1/2 from being to access br0. br1-br2. br2-br1
    iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP
    iptables -I FORWARD -i br2 -o br0 -m state --state NEW -j DROP
    ... the following is unnecessary.

    Code:
    # All BR0 to other BR Clients
    #
    iptables -I FORWARD -s 192.168.10.0/24 -d 192.168.20.0/24 -j ACCEPT
    iptables -I FORWARD -s 192.168.10.0/24 -d 192.168.30.0/24 -j ACCEPT
    dd-wrt is (iirc), by default, NOT blocking access between the bridges. That's why you needed to add the blocking rules (based on the network interfaces br1 and br2) above. But since br1 and br2 are only being blocked when they attempt to *initiate* a *NEW* connection from their own network interfaces to some other network interface, any attempt to send replies back to br0 from br1 and br2 will work just fine.

    IOW, once you've configure your blocking rules based on network interfaces, you're done, *unless* you're trying to make exceptions for specific devices. Now you begin to see things like source and/or destination IPs, which is exactly what you did in the following rules.

    Code:
    # Allow ALL access to HP printer
    iptables -I FORWARD -i br1 -d 192.168.10.15 -j ACCEPT
    iptables -I FORWARD -i br2 -d 192.168.10.15 -j ACCEPT
    However, even these rules are unnecessary since br0 has unfettered access to these destinations by default (you added no rules to prevent access from br0 to either br1 or br2). Therefore, the above rules are pointless.

    As far as the FTP rules, the following is the wrong approach.

    Code:
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 64021 -j ACCEPT
    iptables -I FORWARD -d 192.168.30.22 -s 192.168.10.9 -p tcp --sport 64021 -j ACCEPT
    You only need the *first* rule in a case like this. Once the connection is made from the source to the destination, the replies will be allowed back in the other direction automatically thanks to the ESTABLISHED/RELATED rule in the same chain.

    Also, in general, I prefer REJECT rather than DROP as a target for internal use. REJECT differs from DROP because unlike the latter, the former actually sends a reply immediately back to the client, thus making it more "friendly". The user doesn't sit there waiting for the connection to timeout, and perhaps sending multiple requests in frustration. Leave the use of DROP for the internet side of the WAN, when you want to make it painful for intruders.

    FWIW, here's my own dd-wrt guest firewall script, which could easily be modified to support additional bridges.

    https://pastebin.com/r4u62P0B

    Notice how little is needed. I block access to the private network and router by guests, but make sure they have the minimal necessary to work w/ the router (dhcp, dns, and icmp (I allow this for debugging purposes, but that's your choice)). The only thing I'm not doing is making exceptions for specific devices, which could be easily added.

    And btw, on the Setup page, under Router IP, there's no need to configure either the Gateway or Local DNS fields. Those are only relevant in a WAP configuration (where the router is configured LAN to LAN wrt the primary router). In such a case, the router is just another LAN device and so it needs a Gateway and Local DNS setting, like any other LAN client. But in a routed config (WAN to LAN wrt the primary router), the router gets its gateway and DNS settings from the upstream router over the WAN. So in that case, you can leave the Gateway and Local DNS fields blank.
     
    Last edited: May 6, 2018
  3. eibgrad

    eibgrad Network Guru Member

    P.S. You also don't need any of those OpenVPN rules. The OpenVPN client GUI is smart enough to generate all the rules it needs. In fact, adding rules is likely to break things. The fact you specified tun2 in the rules strongly suggests you added "dev tun2" to the Additional Config field, since the default used by the router is "dev tun1". And the auto-generated firewall rules are based on tun1. IOW, by adding "dev tun2" to Additional Config, it acts as an override, and you end up breaking the existing auto-generated firewall rules. And now you end up having to create your own.

    This is a common problem w/ the dd-wrt OpenVPN client GUI. Ppl over-configure it. You typically don't need anything in the Additional Config field, nor any firewall rules of your own. The only exception that comes to mind is if your VPN provider requires username/password. Some of the older builds don't have GUI options for these settings, and so you may need to specify the auth-user-pass directive in Additional Config in such instances. But newer builds should make this unnecessary.
     
  4. smitty870

    smitty870 Networkin' Nut Member


    Sorry for my late response, I must need to update my email and preferences. I did not realize I had a response waiting until today.

    I ended up trial and error with these rules that seem to work well.

    # Firewall Rules to secure the private network and give the guest network internet access:
    iptables -I FORWARD -i br1 -m state --state NEW -j ACCEPT
    iptables -I FORWARD -i br2 -m state --state NEW -j ACCEPT

    I understand correctly I thought change these to REJECT?
    So your saying I do need need these rules at all?
    # Block BR1/2 from being to access br0. br1-br2. br2-br1
    iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP
    iptables -I FORWARD -i br1 -o br2 -m state --state NEW -j DROP
    iptables -I FORWARD -i br2 -o br0 -m state --state NEW -j DROP
    iptables -I FORWARD -i br2 -o br1 -m state --state NEW -j DROP

    # NAT to make Internet work
    iptables -t nat -I POSTROUTING -o `get_wanface` -j SNAT --to `nvram get wan_ipaddr`
    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


    I suspect this will be overkill? I had read and was told in other forums I should be using example "iptables -I INPUT -i br1 -d 192.168.10.1 -j DROP" to ensure guests do not have access to the web interface of the router.
    I also read I should be blocking services on the router to the guests.
    # Block br1/2 from WebGUI
    iptables -I INPUT -i br1 -d 192.168.10.1 -j DROP
    iptables -I INPUT -i br1 -d 192.168.20.1 -j DROP
    iptables -I INPUT -i br1 -d 192.168.30.1 -j DROP
    iptables -I INPUT -i br2 -d 192.168.10.1 -j DROP
    iptables -I INPUT -i br2 -d 192.168.20.1 -j DROP
    iptables -I INPUT -i br2 -d 192.168.30.1 -j DROP
    iptables -I INPUT -i br1 -p tcp --dport telnet -j REJECT --reject-with tcp-reset
    iptables -I INPUT -i br1 -p tcp --dport ssh -j REJECT --reject-with tcp-reset
    iptables -I INPUT -i br1 -p tcp --dport www -j REJECT --reject-with tcp-reset
    iptables -I INPUT -i br1 -p tcp --dport http -j REJECT --reject-with tcp-reset
    iptables -I INPUT -i br1 -p tcp --dport https -j REJECT --reject-with tcp-reset
    iptables -I INPUT -i br2 -p tcp --dport telnet -j REJECT --reject-with tcp-reset
    iptables -I INPUT -i br2 -p tcp --dport ssh -j REJECT --reject-with tcp-reset
    iptables -I INPUT -i br2 -p tcp --dport www -j REJECT --reject-with tcp-reset
    iptables -I INPUT -i br2 -p tcp --dport http -j REJECT --reject-with tcp-reset
    iptables -I INPUT -i br2 -p tcp --dport https -j REJECT --reject-with tcp-reset


    # Allow br2 devices access to br0 Devices
    #
    When I had, it was a suggestion from another forum and I thought about the whole BR0 has acess to BR1/2 that it should matter. I took our all the BR0 to BR2 rulles and it works fine.
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 64021 -j ACCEPT
    iptables -I FORWARD -d 192.168.30.22 -s 192.168.10.9 -p tcp --sport 64021 -j ACCEPT

    # FTP
    iptables -I FORWARD -s 192.168.30.47 -d 192.168.10.9 -p tcp --dport 64021 -j ACCEPT
    iptables -I FORWARD -d 192.168.30.47 -s 192.168.10.9 -p tcp --sport 64021 -j ACCEPT

    # Plex
    iptables -I FORWARD -s 192.168.30.47 -d 192.168.10.9 -p tcp --dport 32400 -j ACCEPT
    iptables -I FORWARD -d 192.168.30.47 -s 192.168.10.9 -p tcp --sport 32400 -j ACCEPT
    #
    # Pixel XL

    I did a have a mutl-iport rule and was told DD-WRT did not support the muti-port, is that not no longer an accurate statement?
    # FTP
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 64021 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 64022 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 64023 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 64024 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 64025 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 64026 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 64027 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 64028 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 64028 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 64029 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 64030 -j ACCEPT

    # PRTG
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 8009 -j ACCEPT
    # SMB
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 445 -j ACCEPT
    #CPUTemp
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 5209 -j ACCEPT
    #SABnzbs
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 9090 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.22 -d 192.168.10.9 -p tcp --dport 9094 -j ACCEPT
    #
    #
    # GN2
    # FTP
    iptables -I FORWARD -s 192.168.30.21 -d 192.168.10.9 -p tcp --dport 64021 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.21 -d 192.168.10.9 -p tcp --dport 64022 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.21 -d 192.168.10.9 -p tcp --dport 64023 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.21 -d 192.168.10.9 -p tcp --dport 64024 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.21 -d 192.168.10.9 -p tcp --dport 64025 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.21 -d 192.168.10.9 -p tcp --dport 64026 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.21 -d 192.168.10.9 -p tcp --dport 64027 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.21 -d 192.168.10.9 -p tcp --dport 64028 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.21 -d 192.168.10.9 -p tcp --dport 64028 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.21 -d 192.168.10.9 -p tcp --dport 64029 -j ACCEPT
    iptables -I FORWARD -s 192.168.30.21 -d 192.168.10.9 -p tcp --dport 64030 -j ACCEPT
    # SMB
    iptables -I FORWARD -s 192.168.30.21 -d 192.168.10.9 -p tcp --dport 445 -j ACCEPT

    # Allow ALL access to HP Laserjet printer
    iptables -I FORWARD -i br1 -d 192.168.10.15 -j ACCEPT
    iptables -I FORWARD -i br2 -d 192.168.10.15 -j ACCEPT

    # All Devices Plex
    iptables -I FORWARD -s br1 -d 192.168.10.9 -p tcp --dport 32400 -j ACCEPT
    iptables -I FORWARD -s br2 -d 192.168.10.9 -p tcp --dport 32400 -j ACCEPT

    No longer need as handled internally by DD-WRT correct?
    # OpenVPN
    iptables -I FORWARD 1 -source 10.1.1.0/24 -j ACCEPT
    iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -j MASQUERADE

    # All BR0 to other BR Clients
    iptables -I FORWARD -s br0 -d br1 -j ACCEPT
    iptables -I FORWARD -s br0 -d br2 -j ACCEPT

    Again, told multi-port rules do not work with DD-WRT.
    # Allow access to DHCP/DNS Servers
    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 br1 -p udp --dport 67 -j ACCEPT
    iptables -I INPUT -i br1 -p tcp --dport 67 -j ACCEPT
    iptables -I INPUT -i br1 -p udp --dport 68 -j ACCEPT
    iptables -I INPUT -i br1 -p tcp --dport 68 -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 -I INPUT -i br2 -p udp --dport 67 -j ACCEPT
    iptables -I INPUT -i br2 -p tcp --dport 67 -j ACCEPT
    iptables -I INPUT -i br2 -p udp --dport 68 -j ACCEPT
    iptables -I INPUT -i br2 -p tcp --dport 68 -j ACCEPT
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice