How to allow subnet communication for my guest network?

Discussion in 'Tomato Firmware' started by Nazgulled, Apr 8, 2019.

  1. Nazgulled

    Nazgulled Serious Server Member

    Hi there,

    I have two subnets on my Tomato router:
    • br0: 192.168.0.0/24 (VLAN: 1, VID: 1)
    • br1: 172.16.0.0/24 (VLAN: 3, VID: 3)
    The first one is my main network where all my devices are connected to and the second one is my guest Wi-Fi network.

    Now, I have an AdGuard based DNS server running on 192.168.0.253:53, which I push to LAN clients with:
    • dhcp-option=tag:br0,6,192.168.0.253
    • dhcp-option=tag:br1,6,192.168.0.253
    As you probably guessed by now, the second dhcp-option (for br1) doesn't work because it's pushing an IP address on a different subnet.

    The question now becomes, how do I allow the guest network LAN clients to access a single host (192.168.0.253) on a different subnet? Should I use Advanced Settings » Routing » Static Routing Table for this? How exactly? Never used this feature... And just to be clear, I don't want the guest network LAN clients to be able to access any other address, just the .253 one.
     
  2. lancethepants

    lancethepants Network Guru Member

    You want to use Advanced >> Lan Access.
     
    Nazgulled likes this.
  3. Nazgulled

    Nazgulled Serious Server Member

    Seems pretty simple, will look into that when I get home later tonight. Thank you :)

    One additional question though, if I wanted to allow only access to port 53 and not anything else (for the guest network subnet only, not the main one), I'd need an iptables rule for that, right?
     
  4. Sean B.

    Sean B. Network Guru Member

    Change as required:

    Private LAN = br0
    Guest LAN = br1
    Protocol = UDP

    Code:
    iptables -t filter -I FORWARD 1 -i br1 -o br0 -p udp --dport 53 -j ACCEPT
    Return traffic will be allowed via the existing RELATED/ESTABLISHED rule. If you want both UDP and TCP protocols allowed, add another rule for TCP.

    If you want to limit to only one host on port 53:

    Code:
    iptables -t filter -I FORWARD 1 -i br1 -o br0 -p udp -d X.X.X.X --dport 53 -j ACCEPT
    Where X.X.X.X is the host IP you're allowing access to.
     
    Nazgulled likes this.
  5. Nazgulled

    Nazgulled Serious Server Member

    Nice! And the correct way to set that up is to add that line to Event Scripts » Firewall, right?
     
  6. Sean B.

    Sean B. Network Guru Member

    Correct.
     
  7. Nazgulled

    Nazgulled Serious Server Member

    Thank you, will try all that later :)
     
  8. Nazgulled

    Nazgulled Serious Server Member

    Added this but it didn't work...

    upload_2019-4-9_0-24-22.png

    While connected to my guest network with an IP like 172.16.0.x, I still wasn't able to access 192.168.0.253 (no firewall rule yet, testing one thing at a time).
     
  9. Sean B.

    Sean B. Network Guru Member

    With that rule set, what is the output of

    Code:
    iptables -t filter --list-rules FORWARD
     
  10. Nazgulled

    Nazgulled Serious Server Member

    Code:
    -P FORWARD DROP
    -A FORWARD -i tun21 -j ACCEPT
    -A FORWARD -i br0 -o br0 -j ACCEPT
    -A FORWARD -i br1 -o br1 -j ACCEPT
    -A FORWARD -s 172.16.0.0/24 -d 192.168.0.253/32 -i br1 -o br0 -j ACCEPT
    -A FORWARD -m state --state INVALID -j DROP
    -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A FORWARD -i br0 -o br1 -j DROP
    -A FORWARD -i br1 -o br0 -j DROP
    -A FORWARD -i vlan100 -j wanin
    -A FORWARD -o vlan100 -j wanout
    -A FORWARD -i br0 -j ACCEPT
    -A FORWARD -i br1 -j ACCEPT
    -A FORWARD -i vlan100 -j upnp
    Sent from my HTC 10 using Tapatalk
     
  11. Sean B.

    Sean B. Network Guru Member

    The rule is placed and formatted correctly by the GUI. Are the IP's you used for the rule from the same subnet as the br0 and br1 interfaces are configured under Basic->Network? And are both clients directly connected to their respective interfaces? IE: If one of those are on the other end of a VPN the LAN access page does not apply, as its rules are applied to the local LAN interfaces only.
     
    Last edited: Apr 9, 2019
  12. Nazgulled

    Nazgulled Serious Server Member

    I believe so, here are a few more screenshots:

    upload_2019-4-9_8-12-4.png

    upload_2019-4-9_8-12-22.png

    upload_2019-4-9_8-16-16.png

    upload_2019-4-9_8-14-35.png
    upload_2019-4-9_8-14-52.png

    The NAZTEN device is my phone connected to my guest Wi-Fi network named Supernova.Guest. There are no VPN tunnels between these devices.

    Don't I still need a route configuration somewhere for all this to work properly?
     
    Last edited: Apr 9, 2019
  13. Sean B.

    Sean B. Network Guru Member

    No, you don't need a route for the interfaces on the router itself. You're using a virtual wireless interface, this may have something to do with it. Try this:

    Code:
    iptables -t filter -I FORWARD 1 -i wl0.1 -p udp -d 192.168.0.253 -j ACCEPT
    and see if DNS queries work.
     
  14. Nazgulled

    Nazgulled Serious Server Member

    I'm confused... The access I'm trying to do is between clients, I think. I mean, 172.16.0.229 is my Android phone (a client) that I need to be able to access 192.168.0.253 the DNS server (another client). Both are clients. Where does the router fit in this?
     
  15. Sean B.

    Sean B. Network Guru Member

    It's early, I read that wrong. I edited the post.
     
  16. Sean B.

    Sean B. Network Guru Member

    Also, is "AP isolation" enabled under Advanced->Wireless?
     
  17. Nazgulled

    Nazgulled Serious Server Member

    It's disabled.
     
  18. Nazgulled

    Nazgulled Serious Server Member

    I'm sorry but the first configuration suggested first by @lancethepants was actually working, my problem was something else.

    For testing purposes I was actually trying to access the admin interface (on port 3000) with an hostname I manually specified in my dnsmasq configuration. The problem was that this hostname was configured to point to another machine (192.168.0.99) which acted as a reverse proxy. But I was only giving access to the .253 address, not the .99 one, so of course it wasn't working.

    This was really dumb of me and I apologize for the confusion. Pinging the IP directly was working and I also used an Android tool that scanned open ports on 192.168.0.253 IP while connected to the guest network and it successfully stated that both port 3000 and 53 were open, as expected.

    Anyway, the LAN Access rule worked, which adds the following to iptables:

    Code:
    -A FORWARD -s 172.16.0.0/24 -d 192.168.0.253/32 -i br1 -o br0 -j ACCEPT
    I also tried to add this (as you mentioned above @Sean B.):

    Code:
    -A FORWARD -d 192.168.0.253/32 -i br1 -o br0 -p udp -m udp --dport 53 -j ACCEPT
    But I don't think this worked, scanning for open ports on 192.168.0.253 still returned port 3000 as opened (the web interface).

    What I'm trying to do is, anyone accessing from 172.16.0.0/24 should only be allowed to access 192.168.0.253:53. In other words, no IP on the 192.168.0.0/24 subnet other than the one ending on .253 and no other port other than 53 should be allowed access from 172.16.0.0/24 client.
     
    Last edited: Apr 9, 2019
  19. Sean B.

    Sean B. Network Guru Member

    Did your port scan use tcp or udp? The rule I stated is correct. And if entered as I stated ( -I FORWARD 1 ) should be working. It must be above the other rules. Considering port 3000 showed open, there are other rules ( such as the LAN access one ) in place. And 3000 is likely tcp, implying the scan was not using udp.
     
  20. Nazgulled

    Nazgulled Serious Server Member

    Yes, the scan is using UDP. But I want all ports (except 53) to be denied access both for TCP/UDP. Since this is a DNS server, only port 53 for UDP should be allowed. I don't know if it makes sense but I also added the same rule for TCP so in the end I ended up with this:

    Code:
    root@AC68U:/tmp/home/root# iptables -t filter --list-rules FORWARD-P FORWARD DROP
    -A FORWARD -d 192.168.0.253/32 -i br1 -o br0 -p tcp -m tcp --dport 53 -j ACCEPT # Manually added
    -A FORWARD -d 192.168.0.253/32 -i br1 -o br0 -p udp -m udp --dport 53 -j ACCEPT # Manually added
    -A FORWARD -i tun21 -j ACCEPT
    -A FORWARD -i br0 -o br0 -j ACCEPT
    -A FORWARD -i br1 -o br1 -j ACCEPT
    -A FORWARD -s 172.16.0.0/24 -d 192.168.0.253/32 -i br1 -o br0 -j ACCEPT # Added by LAN Access
    -A FORWARD -m state --state INVALID -j DROP
    -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A FORWARD -i br0 -o br1 -j DROP
    -A FORWARD -i br1 -o br0 -j DROP
    -A FORWARD -i vlan100 -j wanin
    -A FORWARD -o vlan100 -j wanout
    -A FORWARD -i br0 -j ACCEPT
    -A FORWARD -i br1 -j ACCEPT
    -A FORWARD -i vlan100 -j upnp
    
    But it didn't work, the port scanner still reports 3000 and 53 as both opened in TCP and I want them both blocked (just UDP 53 should be opened). Is this possible?

    First, I've been reading iptables syntax and what all this means and I don't understand how all these rules are blocking every port except 53, shouldn't there be a DENY/DROP/REJECT somewhere or something?
     
  21. Nazgulled

    Nazgulled Serious Server Member

    Actually, after thinking a bit about all that you said, I removed the entry from the LAN Access section and simply added this line to the "Firewall" scripts section:

    Code:
    iptables -t filter -I FORWARD 1 -i br1 -s 172.16.0.0/24 -o br0 -d 192.168.0.253/32 -p udp --dport 53 -j ACCEPT
    This will make sure that when:
    • Source LAN is the guest network (br1)
    • Source IP is from the 172.16.0.0/24 subnet
    • Destination LAN is the main network (br0)
    • Destination IP is exactly 192.168.0.253
    • Protocol is UDP
    • Port being accessed is 53
    Accept the connection, otherwise, check the other rules below which will DENY access for any other type of connection from the guest network to the main network.

    Does this look good?
     
  22. Sean B.

    Sean B. Network Guru Member

    Yes, that's what I said. The LAN access rule in the GUI was allowing access to all ports. That rule is the same as what I told you, except the addition of -s 172.16.0.0/24 , which is redundant because the -i br1 flag means incoming from br1.. and br1's subnet is 172.16.0.0/24.

    If you prefer IP's rather than interfaces to be used in the rules, this will do the same thing:

    Code:
    iptables -t filter -I FORWARD 1 -p udp -s 172.16.0.0/24 -d 192.168.0.253 --dport 53 -j ACCEPT
     
    Nazgulled likes this.
  23. Nazgulled

    Nazgulled Serious Server Member

    Yep, that's it.

    Thank you once again for everything :)
     
    Sean B. likes this.
  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