16
23.1 Legacy Series / Re: ddclient doesn't support multi-wan ip update
« on: August 22, 2023, 07:32:35 am »
Here we go... this is what I already wrote for the docs (since I am not familar with github, I am not able to provide it there). I also added some screenshots (please note that the description is not based on the screenshots):
Multi-WAN
In multi-WAN environments you would like to update your domain with primary WAN’s IP address even if other WAN interfaces are available, or separately for each WAN. You will be quite fine, if your desired IP address is issued directly on your OPNSense’s interface, but not if you have upstream router or modem connected to your sense.
In the latter case ddclient might check the IP address on the wrong interface, resulting in wrong IP address issued to your domain.
The following describes different secenarios and how to deal with it in multi-WAN environments to make sure that the desired IP address will be issued to your domain.
IP addresse(s) directly issued on your OPNsense interface
If the desired IP address for an interface is issued directly on your OPNsense, you are fine using „Interface IPvX“ as check IP method in ddclient. For those interfaces there is no need for further configuration, as long as you are using separate domains for each interface.
Note:
This will always grab the IP address from the chosen interface. This is not suitable if you want to achieve, that the IP address of the actual active WAN will be issued to one and the same domain.
Upstream router / modem connected to OPNsense
For interfaces with upstream devices you usally want to issue your upstream device’s public IP to your domain (but usually not for IPv6). In this case the check IP method „Interface IPvX“ mentioned above may not give you the desired public IP address and you need to choose one of the other methods. All those other methods will use external services to check the public IP address, but, as mentioned at the beginning, ddclient may use the wrong interface to perform its IP checks.
Depending on what is to be achieved you need one of the following configurations:
A) Seperate domains for each interface
1. Set up DDNS for WAN 1 as desired.
2. Set up DDNS for WAN 2 and make sure to choose another check IP service (e.g. nsupdate.info) than used
for primary WAN.
If there are more WAN interfaces, choose different check IP services for each.
3. At Firewall/Alias create an alias as follows:
Enabled = checked
Name = Check IP WAN 2 (or anything suitable)
Type = Host(s)
Content = URL from IP check service configured for WAN 2 (in this example nsupdate.info). Please see notes below.
4. Create a firewall rule on WAN 1 as follows:
Action = Pass
Direction = out
Destination = the new created alias for this interface
TCP/IP Version = depending on your needs; in doubt v4+v6 will be fine
Description = Route check IP WAN 2 (or anything suitable)
Gateway = WAN 2
Note:
For alias content do not add the check IP service as it is specified in ddclient, as this is only the service’s name. You need to determine the domain for this service. E.g.
dyndns = checkip.dyndns.org
nsupdate.info-ipv4 = ipv4.nsupdate.info
nsupdate.info-ipv6 = ipv6.nsupdate.info
ip4only.me = ip4only.me, ip4.me (add both to alias)
ip6only.me = ip6only.me, ip6.me (add both to alias)
Note:
If there are more WAN interfaces, you need to create this rule on all WAN interfaces, except the interface to monitor. In such cases you are good to go using floating rules.
Also remember that in this case there are further rules, following the same scheme, for each gateway to monitor required.

Requests to the desired check IP service(s) will now be routed over the given gateway in the firewall rule, resulting in getting the public IP address of the upstream device.
Tip:
For IPv6 you should use „Interface IPv6“ as IP check method in ddclient, as long as you are not intended to update a single domain for the actual active interface.
B) Single domain for actual active interface
Without routing IP checks to a certain gateway as previously described under A), ddclient will always use the active gateway (online with highest priority and marked as „upstream“), even if you have set up policy based routing for your LAN and other subnets.
To make sure ddclient uses the desired gateway, the gateway priority at System/Gateways/Single should match the tiers configured at System/Gateways/Group.
Note:
A lower value means a higher priority.
Gateways marked as „upstream“ will always be used favor to those that are not. To just go by priority, mark all involved gateways as upstream.
In this scenario you have to use any IP check method in ddclient but „Interface IPvX“.
Requests to the check IP service will now be routed over the active gateway, resulting in getting the public IP address of the corresponding upstream device.
Tip:
For sure, the different scenarios can be combined, e.g. having separate domains for WAN 1 and WAN 2 and one domain for the active one. Make sure you are using different IP check services for each, as long as you are not using „Interface IPvX“ method for WAN 1 and WAN 2.
Multi-WAN
In multi-WAN environments you would like to update your domain with primary WAN’s IP address even if other WAN interfaces are available, or separately for each WAN. You will be quite fine, if your desired IP address is issued directly on your OPNSense’s interface, but not if you have upstream router or modem connected to your sense.
In the latter case ddclient might check the IP address on the wrong interface, resulting in wrong IP address issued to your domain.
The following describes different secenarios and how to deal with it in multi-WAN environments to make sure that the desired IP address will be issued to your domain.
IP addresse(s) directly issued on your OPNsense interface
If the desired IP address for an interface is issued directly on your OPNsense, you are fine using „Interface IPvX“ as check IP method in ddclient. For those interfaces there is no need for further configuration, as long as you are using separate domains for each interface.
Note:
This will always grab the IP address from the chosen interface. This is not suitable if you want to achieve, that the IP address of the actual active WAN will be issued to one and the same domain.
Upstream router / modem connected to OPNsense
For interfaces with upstream devices you usally want to issue your upstream device’s public IP to your domain (but usually not for IPv6). In this case the check IP method „Interface IPvX“ mentioned above may not give you the desired public IP address and you need to choose one of the other methods. All those other methods will use external services to check the public IP address, but, as mentioned at the beginning, ddclient may use the wrong interface to perform its IP checks.
Depending on what is to be achieved you need one of the following configurations:
A) Seperate domains for each interface
1. Set up DDNS for WAN 1 as desired.
2. Set up DDNS for WAN 2 and make sure to choose another check IP service (e.g. nsupdate.info) than used
for primary WAN.
If there are more WAN interfaces, choose different check IP services for each.
3. At Firewall/Alias create an alias as follows:
Enabled = checked
Name = Check IP WAN 2 (or anything suitable)
Type = Host(s)
Content = URL from IP check service configured for WAN 2 (in this example nsupdate.info). Please see notes below.
4. Create a firewall rule on WAN 1 as follows:
Action = Pass
Direction = out
Destination = the new created alias for this interface
TCP/IP Version = depending on your needs; in doubt v4+v6 will be fine
Description = Route check IP WAN 2 (or anything suitable)
Gateway = WAN 2
Note:
For alias content do not add the check IP service as it is specified in ddclient, as this is only the service’s name. You need to determine the domain for this service. E.g.
dyndns = checkip.dyndns.org
nsupdate.info-ipv4 = ipv4.nsupdate.info
nsupdate.info-ipv6 = ipv6.nsupdate.info
ip4only.me = ip4only.me, ip4.me (add both to alias)
ip6only.me = ip6only.me, ip6.me (add both to alias)
Note:
If there are more WAN interfaces, you need to create this rule on all WAN interfaces, except the interface to monitor. In such cases you are good to go using floating rules.
Also remember that in this case there are further rules, following the same scheme, for each gateway to monitor required.
Requests to the desired check IP service(s) will now be routed over the given gateway in the firewall rule, resulting in getting the public IP address of the upstream device.
Tip:
For IPv6 you should use „Interface IPv6“ as IP check method in ddclient, as long as you are not intended to update a single domain for the actual active interface.
B) Single domain for actual active interface
Without routing IP checks to a certain gateway as previously described under A), ddclient will always use the active gateway (online with highest priority and marked as „upstream“), even if you have set up policy based routing for your LAN and other subnets.
To make sure ddclient uses the desired gateway, the gateway priority at System/Gateways/Single should match the tiers configured at System/Gateways/Group.
Note:
A lower value means a higher priority.
Gateways marked as „upstream“ will always be used favor to those that are not. To just go by priority, mark all involved gateways as upstream.
In this scenario you have to use any IP check method in ddclient but „Interface IPvX“.
Requests to the check IP service will now be routed over the active gateway, resulting in getting the public IP address of the corresponding upstream device.
Tip:
For sure, the different scenarios can be combined, e.g. having separate domains for WAN 1 and WAN 2 and one domain for the active one. Make sure you are using different IP check services for each, as long as you are not using „Interface IPvX“ method for WAN 1 and WAN 2.