Business Community > General Discussion > Simple rule-based firewall into Omada SDN Controller
< General Discussion

Simple rule-based firewall into Omada SDN Controller

Simple rule-based firewall into Omada SDN Controller

Simple rule-based firewall into Omada SDN Controller
Simple rule-based firewall into Omada SDN Controller
2025-06-11 23:31:50 - last edited 2025-06-12 02:52:59
Model: ER605 (TL-R605)   EAP225   TL-SG2218  
Hardware Version:
Firmware Version:

First of all, I’ve always been an SDN enthusiast, and my university graduation project was about SDNs (using Mininet, OpenDayLight, OpenFlow, GNS3). So I understand how an SDN works under the hood, academically speaking, and that was one of the reasons I decided to make my home network an SDN. After evaluating the best platforms in terms of cost-effectiveness, I naturally ended up choosing TP-Link's solution—mainly due to its availability in my country.

 

My topology is quite simple:

 

  1. Gateway: ER605 v2.0 (2.0.1 Build 20220223 Rel.68551)
  2. Switch: TL-SG2218 v1.0 (1.1.4 Build 20220707 Rel.55528)
  3. 2x EAPs: EAP225(US) v3.0 (5.0.9 Build 20220429 Rel. 43558)

 

My Omada SDN Controller is running on a Raspberry Pi (RPi), containerized (Docker), on version 5.15.8.2. There are no pending firmware updates and everything works very well.

 

Lately, I started having some concerns regarding privacy and security, which led me to mirror all the traffic on the port connecting the switch to the router and analyze it using NTOP-NG. From this analysis, I discovered that my soundbar, even in standby mode, kept sending packets to servers in strange locations, with unusual payloads, and on a constant basis. My natural reaction to this was to create a firewall rule to block any outbound traffic from the IP of that device, dropping it internally before it could exit—either at the EAP, switch, or router within the SDN network.

 

For months, I tried everything possible within the Omada Platform to create a simple “DROP” rule for this device, but nothing worked (the traffic was still detected by NTOP-NG).

In a drastic move, I decided to place a Sophos XGS135 between my switch and router, in “bridge” mode (with the DHCP server disabled), just to inspect the source/destination of the packets and drop them using Sophos XGS's excellent rule-based firewall interface.

 

The problem is that, for some reason I haven’t yet identified, after a few minutes all the devices in my network behind the switch lose the ability to renew their DHCP lease and become unreachable. Strangely, in the SDN controller, the status of the ER605 appears as “disconnected,” even though it responds to ICMP (ping) from any device that still has a valid IP lease.

 

I tried enabling DHCP Relay (L2) and added the IP of the Sophos XGS135 as an “authorized DHCP source” in the LAN settings, hoping this might work around a possible bug, but none of that worked.

 

It’s frustrating and disheartening that such an interesting solution like Omada doesn’t allow you to inject a simple IPTABLES rule to reroute traffic from devices. There’s no plugin or feature that lets you create a straightforward firewall rule for this purpose in the Omada solution.

 

Because of that, I kindly ask for your help: any suggestions to resolve this issue would be very welcome.

 

Thank you.

  1      
 
  1      
 
#1
Options
1 Accepted Solution
Re:Simple rule-based firewall into Omada SDN Controller-Solution
2025-06-12 02:52:46 - last edited 2025-06-12 02:52:59

  @brizzio 

Telemetry is a common practice for any network product nowadays. 

When you agree to the Terms of Use, you allow that action. 

If you want to block that, ACL does not seem to be the proper way. Consider the ad block stuff, which you can build in your local network to filter that.

Omada does not adjust or modify the DNS resolution. So there is no option to do it on the Omada gears. 

 

On how to use two routers, one for the Internet and another one for policy-based filtering or routing, that's not a solution we should provide. 

I am aware of such a setup, which is commonly found in some countries. But this is not what we are supposed to offer help or support. It is not a traditional setup and is beyond our support. 

 

This setup commonly uses the routing function. DHCP should not be affected as you turned off DHCP on the secondary router. One serves the DHCP(pointing the GW to secondary IP) and gateway for the Internet, and another one is used for policy stuff and its GW is directed and routed to the primary one. 

About the details for that, you can look it up online, as mentioned, it is beyond our support. 

Recommended Solution
  2  
  2  
#3
Options
3 Reply
Re:Simple rule-based firewall into Omada SDN Controller
2025-06-12 02:37:47
I support this request too. The Omada product range and its controller is fantastic. The one down side is the lack of good firewall functionality. I know there are ACLs, but they are not very effective, and its confusing as to where its a switch ACL or a gateway ACL. Having a more robust Firewall feature set on the gateways would be fantastic. Even if the gateway is $1000+, I would purchase this for business clients.
  0  
  0  
#2
Options
Re:Simple rule-based firewall into Omada SDN Controller-Solution
2025-06-12 02:52:46 - last edited 2025-06-12 02:52:59

  @brizzio 

Telemetry is a common practice for any network product nowadays. 

When you agree to the Terms of Use, you allow that action. 

If you want to block that, ACL does not seem to be the proper way. Consider the ad block stuff, which you can build in your local network to filter that.

Omada does not adjust or modify the DNS resolution. So there is no option to do it on the Omada gears. 

 

On how to use two routers, one for the Internet and another one for policy-based filtering or routing, that's not a solution we should provide. 

I am aware of such a setup, which is commonly found in some countries. But this is not what we are supposed to offer help or support. It is not a traditional setup and is beyond our support. 

 

This setup commonly uses the routing function. DHCP should not be affected as you turned off DHCP on the secondary router. One serves the DHCP(pointing the GW to secondary IP) and gateway for the Internet, and another one is used for policy stuff and its GW is directed and routed to the primary one. 

About the details for that, you can look it up online, as mentioned, it is beyond our support. 

Recommended Solution
  2  
  2  
#3
Options
Re:Simple rule-based firewall into Omada SDN Controller
2025-06-12 10:36:19

Hello  @Clive_A ! Thanks a lot for your reply. Allow me to answer some things you raised on your answer: 

 

"Telemetry is a common practice for any network product nowadays. 

When you agree to the Terms of Use, you allow that action. 

If you want to block that, ACL does not seem to be the proper way. Consider the ad block stuff, which you can build in your local network to filter that.

Omada does not adjust or modify the DNS resolution. So there is no option to do it on the Omada gears."

 

The same Raspberry Pi I use to host the SDN Controller also runs a Pi-hole instance blocking over 6,750,000 domains. The issue here isn’t about telemetry (especially because telemetry is, according to common sense, something that happens while your device is in use—not in a dormant state). In this case, Pi-hole isn’t effective because the communication happens directly with an IP address, not a FQDN... and in such a scenario, only an explicit firewall rule could address my concern.
 

 

"On how to use two routers, one for the Internet and another one for policy-based filtering or routing, that's not a solution we should provide. 

I am aware of such a setup, which is commonly found in some countries. But this is not what we are supposed to offer help or support. It is not a traditional setup and is beyond our support. "

 

I understand the guideline and your response, so I’d like to take this opportunity to ask how to submit a feature request—since the demand for a rule-based firewall module is clear and widely expressed by the majority of Omada platform users. The current ACL system is overly confusing, too restrictive, and highly inefficient, as can be seen in most posts related to security within TP-Link’s solution.

 

I would really like to see a solution provided for this issue from the TP-Link's Product Team, rather than having to take a more drastic step and decommission the SDN model entirely due to the absence of a basic functionality—one that anyone can easily achieve using a generic router in a traditional, non-SDN network topology.

 

Thanks again for your attention, suggestions, and answer.

  0  
  0  
#4
Options

Information

Helpful: 1

Views: 549

Replies: 3

About Us
Press
Copyright © TP-Link Systems Inc. All rights reserved.