Blocking communication between subnets

@psherman I always have clients, I can't reset my router to defaults and set it up again. But I am setting up another router to possibly replace this one, I can experiment with this one.
@trendy thanks for the hint! I will check.

Now I tested various things. I borrowed win8.1 and installed angry IP. It doesn't show anything like my laptop (macbook pro 2012) does, when it's on 3.1/24: it doesn't see anything it's not supposed to see according to my intention. So tcpdump doesn't give any output either. But angry IP site says that it works differently with each computer, depending on privilege level. I guess it's "stronger" on my laptop.

So I put my laptop on 3.1/24 (eth0.15), samsung 1.1/24 (eth0.16), and used putty on win8.1 to check tcpdump on the router.

root@OpenWrt:~# tcpdump -i eth0.15 -n host 192.168.1.220 and host 192.168.3.205
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.15, link-type EN10MB (Ethernet), capture size 262144 bytes
10:38:00.885244 IP 192.168.3.205.61640 > 192.168.1.220.7: Flags [S], seq 3606877515, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 764036204 ecr 0,sackOK,eol], length 0
10:38:00.885329 IP 192.168.1.220.7 > 192.168.3.205.61640: Flags [R.], seq 0, ack 3606877516, win 0, length 0

Repeat (with a bit different numbers), then in the end

12 packets captured
12 packets received by filter
0 packets dropped by kernel

Then

root@OpenWrt:~# tcpdump -i eth0.16 -n host 192.168.1.220 and 192.168.3.205
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.16, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
1 packet received by filter
0 packets dropped by kernel

I'm not sure what this "one packet" is....

But so it's looks like my macbook can do something that goes through firewall. What is it doing ? I would appreciate your explanation!

On the other hand, I did the same test on the other router I am setting up as a replacement. The result of Angry IP is the same (i.e. my laptop sees things I don't want it to see, and win8.1 doesn't.) , but on this router, tcpdump doesn't return anything....

From the manual:

When tcpdump finishes capturing packets, it will report counts of:

packets ``captured'' (this is the number of packets that tcpdump has received and processed); 
packets ``received by filter'' (the meaning of this depends on the OS on which you're running tcpdump, and possibly on the way the OS was configured - if a filter was specified on the command line, on some OSes it counts packets regardless of whether they were matched by the filter expression and, even if they were matched by the filter expression, regardless of whether tcpdump has read and processed them yet, on other OSes it counts only packets that were matched by the filter expression regardless of whether tcpdump has read and processed them yet, and on other OSes it counts only packets that were matched by the filter expression and were processed by tcpdump); 
packets ``dropped by kernel'' (this is the number of packets that were dropped, due to a lack of buffer space, by the packet capture mechanism in the OS on which tcpdump is running, if the OS reports that information to applications; if not, it will be reported as 0). 

I think the witch hunt can stop now. Firewall is working as intended and AngryIP is reporting controversial stuff.

@trendy OK, so actually there is no witch, which I should be hunting as a router-manager. As a matter of fact, I don't have any reason to suspect any of my users to be doing weird things, there is no actual danger. Bad people can do anything and I can't stop them, so basically I have done my job if I set the forwarding zones of 2.1/24 and 3.1/24 to be just wan, and it was indeed properly done.

I am still a bit interested in knowing the difference between setting forwarding to wan alone, and dropping the forwarding to certain subnets explicitly using traffic rules: because the latter did stop my angry IP. But in practice, it doesn't have to be there for normal purpose.

So, now I am happy:) I think I should get a weaker IP scanner (or set angry to do something weaker) to check what's normal.

Thanks a lot, all, for all your help!!

Since there is only one dnsmasq process, that DNS server will do reverse lookups for all the leases that it has issued on any network in the router. This does not depend on access to the actual other network at all. It is a DNS request on the user's native network.

@mk24 Oooh, indeed, it says so: https://angryip.org/faq/hostnames
I don't know why it shows that on my mac and not on win8.1, though...

@trendy I read the explanation on tcpdump reports again, so "filter" is firewall (netfilter), and it is saying that all the packages that wanted to pass did get caught by the firewall, so it's all working fine. Did I understand it right?

No, the filter is the expression in the tcpdump line to select specific packets.

o, OK. Then I actually don't understand why you could conclude from the output that firewall is working as intended.....
And I also don't understand why additional traffic rules to drop forwarding to 192.168.0.0/16 does stop angry IP on my mac from getting any information (incl. hostnames), if the general forwarding just to wan is supposed to be doing the same thing....

I conclude it because there are no packets shown in the output interface.

It's the difference between the default REJECT policy and the DROP you applied on your custom rule.

I changed "reject" to "drop" in the general rule to see what happens, the outcome is the same.... I still see the hostnames....

Seeing the hostnames has nothing to do with forwarding between networks. dnsmasq will report hostnames that exist on other networks without concern for whether those networks are reachable or not.

If you firewall DNS requests entirely, then of course you won't see any hostnames, unless they are still in the client's cache from previous attempts.

2 Likes

DNS is allowed for 3.1/24 and 2.1/24: TCP and UDP 53, and my blocking .0.0/16 doesn't seem to override it (because it's also for "zones", not for "device", if I understood it right. Or otherwise, since "allow" rule is before the drop to .0.0/16.)

You need to block input from any zones and/or addresses/networks that should not have access to the DNS served by the OpenWrt router. You currently are only blocking that 192.168.0.0/16 as a destination. Even though the router does have addresses on these networks, you have to think of this from the perspective of the firewall...

  • source is obviously where a packet originates
  • destination is obviously the place where a packet is destined to go that is external to the router/firewall itself... but that doesn't include router/firewall itself.
  • input is when the destination is the router/firewall

Yeah, I mean, I thought I shouldn't be doing it, because otherwise the users cannot use the internet, right? I do need to allow UDP and TCP 53 for device input, right?

But for some reason, if I put "drop" forwarding to .0.0/16 in the traffic rules, then the hostnames do not show up anymore on Angry IP.

You could block port 53 then use a DHCP option to direct users to an external DNS service. Performance might be slightly reduced since DNS won't be locally cached on the router, (though most clients maintain their own cache.)

Obscurity doesn't really increase any security.

Do you mean "DNS forwardings" under DHCP and DNS > General Settings?
I always had things like 8.8.8.8 there. I had thought that DNS servers are always external: if I hadn't put 8.8.8.8 etc, it would be forwarded to the DNS server of the ISP.....

Or, are you talking about something else ?

If you specify option 6 in the dhcp server settings, you can advertise the addresses of preferred dns servers. So if you want to point those clients to google (8.8.8.8) or cloud flare (1.1.1.1), you can send those addresses for the clients to use.

It looks like your "option 6" and my "DNS forwardings" are the same thing. So I should then remove "allow" for TCP+UDP 53, since I already have 8.8.8.8 etc on this entry, the clients should be able to use internet normally, while not being able to look up the hostnames on the networks on OpenWRT (i.e. DNS for local domain names is not available, while DNS for looking up the domain names outside is taken care of). Did I understand it correctly ?

Right, if you advertise an external DNS with option 6, the endpoints on the LAN will go directly outside for their DNS. They're not using the router DNS service at all, so you can firewall it by blocking port 53. This means that no local domains can be looked up.

DNS forwarding is the usual case where the LAN clients use the router for DNS. When the dnsmasq process in the router is asked for a name outside its domain, it forwards to the external server which is configured in the router. The reply is then forwarded back to the client. It is also cached in the router so the next request for the same name does not require an external lookup.

I am still not super clear about how DNS forwarding works: because, if don't specify any extra outside DNS server like 8888 in the router, then the DNS server from the ISP will be automatically used. This would mean that DNS forwarding takes place independent of whether I put something on option 6 ? And in order for this to happen, TCP+UDP 53 should be open, right?

So, if TCP+UDP 53 is open, DNS query will go to the dnsmasq of the router, and it decides the domain is outside, if so, then it will check if external DNS server is specified, and if not, it will send it to the DNS server of the ISP.
If TCP+UDP 53 is closed, DNS query will be send to an external DNS server if and only if external DNS is specified with option 6. It will process an external domain, but then internal domain will be thrown away. And Angry IP cannot look up the hostnames using IP addresses because the port is closed.

Is this right?

But, for DHCP, UDP 67 should be still open in order to get an IP address, right?

Thanks a lot for your patience!!