Pre-Auth List issue with HTTPS domains on Omada Controller v5.15.20.16
Pre-Auth List issue with HTTPS domains on Omada Controller v5.15.20.16

Hi,
I'm facing a problem with the Pre-Authentication Access List on Omada SDN Controller (v5.15.20.16).
The whitelist works fine for some domains (e.g., btc2007[dot]com), but fails for others hosted behind certain CDN providers (like fedapay[dot]com).
What I did:
-
Whitelisted both domain names and IP addresses (using /32)
-
Added public DNS servers (8.8.8.8 and 1.1.1.1)
-
DNS resolution works
-
Access to btc2007[dot]com is successful before login
-
Access to fedapay-type domains is blocked or redirected to the captive portal
When testing with curl, I receive HTTP 530 errors. It seems the portal is not handling HTTPS requests correctly for some domains, maybe due to TLS/SNI or how Cloud-based protection works.
Looking for:
-
Confirmation if this is a known limitation or bug
-
A reliable method to allow such HTTPS domains in the Pre-Auth List
Thanks in advance!
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hi @fulgore
To understand the issue better, could you please give us the following info:
1. a screenshot of the portal config page;
2. a screenshot of the Pre-Authentication Access List;
3. some screenshots when failed to access fedapay[dot]com;
4. a screenshots of the device list so we can know what SDN devices you are using.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Hi @fulgore
Didy ou contact TP-Link support team? To get more details, Could you please give me the case ID?
- Copy Link
- Report Inappropriate Content
TKID250411305
- Copy Link
- Report Inappropriate Content
Issue is still present as of today on 5.15.24.19.
There are multiple, worrying issues to be honest, all tied to the walled garden capabilities - and these are business capabilities, not SOHO or EU.
I have a configuration where Omada and the MGMT interfaces are on VLAN 10, and my guest is on VLAN 20. I configured an external radius authentication through a web portal - works perfectly on a cable connected on the omada switch, but as soon as I get on the guest network I'll get initial DNS resolution (nslookup will show me the IP and fail traffic) and no splash page. Adding the actual IPs of the provider (purple.ai) as explained bu OP will show me the page, but Social login is 100% broken - if you are doing social authentication and you are supposed to call *.apple-pay-gateway.apple.com you are potentially addressing 17.0.0.0/8.
You could narrow it down correctly with the wildcard *.apple-pay-gateway.apple.com, but this can't be added as your controller only accepts IPs and URLs - how can this have been overlooked? Just from one client connecting I get about 60 different failed calls to external hosts because the walled garden DNS resolution is hindered and not working correctly.
At least the DNS resolution to non-wildcarded domains has to work correctly - do you have a beta version where this is working?
The configuration I am testing now is
Omada 5.15.24.19 (registered in cloud of course)
x2 EAP615-Wall(EU) v1.0 (1.5.4)
x1 SG2210XMP-M2 v1.0 (1.0.12)
As Gateway we are using a Sophos Firewall - this is a branch office and it's the first we are configuring, but if we can't fix the guest captive portal for our users we'll need to switch technology.
- Copy Link
- Report Inappropriate Content
Thanks you for the detailed feedback.
To help assist and streamline the identification of the behavior, we recommend sending an email with the following information:
Subject: [Forum Escalation][ID 785478]
Forum Nickname:
Thread URL: https://community.tp-link.com/en/business/forum/topic/785478?replyId=1598400
Model&Version:
Description:
Any Other Relevant Information:
For your case, please include the info I mentioned earlier in this post
Once sent, a ticket will be created in our support system, and a member of the team will follow up to gather more information or troubleshoot a cause.
- Copy Link
- Report Inappropriate Content
I have sent the email from your link, also there are updates to what I wrote here - practically the main issue that I cannot get around right now is the lack of wildcards in the Portal ACL (I fixed the DNS issues updating the APs and redeploying the Controller from scratch).
- Copy Link
- Report Inappropriate Content
Hi @AlessandroA
Thanks for the info.
Once the issue is addressed or resolved, please update this topic thread with your solution to help others who may encounter the same problem as you did.
- Copy Link
- Report Inappropriate Content
as per my information as of now, the only way to fix it is if Tp-Link rolls out a version of Omada that accepts wildcards in all ACLs - which I really wouldn't think to be too complicated - they are already there in the Network ACLs (I tried creating a Network ACL for Wireless, but this is a walled garden situation and Network ACLs are rightfully-so impacting the navigation, not the AAA). It would have been another bug if it worked :)
Do you have the ability to prioritize this? I opened a ticket to your italian support last Monday, but apparently TP-Link website is wrong about the support email, so I called on Tuesday and got the right email (after waiting 30 minutes on the phone), but the nice lady who replied told me no one will pick it up until next Monday.
I understand this is a free NAC platform, but the devices are paid for, I'd really like after almost a full working week that someone just started doing something about it.
This is also part of my experience, so I believe this needs to be shared, and Tp-Link's reaction is definetly a benchmark that, as customers, we need to evaluate.
Thank you again.
AA
- Copy Link
- Report Inappropriate Content

Information
Helpful: 0
Views: 690
Replies: 13
Voters 0
No one has voted for it yet.