OPNsense Forum
Archive => 23.1 Legacy Series => Topic started by: Sakata_T on May 07, 2023, 08:45:16 am
-
As subject states, the newest update broke the dynamic DNS updater.
I have two WANs, and previously it worked.
ip1.mydomain.com was tied to WAN1
ip2.mydomain.com was tied to WAN2
Now both are stuck on WAN1 IP despite checking and rechecking settings to confirm that the correct interface is selected.
Can't use the OPNSense backend as it doesn't seem to have namecheap available as an option
-
What have you set for "Check IP method"? "interface" or something else?
-
It's been set to interface since switching to the new DDNS system, and has worked thusfar.
-
switched the setting to 'freedns' which seems to have worked, but now the service shows as not running, and 'starting' it doesn't work. Interestingly, the logs show it is running...
-
It seems like the new routing subsystem (the one integrating the gateway switching) broke the ability to determine the IP address of an interface if there are other (VPN) interfaces going through them. For me none of ddclient's methods work reliably to find out the IP of my WAN interface (was working fine until now).
I don't know if it is also stemming from this or not but my local Wireguard LAN interface does not come up on the routers, so this change entirely brought down my so-far perfectly working infrastructure interconnected thorugh Wireguard. I am eagerly waiting for a fix, now that I will have to visit all the remote places where the routers reside...
-
I am unsure about the preliminary analysis here... if you use default gateway switching os-ddclient would naturally use the default gateway whatever it is switched to when using a public service. The interface methods should work regardless...
Cheers,
Franco
-
Thanks for looking into this Franco! In the meantime I found out that probably OpenVPN was the culprit in my case (at least partly): it was working fine until the 23.1.7 upgrade, then the connection would build up, but the routes were not added to the routing table. So I unchecked the 'Don't pull routes' and 'Don't add/remove routes' switches and all was well until reboot as it seems. Now I have noticed that there was a 0.0.0.0 route added to the routing table (superseding the default route!) which of course redirected all traffic through OpenVPN - the dynamic DNS request among them - but still it is strange that it also overtook the dynamic DNS's WAN interface address.
[edit] So far it seems to be working fine having 'Don't add/remove routes' checked and 'Don't pull routes' unchecked in OpenVPN, but I still need to phisically travel to all the other routers to correct this on them as well so they can interconnect again. :/
-
Is this something that changed due to OpenVPN 2.6? That sounds a bit like OpenVPN overstepping its role.
Cheers,
Franco
-
Yes, I think something changed with OpenVPN 2.6. But I'm not sure if it is the intended behaviour or not (to me the current behaviour seems more logical to be honest).
-
I think something else is also going on. I reboot the firewall again, and I noted in the logs that despite having NameCheap selected, it keeps showing this in logs:
CONNECT: dynamicdns.park-your-domain.com
WARNING: cannot connect to dynamicdns.park-your-domain.com:443 socket: Name does not resolve IO::Socket::IP configuration failed
Not sure where that comes from...
Also at some point the thing did manage to update the WAN2 DNS to WAN1 IP... again.
-
Hoping this is being looked into? If there is any information I can provide, I'm happy to do so, just let me know what is needed.
Manually editing the nameserver by hand is not exactly optimal, as I'm depending on the firewall already being updated for roadwarrior VPN which I can't exactly do without getting my IP to connect to first.
Thankfully I have an annoying but usable workaround, but would at least like to know this is on someone's radar to be re-fixed.
-
So far it seems to be working fine having 'Don't add/remove routes' checked and 'Don't pull routes' unchecked in OpenVPN...
I'm fairly certain that's the configuration required for split-tunnelling, which you would need to bypass the VPN for DDNS updates. This effectively disables the use of --redirect-gateway def1 ... when pushed (which it typically is).
Is this something that changed due to OpenVPN 2.6? That sounds a bit like OpenVPN overstepping its role.
I don't think that's the case here, but something could have changed...
EDIT: Something did indeed change with OpenVPN, per this post (https://forum.opnsense.org/index.php?topic=33890.msg164439#msg164439) below.
@Sakata_T, do you have any client instances configured, or just your roadwarrior server?
-
I'm fairly certain that's the configuration required for split-tunnelling, which you would need to bypass the VPN for DDNS updates. This effectively disables the use of --redirect-gateway def1 ... when pushed (which it typically is).
Sure, it was just working differently with OpenVPN 2.4: the routes were added even with 'Don't pull routes' checked.
-
Sure, it was just working differently with OpenVPN 2.4: the routes were added even with 'Don't pull routes' checked.
Interesting.
The oldest route add command in my logs is from 2023-01-28. I'm guessing these were v2.4. There are no severity labels and I have successful route add commands for what looks like --redirect-gateway def1 (64/8, 128/8 & 192/8). These would often fail (I presumed due to running multiple clients), so I'm somewhat surprised by this.
Then from 2023-04-14 (v2.5?), I see (reverse chronological order):
/sbin/route add -net virt_net remote_gateway mask
ROUTE_GATEWAY <upstream router IP>, IFACE=xxx, HWADRR=MAC
OPTIONS IMPORT: route-related options modified
OPTIONS IMPORT: route options modified
Then from 2023-05-05 (v2.6?) I see (reverse chronological order):
ROUTE_GATEWAY <upstream router IP>, IFACE=xxx, HWADRR=MAC
OPTIONS IMPORT: route-related options modified
OPTIONS IMPORT: route options modified
So it now appears to be working as intended/expected...
-
Wondering if my posts for this thread are going through, I'm seeing the IP correct now in the panel but when the thing updates my DNS record, it still assigns the wrong IP.
Not sure that this is related to the OpenVPN stuff that is mentioned, but for me at least it seems that the ddns system is choosing a different IP even if the plugin is working for detecting the right IP, at some point in the process it isn't using the data it already has.
-
Not sure that this is related to the OpenVPN stuff that is mentioned...
@Sakata_T, to understand if OpenVPN could be affecting your problem, do you have any client instances configured, or just your roadwarrior server?
-
Just server instance. No clients
-
Just server instance. No clients
In that case, I am minded to consider root causes not related to OpenVPN.
Have you considered the discussion in this topic (https://forum.opnsense.org/index.php?topic=33831.0).
-
Hi,
Have the same problem: Both WAN IP addresses are identified as the fixed IP on the Wireguard Interface. Any workaround ?
edit:
workaround: used icanhazip for "Check ip method"
rgds,
Y
-
I thought "Interface to monitor" is specifying the interface to probe, but none of the methods can extract the interface IP.
Once again i resort to routes. But that is temporary. Routes however don't allow hostnames, apps don't allow aliases etc, so need to create an action.d to refresh:
for host in freedns.afraid.org ...; do
for ip in $(host -4t A $host | grep " has address " | cut -d' ' -f4); do
route add -inet $ip/32 -link -iface wgX
done
done