Dynamic DNS Service and Multi-WAN: Wrong IP detected via CloudFlare

Started by alfredo.pironti, January 24, 2025, 06:56:27 PM

Previous topic - Next topic
Hi All, first-time poster here after a migration to OPNsense.

I've read other DynDNS + multi-WAN posts, as well as looked at the plugin source code, but I can't still make sense of what I'm seeing on my instance. Here go the details.

The setup
I have to WANs, as per the "WANs" picture. WAN/em0 is main, with priority 254, and WAN_BKP/em5 is fallback, with priority 255. Each WAN has a private IP address, with an additional ISP router doing NAT and acquiring the public IP address.

This implements a simple fallback system, that does not require a gateway group nor policy-based routing. (I have the gateway switching option enabled). The fallback mechanism works as expected. For example, see the "CURL" picture, using ipify: when using WAN/em0 the requests goes through the main 81.xxx IP address; when using WAN_BKP/em5 it uses the backup 5.xxx IP address. Crucially, when using LAN/em1, it correctly uses the main 81.xxx, active gateway.

The issue
In the DynDNS plugin, I have defined two dynamic-IP hosts (each is backed by a different DNS server, so I need one entry for each domain). See DynDNS picture.

I want each of them to resolve to the same, active gateway at any given time. So I just need the plugin to use the ipify service via the current, active default gateway. The desired behavior is, hence, that if the WAN/em0 connection fails, the active gateway becomes WAN_BPK/em5, a public address change is detected, and DNS records are updated.

However, as you can see from the same DynDNS picture, each host has resolved to a different address! I've set the "Interface to Monitor" as LAN, but also tried with None, and it makes no difference. Edit: I'm using the CloudFlare service to detect the public IP address, and this appears to be inconsitent in a multi-WAN setup. (See post below for details.)

Note the detected public IP address changes erratically. Sometimes both hosts resolve to WAN, sometimes both to WAN_BPK, and sometimes, like in the screenshot, to different IP addresses at the same time.

It's like the DynDSN service is picking a random gateway when issuing the ipify request. But I can't make sense of it, as the source code seems to issue a CURL request, either not specifying any interface when set to None, or resolving the interface of the specified one (LAN in my case, which should always go out from the default gateway.)

(As a note: the DNS records are correct. I use DNS servers where you just inovke a URL, and they pick the source IP of that request. This tells me the requests going out to the DNS servers -- as opposed to those going to ipify -- are indeed picking the correct gateway!)

Any idea what I may be doing wrong, or which portion of the code I could look deeper at to spot the bug? Thanks!

Update: I was using CloudFlare (https://one.one.one.one/cdn-cgi/trace) as the remote service to detect my public IP. Unfortunately, with the dual WAN setup, it appears CloudFlare returns inconsistent results, switching between the two IPs. Even when invoking the same URL from two browser windows (e.g. regular and incognito), I could get two different source IPs. Both of my WANs may emit traffic to 1.1.1.1 and 1.0.0.1 as they are set as DNS servers. I'm not sure how CloudFlare is able to correlate the two IPs, but that may be the source of the issue.

No other IP-detection service exhibits this behavior, always returning the expected, currently-active WAN address.

Given the wide availability of IP-detection services, I'm wondering if CloudFlare should be kept in the plugin as a reliable source?