Impossible to block traffic to port 53/UDP on guest network

Impossible to block traffic to port 53/UDP on guest network
Impossible to block traffic to port 53/UDP on guest network
Thursday - last edited Thursday
Model: EAP245
Hardware Version: V3
Firmware Version: 2.3.1 Build 20191029 Rel. 61589

Both 'Guest Network' and 'Access Control' allow clients to communicate with any host on port 53/UDP when traffic to said host should be blocked. I believe this to be a bug. I am using Omada Controller v3.2.6.

 

Can anyone confirm what I am seeing?

0
0
#1
Options
9 Replies
Re:Impossible to block traffic to port 53/UDP on guest network
Thursday

@XelNika, I can confirm this at least for hosts in the wired network, did not test with wireless hosts so far.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
0
0
#2
Options
Re:Impossible to block traffic to port 53/UDP on guest network
Thursday

@R1D2 Admittedly I had only tested from a wireless client to a wired one. I'm no networking expert, but I tried listening on port 53/UDP with netcat and tcpdump on one wireless client and sending packets from a different wireless client and I did not see anything get through so this issue might only apply for traffic from wireless to wired hosts.

0
0
#3
Options
Re:Impossible to block traffic to port 53/UDP on guest network
Friday

@XelNika 

 

Both 'Guest Network' and 'Access Control' allow clients to communicate with any host on port 53/UDP when traffic to said host should be blocked.

Port 53 is used by DNS, if this is blocked, some features based on DNS cannot work normally. 

 

0
0
#4
Options
Re:Impossible to block traffic to port 53/UDP on guest network
Friday

@forrest Which features exactly? First of all, DNS also uses 53/TCP which is blocked. Second, there should be no need for DNS to connect to an AP.

0
0
#5
Options
Re:Impossible to block traffic to port 53/UDP on guest network
Friday - last edited Friday

 

XelNika wrote

@forrest Which features exactly? First of all, DNS also uses 53/TCP which is blocked. Second, there should be no need for DNS to connect to an AP.

 

In my opinion ACLs and the Guest Network setting have been added to Omada controller because home users demanded this functionality to easily create a guest network for friends visiting them. In a home environment, most users don't have sophisticated network setups with firewalls and VLANs and most often use only one network for both, the guest network and the private network. So, with the ACLs the controller got a subset of firewalling features needed to deploy a simple guest network with just a single click.

 

In business environments a guest network for public hotspots must be strictly isolated from the company network. Such business-class hotspots use a security gateway, different networks, VLANs and a full-fledged firewall. ACLs and the Guest Network setting in the controller are just not sufficient in such environments.

 

For example, to implement certain features required by law in our country for public hotspots we even need to block any DNS request to any server except the one running on the hotspot's security gateway which we have developed for the purpose to comply with the law. But home users are not required to make such great efforts to comply with the law.

 

To summarize:

  • In my opinion the Omada Guest Network is sufficient for home users who demanded an easy way to create a guest network.
    They asked for it, they finally got it.
  • For a business-class guest network you wouldn't use ACLs in the controller, rather you would deploy an own network for guests only.

 

 

My point is:

If Guest Network or ACL settings would block traffic to DNS servers, home users would start complaining again.
What's more, ACLs would need to allow more features such as port-based rules as implemented in switches.

 

Thus, I suggest to use either a managed switch with full ACL functionality offering IP/MAC/port-based rules or even a full-fledged firewall and a separate network for WiFi clients only if strict isolation of the guest network is needed.

 

What could make sense would be a restriction to only allow DNS requests to the gateway, but then this would break setups of those home users who use a separate DNS server (such as PiHole on a RasPi).

 

It's not that easy to fulfill the whishes of home users and business users in an AP controller alone.

 

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
0
0
#6
Options
Re:Impossible to block traffic to port 53/UDP on guest network
Friday - last edited Friday

R1D2 wrote

My point is:

If Guest Network or ACL settings would block traffic to DNS servers, home users would start complaining again.
What's more, ACLs would need to allow more features such as port-based rules as implemented in switches.

 

 

If this is TP-Link's reasoning (i.e. allow users access to their local DNS servers) then we have a different bug. The DNS protocol is not limited to UDP, port 53/TCP is used as a fallback in a few scenarios, including when DNS responses exceed a certain size. I have tested and verified that large DNS queries fail on the TP-Link guest network unless allowed via ACL.

 

From RFC 5966:

 

 

In the absence of EDNS0 (Extension Mechanisms for DNS 0) (see below),
   the normal behaviour of any DNS server needing to send a UDP response
   that would exceed the 512-byte limit is for the server to truncate
   the response so that it fits within that limit and then set the TC
   flag in the response header.  When the client receives such a
   response, it takes the TC flag as an indication that it should retry
   over TCP instead.

 

That is why I ask what features of the access point require port 53/UDP, because this would be a bug in the other direction (blocking too much rather than not enough).

 

EDIT: I also dislike the lack of transparency on this. Neither the tooltip nor the user guide make any mention of this particular hole. Now, it's no surprise that some local traffic like DHCP is still available, but local DNS definitely is not a requirement for basic AP connectivity and it should have been mentioned somewhere. I stumbled across this particular port by chance, but for all I know, these features have as many holes as Swiss cheese.

0
0
#7
Options
Re:Impossible to block traffic to port 53/UDP on guest network
Friday - last edited Friday

 

XelNika wrote

If this is TP-Link's reasoning (i.e. allow users access to their local DNS servers) then we have a different bug. The DNS protocol is not limited to UDP, port 53/TCP is used as a fallback in a few scenarios, including when DNS responses exceed a certain size. I have tested and verified that large DNS queries fail on the TP-Link guest network unless allowed via ACL.

 

 I'm not from TP-Link, but just wrote my opinion about the history of this »Guest Network« setting in place since controller version 3.1.4.

 

With larger DNS queries you mean zone transfers etc.?

 

Anyway, in my personal opinion policies like implementing a »single-click guest network« on an AP (with ACLs set in every EAP instead of centralizing it in a switch or a firewall!) is not the right way to do, but lots of home users here disagree with me.

 

In my opinion EAPs should implement just functions, but not policies.

 

Strict separation of functions and policies is one of the main principles in the UNIX world, which made this software (including Linux, BSD Unix, FreeBSD, MacOS) so successful in last 50 years and which was (and still is) the main force behind what we call the Internet.

 

OTOH, I can even accept policies one can choose from if one has the freedom to not use it. I don't care much about this as long as I'm not forced to use it. So, my concern and feature request to TP-Link is just to re-introduce the »Client Isolation« setting, which can co-exist with this kind of guest network setting for other users needing it.

 

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
0
0
#8
Options
Re:Impossible to block traffic to port 53/UDP on guest network
Friday - last edited Friday

 

R1D2 wrote

 I'm not from TP-Link, but just wrote my opinion about the history of this »Guest Network« setting in place since controller version 3.1.4.

 

I understand you're not affiliated with TP-Link, I am just speaking hypothetically while I wait for an official response.

 

R1D2 wrote

With larger DNS queries you mean zone transfers etc.?

 

I literally mean a large DNS response. That could be an ANY query or simply a regular query for a domain with a lot of A records. These large responses fail on my TP-Link guest network. Don't get me wrong, it's not usually an issue, I specifically looked for problematic domains when testing it.

 

I am with you on the client isolation/ACL subject, but if TP-Link is going to do it wrong, they should at least do so correctly :P

0
0
#9
Options
Re:Impossible to block traffic to port 53/UDP on guest network
Friday - last edited Saturday

 

XelNika wrote 

I am with you on the client isolation/ACL subject, but if TP-Link is going to do it wrong, they should at least do so correctly :P

 

The wrong-doing is to implement certain policies. 

 

Needing zone transfers or other large DNS queries is also a policy and I agree with you that you should be able to request those queries, too.

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
0
0
#10
Options