Understanding iptables trying to implement guest network

Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking
Author Message
johnfh
DD-WRT Novice


Joined: 09 Feb 2018
Posts: 15

PostPosted: Mon Feb 12, 2018 0:00    Post subject: Understanding iptables trying to implement guest network Reply with quote
I'm trying to implement a guest network to provide both physical LAN ports and a wifi network for guests. For the LAN ports, I've created a VLAN (tag 10) and for the wifi network I've created a virtual access point on 2.4GHz. I've created a bridge (called br1) between them so that all guest clients share one DHCP server. The DHCP server on the guest bridge seems to be working perfectly (as is the VLAN setup I believe), providing IP addresses to both LAN and wifi clients. The problem I have however is in locking down the clients so that they a) can't talk to each other and b) cannot talk to the router or other LAN clients except for DNS and DHCP queries. I've put the guest bridge on a separate subnet, enabled masquerade/NAT (because I want guests to access the internet), and enabled net isolation. However from a wifi client I can still ping the router.

I've listed below the relevant iptables rules and, in particular, rule 8 is defined above all other guest bridge (br1) rules which seems very odd. I've confirmed that if I delete that specific rule then my wifi client cannot ping the router and it can still access the internet. Where is this rule coming from though? It does look wrong though especially since the same rule appears much further down at number 26.
Obviously deleting it manually doesn't survive a reboot so I have no good solution at the moment. In the listing below, br1 is the guest bridge, bridging ath1.1 and eth1.10.

Code:
root@DD-WRT:~# iptables -nv -L INPUT --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      318 37831 ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
2        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:1194
3        0     0 ACCEPT     0    --  tun2   *       0.0.0.0/0            0.0.0.0/0
4        0     0 logdrop    udp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0           udp dpt:520
5        0     0 logdrop    udp  --  br0    *       0.0.0.0/0            0.0.0.0/0           udp dpt:520
6        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:520
7       51  3467 ACCEPT     0    --  br0    *       0.0.0.0/0            0.0.0.0/0
8       28  9232 ACCEPT     0    --  br1    *       0.0.0.0/0            0.0.0.0/0
9        0     0 ACCEPT     icmp --  ppp0   *       0.0.0.0/0            0.0.0.0/0
10       2    72 logdrop    2    --  *      *       0.0.0.0/0            0.0.0.0/0
11       5   352 ACCEPT     0    --  lo     *       0.0.0.0/0            0.0.0.0/0           state NEW
12       0     0 ACCEPT     0    --  br0    *       0.0.0.0/0            0.0.0.0/0           state NEW
13       0     0 ACCEPT     udp  --  eth1.10 *       0.0.0.0/0            0.0.0.0/0           udp dpt:67
14       0     0 ACCEPT     udp  --  eth1.10 *       0.0.0.0/0            0.0.0.0/0           udp dpt:53
15       0     0 ACCEPT     tcp  --  eth1.10 *       0.0.0.0/0            0.0.0.0/0           tcp dpt:53
16       0     0 logdrop    0    --  eth1.10 *       0.0.0.0/0            0.0.0.0/0           state NEW
17       0     0 ACCEPT     0    --  eth1.7 *       0.0.0.0/0            0.0.0.0/0
18       0     0 ACCEPT     udp  --  ath1.1 *       0.0.0.0/0            0.0.0.0/0           udp dpt:67
19       0     0 ACCEPT     udp  --  ath1.1 *       0.0.0.0/0            0.0.0.0/0           udp dpt:53
20       0     0 ACCEPT     tcp  --  ath1.1 *       0.0.0.0/0            0.0.0.0/0           tcp dpt:53
21       0     0 logdrop    0    --  ath1.1 *       0.0.0.0/0            0.0.0.0/0           state NEW
22       0     0 ACCEPT     udp  --  br1    *       0.0.0.0/0            0.0.0.0/0           udp dpt:67
23       0     0 ACCEPT     udp  --  br1    *       0.0.0.0/0            0.0.0.0/0           udp dpt:53
24       0     0 ACCEPT     tcp  --  br1    *       0.0.0.0/0            0.0.0.0/0           tcp dpt:53
25       0     0 logdrop    0    --  br1    *       0.0.0.0/0            0.0.0.0/0           state NEW
26       0     0 ACCEPT     0    --  br1    *       0.0.0.0/0            0.0.0.0/0
27      58  5196 logdrop    0    --  *      *       0.0.0.0/0            0.0.0.0/0
Sponsor
johnfh
DD-WRT Novice


Joined: 09 Feb 2018
Posts: 15

PostPosted: Mon Feb 12, 2018 6:47    Post subject: Reply with quote
Yes but that doesn't explain where line 8 of my iptables rules comes from. Taking that line out solves everything but I can't just do that. I'm wondering if that's a bug because that rule prevents net isolation from working and it serves no purpose at all anyway.
johnfh
DD-WRT Novice


Joined: 09 Feb 2018
Posts: 15

PostPosted: Mon Feb 12, 2018 8:24    Post subject: Reply with quote
I didn't insert any of these rules myself though. These were all created after configuring the guest bridge on the DD-WRT GUI. That's why I think it must be a bug. I rebooted the router, then accessed the router via SSH to print the iptables rules but I did not enter any of them myself (well, apart from a couple involving tun2 which is for the VPN but that doesn't affect the guest bridge). That's why I'm asking where rule 8 came from because ideally I want to undo whatever GUI configuration caused it although I suspect it's a bug rather than any configuration option.

Thanks for your script, that's really helpful. How should I use it though? Should I disable net isolation, etc. in the GUI and then just call your script from startup to avoid unnecessary proliferation of needless iptables rules?
johnfh
DD-WRT Novice


Joined: 09 Feb 2018
Posts: 15

PostPosted: Mon Feb 12, 2018 20:29    Post subject: Reply with quote
I have a problem with using the script in that it precedes the port forwarding rules that I've setup. The consequence is that any guests cannot access my public website because the port forwarding rule isn't reached when connected to my guest network. Any ideas how to solve that?
johnfh
DD-WRT Novice


Joined: 09 Feb 2018
Posts: 15

PostPosted: Mon Feb 12, 2018 20:48    Post subject: Reply with quote
No just to my web server on my LAN. The rules denying access from guests to my LAN are before the general port forwarding rules that are configured in the GUI.
johnfh
DD-WRT Novice


Joined: 09 Feb 2018
Posts: 15

PostPosted: Mon Feb 12, 2018 21:09    Post subject: Reply with quote
I'm using the GUI to configure port forwarding apart from a few VPN rules on the 192.168.20.1 network which don't interfere with the guest network or my web server. If you look at the FORWARD chain you'll see the guest rules above the port forwarding rules that were setup in the GUI, specifically port 80 going to 192.168.1.10.

iptables -t nat -vnL PREROUTING:
Code:
Chain PREROUTING (policy ACCEPT 3738 packets, 671K bytes)
 pkts bytes target     prot opt in     out     source               destination
   81  5233 DNAT       udp  --  br1    *       0.0.0.0/0            0.0.0.0/0           udp dpt:53 to:8.8.8.8
    0     0 DNAT       tcp  --  br1    *       0.0.0.0/0            0.0.0.0/0           tcp dpt:53 to:8.8.8.8
    1    32 DNAT       icmp --  *      *       0.0.0.0/0            <WAN>       to:192.168.1.1
   10   540 DNAT       tcp  --  *      *       0.0.0.0/0            <WAN>       tcp dpt:22 to:192.168.1.30:5050
    7   420 DNAT       tcp  --  *      *       0.0.0.0/0            <WAN>       tcp dpt:80 to:192.168.1.10:80
    0     0 DNAT       tcp  --  *      *       0.0.0.0/0            <WAN>       tcp dpt:5010 to:192.168.1.30:5050
  135  8100 DNAT       tcp  --  *      *       0.0.0.0/0            <WAN>


iptables -vnL INPUT:
Code:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443
  154 54582 ACCEPT     udp  --  br1    *       0.0.0.0/0            0.0.0.0/0           udp dpt:67
    0     0 ACCEPT     udp  --  br1    *       0.0.0.0/0            0.0.0.0/0           udp dpt:53
    0     0 ACCEPT     tcp  --  br1    *       0.0.0.0/0            0.0.0.0/0           tcp dpt:53
    0     0 ACCEPT     icmp --  br1    *       0.0.0.0/0            0.0.0.0/0
    0     0 REJECT     tcp  --  br1    *       0.0.0.0/0            0.0.0.0/0           state NEW reject-with tcp-reset
    0     0 REJECT     0    --  br1    *       0.0.0.0/0            0.0.0.0/0           state NEW reject-with icmp-host-prohibited
 2804  357K ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:1194
    0     0 ACCEPT     0    --  tun2   *       0.0.0.0/0            0.0.0.0/0
    0     0 logdrop    udp  --  ppp0   *       0.0.0.0/0            0.0.0.0/0           udp dpt:520
    0     0 logdrop    udp  --  br0    *       0.0.0.0/0            0.0.0.0/0           udp dpt:520
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:520
 1353  184K ACCEPT     0    --  br0    *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  br1    *       0.0.0.0/0            0.0.0.0/0
    1    32 ACCEPT     icmp --  ppp0   *       0.0.0.0/0            0.0.0.0/0
   37  1332 logdrop    2    --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  lo     *       0.0.0.0/0            0.0.0.0/0           state NEW
    0     0 ACCEPT     0    --  br0    *       0.0.0.0/0            0.0.0.0/0           state NEW
    0     0 ACCEPT     0    --  br1    *       0.0.0.0/0            0.0.0.0/0
  109  7179 logdrop    0    --  *      *       0.0.0.0/0            0.0.0.0/0


iptables -vnL FORWARD:

Code:
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  *      *       192.168.20.0/24      0.0.0.0/0
    0     0 REJECT     tcp  --  br0    br1     0.0.0.0/0            0.0.0.0/0           state NEW reject-with tcp-reset
    0     0 REJECT     0    --  br0    br1     0.0.0.0/0            0.0.0.0/0           state NEW reject-with icmp-host-prohibited
    0     0 REJECT     tcp  --  br1    br0     0.0.0.0/0            0.0.0.0/0           state NEW reject-with tcp-reset
    0     0 REJECT     0    --  br1    br0     0.0.0.0/0            0.0.0.0/0           state NEW reject-with icmp-host-prohibited
 3300  198K ACCEPT     0    --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    0     0 ACCEPT     47   --  *      ppp0    192.168.1.0/24       0.0.0.0/0
    0     0 ACCEPT     tcp  --  *      ppp0    192.168.1.0/24       0.0.0.0/0           tcp dpt:1723
    0     0 ACCEPT     0    --  tun2   *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  *      tun2    0.0.0.0/0            0.0.0.0/0
  917 61283 lan2wan    0    --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 logreject  tcp  --  br0    ppp0    0.0.0.0/0            0.0.0.0/0           WEBSTR match content 7
  135  8100 ACCEPT     0    --  br0    br0     0.0.0.0/0            0.0.0.0/0
  666 45966 ACCEPT     0    --  br0    ppp0    0.0.0.0/0            0.0.0.0/0
  105  6621 ACCEPT     0    --  br1    ppp0    0.0.0.0/0            0.0.0.0/0
   11   596 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.30        tcp dpt:5050
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.10        tcp dpt:80
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.30        tcp dpt:5050
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            192.168.1.10        tcp dpt:443
    0     0 TRIGGER    0    --  ppp0   br0     0.0.0.0/0            0.0.0.0/0           TRIGGER type:in match:0 relate:0
    0     0 trigger_out  0    --  br0    *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     0    --  br0    *       0.0.0.0/0            0.0.0.0/0           state NEW
    0     0 logdrop    0    --  *      *       0.0.0.0/0            0.0.0.0/0

[/code]


Last edited by johnfh on Tue Feb 13, 2018 0:15; edited 1 time in total
johnfh
DD-WRT Novice


Joined: 09 Feb 2018
Posts: 15

PostPosted: Mon Feb 12, 2018 21:49    Post subject: Reply with quote
eibgrad wrote:
Looks to me like the following port forward isn't correct.

NAT table:

10 540 DNAT tcp -- * * 0.0.0.0/0 <WAN> tcp dpt:22 to:192.168.1.30:5050

FORWARD chain:

11 596 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.30 tcp dpt:5050

What that says if you used an external port of 22 (typically ssh) and mapped it to an internal IP (192.168.1.30) and port of 5050! Seems to me more likely the external and internal ports should be reversed.


That's exactly what it should do I'm afraid. I agree that on the face of it it does look weird but at one point I used non-standard SSH ports to mitigate the constant hack attacks from China but some time later I needed access to home from work and work blocked virtually all ports apart from a select few including the standard SSH port 22. So I needed a rule to forward the standard SSH 22 port to the local SSH port so I could ssh in from work.

When I try to access my public website from my guest network I can see the packet counter increase for the iptables guest rule going from br1 (guest) to br0 (internal LAN) despite the domain in the URL resolving to my external IP address.


Last edited by johnfh on Tue Feb 13, 2018 0:16; edited 1 time in total
johnfh
DD-WRT Novice


Joined: 09 Feb 2018
Posts: 15

PostPosted: Mon Feb 12, 2018 22:04    Post subject: Reply with quote
eibgrad wrote:
P.S. And as a side note, you mentioned a VPN and adding your own firewall rules for tun2. I assume that's the OpenVPN server on the router. If so, you don't need to be adding any rules!

https://www.dd-wrt.com/phpBB2/viewtopic.php?p=1117606

I'm not suggesting this is related to your current problems, but you have to be *very* careful mixing your own firewall rules (esp. when not necessary) w/ the GUI. One slip-up and things just don't work right.


That's a good side note, thanks. I had a brief look and a brief test and there is indeed a rule I don't need but I do need additional MASQUERADE rules so that my internet access goes over the VPN. It's not affecting any guest behaviour though.
johnfh
DD-WRT Novice


Joined: 09 Feb 2018
Posts: 15

PostPosted: Mon Feb 12, 2018 22:41    Post subject: Reply with quote
eibgrad wrote:


That sounds like NAT loopback, where you reference the public IP of the WAN for the port forward while inside the same network as the target. But NAT loopback has been broken several times over the year, and even w/ some recent builds. It not a reliable feature I'm afraid. I'm not even sure it will work w/ anything but the private network, even when it's working perfectly.

Whenever testing port forwards, do NOT rely on the results of NAT loopback to verify that it works. That's meaningless. That's nothing but a convenience so users can specify the same URL, whether at home or on the road. But that's no guarantee, for example, that a) NAT loopback is even working, and b) that you're ports might not be blocked by your ISP when you hit the road. Always test the port forwards from the WAN side of the router, whether that's via smartphone using the cellular network, a neighbor's wifi, etc.

I don't think you understand my problem. I already know the port forwarding works because I use it all the time, including today from outside my network. What I want though is for guests in my house, connected to my guest network, to be able to see my public website. If you're saying that's not going to work at all then I have to disagree because it's your forwarding rules that prevent it from working.

For example, as a guest going to my website:
br1 (guest) -> WAN port 80
this gets prerouted in the NAT table correctly to:
br1 (guest) -> internal IP port 80
BUT this matches exactly against your forwarding rule to deny access from guests to internal network and because this rule was inserted at the top it takes priority over the standard port forwarding rules on the FORWARD chain.
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum