Hardware: Omada Fusion 2.5G, Hardware Version: V1.0
Firmware: 1.0.30 Build 20260721 Rel.31623
Units involved: two Fusion 2.5G routers (Site A and Site B)
Summary:
Site-to-Site WireGuard on the Fusion 2.5G currently has NO working path to set the peer Endpoint to an IPv6 address — neither by entering a literal IPv6 address, nor by using a DDNS hostname that only has an AAAA record. This makes Site-to-Site WireGuard unusable in any deployment where a site only has a public IPv6 address and no public IPv4 (increasingly common with IPv6-only, DS-Lite, or CGNAT ISP deployments).
Scenario:
Both Site A and Site B have ONLY a public IPv6 address on their WAN (no public IPv4 at all). DDNS is configured via dynv6.net on both sides and correctly reflects each site's current public IPv6 address (verified directly in the dynv6 dashboard, both AAAA records are accurate and up to date).
Configuration summary:
– VPN type: WireGuard, Site-to-Site
– Local network type: Custom IP (tunnel address e.g. 172.31.255.3/24 on Site A, 172.31.255.2/24 on Site B)
– Peer Endpoint: DDNS hostname (sitea.dynv6.net / siteb.dynv6.net), port 51558
– Allowed Address: the peer's single tunnel IP (/32)
– Persistent keepalive: 25s, PSK configured identically on both ends
– Firewall: explicit ACL rule on both routers permitting inbound UDP to the gateway's management IP on port 51558 from WAN
– System clocks on both routers are in sync
Problem:
The WireGuard peer never establishes a handshake. VPN Status always shows:
– Status: Disconnected
– Remote Server IP: 0.0.0.0
– TX/RX bytes and packets: 0
– Last Handshake: never
Two tests were performed to isolate the cause:
Test 1 — DDNS resolution only checks the A record, never AAAA:
I temporarily added a fake A record (127.0.0.1) alongside the real AAAA record on the DDNS hostname. Immediately after, "Remote Server IP" in VPN Status changed to 127.0.0.1. This shows the Fusion 2.5G resolves the Endpoint hostname's A (IPv4) record only, and completely ignores the AAAA (IPv6) record. With a hostname that only has an AAAA record (our actual case), resolution silently fails and falls back to 0.0.0.0.
Test 2 — the Endpoint field rejects IPv6 literal addresses outright:
Independent of DNS, I tried entering the peer's literal public IPv6 address directly into the Endpoint field (tested both with and without square brackets). In both cases the configuration fails to save. This shows the Endpoint input validation itself does not accept IPv6 address syntax at all — it's not just a DNS resolution issue.
Conclusion:
Test 1 and Test 2 together show this isn't a single narrow bug but a complete lack of IPv6 support for the Site-to-Site WireGuard Endpoint field, at both the input-validation level and the DNS-resolution level. WireGuard itself fully supports IPv6 endpoints, so this is purely a limitation of the Omada Fusion firmware/UI.
Feature request: Please add IPv6 support to the WireGuard Endpoint field:
(a) accept a literal IPv6 address (with brackets, per standard WireGuard/RFC syntax), and
(b) resolve AAAA records when a DDNS hostname is used for the Endpoint.
I've seen related reports scattered across the TP-Link community for other Omada/TP-Link WireGuard implementations (e.g. topic/671792, topic/856096, topic/684370), so this doesn't appear isolated to my hardware — it looks like a broader limitation across the WireGuard stack used on Omada devices. Happy to provide full config screenshots/logs if it helps triage.
Source: r/Omada_Networks · by /u/andy-chin-lab