Impossible to block traffic to port 53/UDP on guest network
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?
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
@XelNika, I can confirm this at least for hosts in the wired network, did not test with wireless hosts so far.
- Copy Link
- Report Inappropriate Content
@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.
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
@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.
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
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
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 2784
Replies: 9
Voters 0
No one has voted for it yet.