I’ve done a 180 on the TP-Link EAP225 v3, going from loving it to loathing it after just a few days. My issues (and decision to return the AP) all spur from introducing IPv6 into my network. However, the issues experienced, I believe, point to a fault in the AP’s firmware that is not specific to IPv6. I thought I’d share my experience as, based on recent reviews/ tests of this device and its price-point, it seemed like the better choice over the UAP-AC-LITE. No doubt others will be considering a similar purchase in future.
My Setup
- TP-Link EAP225 version 3 (2.4.0 Build 20181121 Rel. 55897)
- TP-Link TL-SG108PE version 2 (1.0.0 Build 20181120 Rel.40990)
- Ubiquiti Edge Router X (EdgeOS v1.10.8)
Additional Context
- Cost was a key factor in selecting hardware. Had the budget been bigger I’d have likely gone US-8-60W and UniFi Nano HD!
- I use VLANs for network segmentation/ isolation (for IOT devices, Guest, etc.) across both wired and wireless clients.
- I *was* using VLAN1 for the management interfaces and a trusted PC (I know… be gentle, it’s a home network). As part of troubleshooting this issue I moved the management VLAN to a different VLAN ID.
- I have multiple SSIDs on the EAP, all set to specific VLANs in order to benefit from wireless device network segregation.
- I use a Zone Based Firewall configuration on the Edge Router. This seems to be the easiest mechanism to enable network segmentation when using IPv6 addresses assigned via prefix delegation.
- All VLANs have IPv6 prefix-delegation configuration in-place, configuration in line with this guide
- Whilst I have a single AP at present, there will be three in this setup
The Problem
- After configuring IPv6 on the Edge Router I ran into an issue with additional IPv6 addresses being assigned to devices that were associated with a different network segment/ VLAN. A device would first receive a correct IPv6 address, with the relevant prefix assigned to the VLAN, but then a rogue address would appear, using a prefix associated with a different VLAN – specifically the management VLAN.
- This would actually break IPv6 connectivity on the devices as they would be unable to use the new router associated with the rogue IPv6 address.
Troubleshooting
- Initially I thought I’d missed something in the configuration (i.e. I’d fat-fingered something). Every VLAN interface on the EdgeRouter has a defined IPv6 prefix ID, as below. I checked each of these, over and over and over.
set interfaces ethernet eth0 dhcpv6-pd pd 0 interface switch0.50 host-address ':1'
set interfaces ethernet eth0 dhcpv6-pd pd 0 interface switch0.50 prefix-id '::5'
set interfaces ethernet eth0 dhcpv6-pd pd 0 interface switch0.50 service slaac
- I then looked to see if I could find anyone else with the same/ similar issues. It didn’t take long to find someone else with the same problem, albeit with slightly different TP-Link devices.
- Initially (from thread linked above) I thought this was down to the TL-SG108PE switch I had the EAP connected to. I’d read this device also leaks traffic from the default VLAN into other VLANs. However, after removing VLAN1 I was still getting an additional IPv6 address from the management VLAN prefix on wireless devices.
- Accepting the EAP may be affected by the same issue (as highlighted in linked thread above), I configured the management VLAN on the EAP and then assigned a dummy/ unused VLAN PVID (that has no IPv6 configuration) to the uplink port used by the EAP (with VLAN tagging set for required VLANs). At this point the rogue IPv6 address assignment issue was resolved.
Learnings
- Simply put the TP-Link EAP225 v3 (along with the TL-SG108PE ) “leaks” traffic from the default VLAN on to other VLANs. The IPv6 Router Advertisements (RAs) were leaking from the management / default VLAN to other VLANs. Whilst I was able to work around this specific issue, TP-Link’s engineers have now introduced a problem that’s broken wireless Client Isolation. Despite raising a support ticket, they seem thrilled with the new functionality (when enabled wireless devices cannot connect to wired devices on any VLAN, which borked all of my IOT/ MQTT connections).
- In an IPv4-only environment, my own experience in testing this device was really positive, albeit prior to the recently introduced wireless Client Isolation issue!
- TLDR, I’m returning the TP-Link EAP225 v3, swapping it out for an Ubiquiti UAP-AC-LITE… I guess you really do get what you pay for!
One reply on “TP-Link EAP225 v3 Experience”
Looks like TP-Link may have fixed this issue in a firmware update.
The release notes for the 2.6.0 2019-09-24 firmware include this:
2. Fixed the bug that untag packets can be transferred to SSIDs with different VLANs.
https://www.tp-link.com/uk/support/download/eap225/v3/#Firmware