Dynamic DNS client can't determine public IP from behind NAT router



  • I have a pfSense install with two WANs, both are provided by upstream NAT routers. My two interfaces on pfSense are both in the DMZ of their respective upstream router, but are provided local IP addresses.

    Due to another problem I am currently experiencing, I have a strong need for dynamic DNS. However, pfSense is unable to determine the public IP for either interface. I have disabled the built in 'check IP' service and added 3 others - my own hosted script and two public ones. If I curl these URLs from pfSense command line it correctly returns the public IP.

    In the logs I can see it is failing to determine the public IP for an unknown reason.

    Nov 29 22:11:44 php-fpm 338 /rc.dyndns.update: Dynamic DNS (ddns1.mydomain.com) There was an error trying to determine the public IP for interface - Failover (em1 ).
    Nov 29 22:11:45 php-fpm 338 /rc.dyndns.update: Dynamic DNS (ddns2.mydomain.com) There was an error trying to determine the public IP for interface - opt1 (em2 ).

    I am using Cloudflare DDNS.



  • Anyone? pfsense still can't determine WAN IP when behind another NAT router, even with multiple check IP services enabled. If I use "curl https://api.ipify.org/" from the command prompt in pfsense it correctly returns the WAN IP. Yet dyanmic DNS client will never work.



  • @jpns said in Dynamic DNS client can't determine public IP from behind NAT router:

    I have disabled the built in 'check IP' service and added 3 others - my own hosted script and two public ones

    Why ? "It works for everybody".

    Btw : when your use a device (PC) on a LAN that connect to a router, and you visit a site on tyhe Internet, that site will only see your WAN IP. Not some other LAN or local WAN IP (if router after router).
    This http://checkip.dyndns.org/ should work - if not, your Internet access s broken or IPv6 only ?

    a curl should also work.
    curl is nothing more as a http requester :

    curl  http://checkip.dyndns.org/
    <html><head><title>Current IP Check</title></head><body>Current IP Address: 82.127.34.254</body></html>
    

    Do you have multiple WAN's ?
    Change something using NAT / outbound / Whatever ?
    Set up a one to one system : LAN + WAN : see that it works. Then continue setting up your system until it breaks. Cancel the latest set up step and you'll be fine.



  • Yes it is multi WAN, in a failover configuration. WAN1 (the primary) is a cable modem in bridge mode so the public IP is assigned directly to pfSense. DDNS client has no problem with that. WAN2 (the backup) is an upstream NAT router and pfSense gets a private IP assigned, but it is in DMZ. DDNS client is unable to find the WAN IP, despite the internet access working perfectly through it and manually going to the check IP site shows the correct WAN IP. It has never worked, even on a fresh install, so there is no step to go back to.



  • @jpns said in Dynamic DNS client can't determine public IP from behind NAT router:

    DDNS client is unable to find the WAN IP, despite the internet access working p

    What does the crul test show ?
    (the DDNS code does exactly the same thing).

    edit : Your DDNS client lives behind the DMZ interface ?
    When you hook up a PC with a browser, can you visit http://checkip.dyndns.org/ ?
    It should return the same info (the used WAN IP). If not, check firewall rules / routing issues.



  • I don't know how to explain it any simpler than I already have.

    I can go to http://checkip.dyndns.org/ on any device on the LAN and it correctly shows the WAN IP. If I curl http://checkip.dyndns.org/ from pfSense it also correctly returns the WAN IP. The failover works fine when the primary connection goes down, and pfSense even sends out the notification email over the backup connection so the routing must be correct. Yet the DDNS client is simply unable to determine the IP address.

    This is all I see in the logs:

    rc.dyndns.update: Dynamic DNS (wan2.secretdomain.com) There was an error trying to determine the public IP for interface - opt1 (em2 ).

    And in the actual DDNS menu in pfSense it just shows cached IP as "N/A"



  • So, the curl "manual" test - from pfSense and some PC - shows what when your main WAN is down, and you're using opt1 (em2 ) (WAN2) ?



  • @gertjan it correctly shows the WAN2 public IP as expected



  • So, http://checkip.dyndns.org/ does return the expected result.
    Of course, it can do so if routes are ok, local DNS is functioning.
    And in your case, the link to Cloudfare DNS is up.



  • @gertjan the only thing that doesn't work is the DDNS client in pfSense. Everything else works perfectly, as it should. I have only ever experienced this problem on interfaces that are assigned a private IP, and I've tested it on more than one install with different configurations. If the interface gets a public IP, DDNS works fine. Which doesn't make sense to me really because the interface IP should be irrelevant if it's using external IP check services (which return the correct IP) anyway.



  • Ok, it is time to read the manual, this means the code /etc/inc/dyndns.class
    Discovered something.

    I disabled the test that print the error so the errorlog would show when I forced an update.

    /services_dyndns_edit.php: Dynamic DNS (245809) There was an error trying to determine the public IP for interface - wan (rl0 82.127.34.254).
    

    My log line shows something that yours doesn't : the IP .... and that's why your error log line pops up.
    Seems normal, without a WAN IP, nothing will work.

    I advise you to look at this line https://github.com/pfsense/pfsense/blob/c07f1c2667995b9c46f9187fdf0baa6efbb8aa19/src/etc/inc/dyndns.class#L2300
    The function dyndnsCheckIP is defined in /etc/inc/services.inc
    Does it return "down" or "0" or an IPv4 ?

    Also : I advise you to remove :

    @jpns said in Dynamic DNS client can't determine public IP from behind NAT router:

    I have disabled the built in 'check IP' service and added 3 others

    which could explain the behaviour.



  • @gertjan Thanks for the reply. Sorry, I am not entirely sure what you are asking me to do here. I re-enabled the default check IP service.


Log in to reply