Custom Dynamic DNS

jimp

Zappca,

Have you tried assigning your openvpn instance as an OPT interface? (assign it, enable it, select "none" for the IP type)

It may do what you want then.

Zappza

Unfortunatly it does not. I tried assigning the interface to the ovpnc1 port, but the DNS client was not able to retrieve the IP adress that OpenVPN was connected to. The adress reported back was 0.0.0.0.

jimp

Then it may be covered by the changes I've suggested here: http://redmine.pfsense.org/issues/904

May not happen for 2.0 though.

BlueMatt

I've updated the patches to fix a couple bugs I've been seeing on the previous patches.
1. Because of the lines```
if (!empty($int))
break;

in services.inc, only one dyndns provider will be updated per interface if services_dyndns_configure is called with an interface (it usually is), this is a bug in pfSense, and is unrelated to my particular patch, but effects all users of multiple dyndns providers on one interface (or should as far as I can tell).  

2\. One of my providers automatically pings my IP Address to make sure it is up before allowing updating (tunnelbroker.net) thus /etc/inc/interfaces.inc had to be changed to allow filter_configure to happen before serivces_dyndns_configure.  I added a sleep(1) to make sure the reload is done.  

All other previous issues still apply.  

Zappza:  I don't use OpenVPN on my installation, so I don't know how pfSense handles the interfaces of it.  If you could send an output of ifconfig -a (or at least the relevant parts) and the list of interfaces according to the webUI, I'll try to add it if I have time.

New Patches are attached and can be applied through```
patch /usr/local/www/services_dyndns.php < services_dyndns.php.txt
patch /usr/local/www/services_dyndns_edit.php < services_dyndns_edit.php.txt
patch /etc/inc/dyndns.class < dyndns.class.txt
patch /etc/inc/services.inc < services.inc.txt
patch /etc/inc/interfaces.inc < interfaces.inc.txt

Again, I claim no copyright on the above patches, or anything posted previously.

interfaces.inc.txt
services.inc.txt
services_dyndns.php.txt
services_dyndns_edit.php.txt
dyndns.class.txt

BlueMatt

I'm sorry, my last post not fully tested.

In addition to the modification of interfaces.inc, rc.newwanip had to be updated in order to make sure that the filter is reloaded before dyndns is updated. (I'm only really assuming that interfaces.inc needs modification, I've only tested the updates through disconnect/connect on the webui, but it is called by several other functions in interfaces, so to be safe I'm going to leave it modified.)
So with rc.newwanip, use```
patch /usr/local/www/services_dyndns.php < services_dyndns.php.txt
patch /usr/local/www/services_dyndns_edit.php < services_dyndns_edit.php.txt
patch /etc/inc/dyndns.class < dyndns.class.txt
patch /etc/inc/services.inc < services.inc.txt
patch /etc/inc/interfaces.inc < interfaces.inc.txt
patch /etc/rc.newwanip < rc.newwanip.txt


This time I tested the patches against the latest snapshot and they work.

As always, I claim no copyright to any of the above. 

[rc.newwanip.txt](/public/_imported_attachments_/1/rc.newwanip.txt)
[interfaces.inc.txt](/public/_imported_attachments_/1/interfaces.inc.txt)
[services.inc.txt](/public/_imported_attachments_/1/services.inc.txt)
[services_dyndns.php.txt](/public/_imported_attachments_/1/services_dyndns.php.txt)
[services_dyndns_edit.php.txt](/public/_imported_attachments_/1/services_dyndns_edit.php.txt)
[dyndns.class.txt](/public/_imported_attachments_/1/dyndns.class.txt)

BlueMatt

Is there a chance this will make it into 2.0, or is there anything that needs changed before possible inclusion, or has this just fallen under bug fixes get first priority and there is a lot left to do?

Thanks for the great project.

jimp

If ermal gets a chance to look them over and offer feedback/fixes, they may make 2.0.

If it doesn't, it should be easy enough to whip up a package to add in the patches, but that couldn't really happen 100% until 2.0 is out since files are moving targets until then.

BlueMatt

One more bug in the existing code: line 587 in /etc/inc/services.inc should be return, not continue.
This can cause an error when a DynDNS Service is disabled.

BlueMatt

@BlueMatt:

One more bug in the existing code: line 587 in /etc/inc/services.inc should be return, not continue.
This can cause an error when a DynDNS Service is disabled.

This bug causes the following error on a page which reconnects an interface:

Fatal error: Cannot break/continue 1 level in /etc/inc/services.inc on line 587

Zappza

Hello!
Here is a pastebin of ifconfig -a.

I did get it to report the correct IP when listening to the LAN interface, but it didn't appear to update the entry properly.

Thanks!

http://pastebin.com/cnsXXRHg

dszp

One option I can think of as well is to be able to update http://www.dnsomatic.com/ from pfSense, which will in turn update many other dynamic IP services. Maybe the existing system will work with it, I think they use a similar API to existing providers to make it easy to use them as a drop-in replacement. But I'm not a dynamic DNS API expert, just a suggestion.

BlueMatt

Its a great idea, and I do use dnsomatic from time to time, however the site (including the list of supported services) hasn't been touched in years, and I needed several other services (including one custom designed one) to be automatically updated.