Ddns : No or private or invalid IP

hi all,
my isp box (livebox) is configured with a DMZ on 80 & 443 ports transfert to my tp-link router known as 192.168.0.11.
i installed a ddns to use my ovh domain. It seems to work fine. But looking the log file, i get this messages :

152913 : Detect registered/public IP
152914 : #> /usr/bin/nslookup xxx.com >/var/run/ddns/myddns_ipv4.dat 2>/var/run/ddns/myddns_ipv4.err
152914 : Registered IP 'xxx.xxx.xxx.xxx' detected
152914 WARN : Updating IP at DDNS provider failed - starting retry 725/0
152914 : Detect local IP on 'network'
152914 : Local IP '192.168.0.11' detected on network 'wan'
152914 : Update needed - L: '192.168.0.11' <> R: 'xxx.xxx.xxx.xxx'
152914 ERROR : No or private or invalid IP '192.168.0.11' given! Please check your configuration
152914 ERROR : No update send to DDNS Provider

Any idea ?
Tks in advance.
Arnaud

Let the livebox do the ddns stuff. It knows the wan ip.

tks for your reply,
In my point of vue, the livebox does not manage ddns services :(.

Sincerly

Your router has a private IP address, you need to use an external service, and configure "ip_source" and "ip_url".

1 Like

Tks for your help @eduperez , but not so clear for me.
OpenWrt router is 192.168.1.1 on LAN.
Oovh domain is configured to be able to access my wan ip using xxx.com.
Livebox (isp routeur) needs to have a dmz transferring 80 & 443 ports to my OpenWrt router (identified with 192.168.0.11).

What do you mean by 'external service' ?

tks again.
Arnaud

1 Like

The DDNS client needs to know your external IP address, and sent it to the DDNS provider. You have told the DDNS client to check the IP address on the WAN interface, but your WAN interface has a private IP address (the DMZ plays no role here, you would need to configure the modem in "bridge modem").

Some DDNS providers permit to auto-configure the redirection using the IP address of the machine that calls their API, and do not need to be told the IP address explicitly, perhaps your provider can do that.

Otherwise, you need someone outside your network to tell your DDNS client what is your external IP address. Have a look at the page on the wiki about DDNS, there is a list of available services there.

Unfortunatly, bridge mode is not available on livebox modem :(. That is why the only solution is to declare a dmz zone.
i have installed luci-ddns & configured to work with ovh.com, cf first message of this post.
It seems does not working properly.

Have you read this?

yes, i did.
I suppose your are talking about the link bellow :
https://openwrt.org/docs/guide-user/services/ddns/client

But i don't understand what @eduperez means by "Somenone outside my netwrok".
I use ovh and openwrt ddns service. i was expecting this would do the job because ovh is in the list " ddns-scripts support the following Dynamic DNS service provider out of the box:"..

tks.

1 Like

It works out-of-the-box when your router has a public IP address.

1 Like

i am really lost in concept.
each time my ip is changed by my provider, i loose the access to my network from outside. I have to actualise it manualy in ovh manager.
i understood that it is the role of openwrt ddns service to change isp ip each time it renew ???

:confused:

I'm not sure what you're missing. You simply need to obtain the Public IP. You won't/can't place your OpenWrt so it obtains that Public IP...

I'm really unsure at what you're missing...

So, I'll just repeat what's been said: if your OpenWrt device had a Public IP, it would work.

EDIT: To be clear, it's being suggested that you use an external service (i.e. a what-is-my-ip provider) to obtain the Public IP for submission to OVH, since you cannot place your router in a configuration to obtain the IP directly on WAN.

1 Like

There are two ways to update a DDNS:

  1. Your client determines the public IP of its network, and forms a request packet including that as a piece of data. The DDNS server places that data into the DNS system.
    1a. If local probing of the network does not allow determining the public IP (which is the case here), a third party server on the Internet can be asked-- an automated version of "whatsmyip". This result is then passed to the DDNS server.
  2. Your DDNS update request does not include any IP data. The DDNS provider's server implies that your public IP is the same as the source of the request.

Method 1 is harder to work in your case. Method 2 should be used if possible.

2 Likes

i confirm that i have a public ip : i am actually accessing to my network from outisde, using xxx.com from ovh, in place of 99.99.99.99.
So when ips ip changes, ovh is not updated ...
but what is strange is

 151128       : Waiting 600 seconds (Check Interval)
 152128       : Detect registered/public IP
 152128       : #> /usr/bin/nslookup dyn.mydomain.com  >/var/run/ddns/myddns_ipv4.dat 2>/var/run/ddns/myddns_ipv4.err
 152128       : Registered IP '**OLD IP**' detected
 152128  WARN : Updating IP at DDNS provider failed - starting retry 1012/0
 152128       : Detect local IP on 'network'
 152128       : Local IP '192.168.0.11' detected on network 'wan'
 152128       : Update needed - L: '192.168.0.11' <> R: '**OLD IP**'
 152128 ERROR : No or private or invalid IP '192.168.0.11' given! Please check your configuration
 152128 ERROR : No update send to DDNS Provider
 152128       : Waiting 600 seconds (Check Interval)
 153128       : Detect registered/public IP
 153128       : #> /usr/bin/nslookup dyn.mydomain.com  >/var/run/ddns/myddns_ipv4.dat 2>/var/run/ddns/myddns_ipv4.err
 153128       : Registered IP '** N E W   IP**' detected
 153128  WARN : Updating IP at DDNS provider failed - starting retry 1013/0
 153129       : Detect local IP on 'network'
 153129       : Local IP '192.168.0.11' detected on network 'wan'
 153129       : Update needed - L: '192.168.0.11' <> R: '** N E W   IP**'
153129 ERROR : No or private or invalid IP '192.168.0.11' given! Please check your configuration
 153129 ERROR : No update send to DDNS Provider

Openwrt seems to be confused with dmz of the isp modem & ip it has attributed to openwrt '192.168.0.11'.

:man_facepalming:

Only after you manually change the IP at OVH!

This is normal, I don't see anything strange. It seems you don't want to configure your OpenWrt properly.

We know.

CORRECT!

You need the Public IP, not 192.168.0.11!

:thinking: So, how do you suggest that OVH obtains that Public IP :question:

If you refuse to try or understand Method 1a, then try to configure OVH to use Method 2.

1 Like

Neither "you" or your OpenWrt router have a public IP address, your modem is the only one who has a public address here, right?

When the public IP address (on the modem) changes, the DDNS client (that runs on the router) has to inform your DDNS provider of the new public IP address. See the issue here?

The DMZ does not play any role here.

1 Like

[quote="eduperez, post:16, topic:55048, full:true"]
Neither "you" or your OpenWrt router have a public IP address, your modem is the only one who has a public address here, right?[/quote]
==> Yes :slight_smile: it is the ISP modem which have the public IP.

==>That is what is implemented using DDNS service on OpenWrt ? Isn t it ?
==>what i was expecting is that when ISP IP changes, Openwrt should update on ovh the DynHost value with this new IP ?

==>OK

Again... no, it does not work that way.

The DDNS client needs that the public IP address is assigned to the router, it does not work out-of-the-box if the public IP address is assigned to the modem. This is expected behaviour, there is nothing wrong here.

Now, you need to find another way to make DDNS work in your setup, because it is never going to work like this.

There are a couple of alternative solutions that have been explained above. Please, read the rest of this thread again, and ask for help on how to implement those solutions, if you need it.

hi all, ok, i solved it using http://checkip.dyndns.com.
tks for all your help !
but now, i am not able to ping my domain... but google.com is ok.

/tmp/hosts# ping google.com
PING google.com (172.217.19.238): 56 data bytes
64 bytes from 172.217.19.238: seq=0 ttl=52 time=6.198 ms
64 bytes from 172.217.19.238: seq=1 ttl=52 time=5.985 ms
64 bytes from 172.217.19.238: seq=2 ttl=52 time=5.932 ms
64 bytes from 172.217.19.238: seq=3 ttl=52 time=6.628 ms
64 bytes from 172.217.19.238: seq=4 ttl=52 time=6.492 ms
64 bytes from 172.217.19.238: seq=5 ttl=52 time=6.366 ms
^C
--- google.com ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 5.932/6.266/6.628 ms
root@OpenWrt:/tmp/hosts# ping mydomain.site
PING mydomain.site (213.186.33.xx): 56 data bytes
^C
--- chtiloft.site ping statistics ---
8 packets transmitted, 0 packets received, 100% packet loss
root@OpenWrt:/tmp/hosts# ping myhome.mydomain.site
PING myhome.mydomain.site (90.45.117.xx): 56 data bytes
^C
--- loft.chtiloft.site ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
root@OpenWrt:/tmp/hosts# ping facebook.com
PING facebook.com (179.60.192.36): 56 data bytes
64 bytes from 179.60.192.36: seq=0 ttl=52 time=5.892 ms
64 bytes from 179.60.192.36: seq=1 ttl=52 time=6.577 ms
^C
--- facebook.com ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 5.892/6.234/6.577 ms
root@OpenWrt:/tmp/hosts#

i really have no idea of the origin of the problem. It works fine during some days, and tryied to install privoxy, maybe the cause.. Privoxy is disabled

firewall :

config defaults
option syn_flood '1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'

config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'

config zone
option name 'wan'
list network 'wan'
list network 'wan6'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'

config forwarding
option src 'lan'
option dest 'wan'

config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'

config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'

config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'

config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'

config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'

config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'

config include
option path '/etc/firewall.user'

Tks again for your help.

This depends on whether your ISP will "hairpin" packets that you send to your public IP back to you. Some do and some do not.

A common workaround to the ISP not having a hairpin route is to add a line to /etc/hosts so that machines on your LAN resolve the public name to a local IP. The problem here is that all your services that you want to see using the public name from the LAN need to have the same local IP, that is they are on the same server machine.

There is also option reflection in forwarded ports. This may work for the case where different ports go to different servers.

Right now your firewall configuration is the default which doesn't accept any incoming WAN except pings and IPsec.