Custom Dynamic DNS
-
Doing it in pfSense may not be that hard - the code for dyndns isn't that hard to get around, it's easy to copy/paste and adjust.
Adding some GUI bits for a "custom" option wouldn't be too difficult for someone who knows PHP, HTML and JavaScript.
-
Doing it in pfSense may not be that hard - the code for dyndns isn't that hard to get around, it's easy to copy/paste and adjust.
Adding some GUI bits for a "custom" option wouldn't be too difficult for someone who knows PHP, HTML and JavaScript.
In that case, I'll go ahead and start working on it, though I might not have much time in the next week, so it might be a while before I can get around to finishing it.
-
Sure. Most of the code you'd need to look at is in /etc/inc/dyndns.class and /usr/local/www/services_dyndns.php
-
The attached patches work, although the GUI could be done a bit nicer.
Just```
patch -R /usr/local/www/services_dyndns.php < services_dyndns.php.txt
patch -R /usr/local/www/services_dyndns_edit.php < services_dyndns_edit.php.txt
patch -R /etc/inc/dyndns.class < dyndns.class.txt
patch -R /etc/inc/services.inc < services.inc.txtNotes: Currently, the cache file used is {$g['conf_path']}/dyndns_{$dyndns['interface']}{$dyndns['type']}.cache, which will result in a shared cache file for any two DDNS settings on the same provider, this might cause problems for people with multiple Custom Entries. The GUI of the current version states that freeDNS does not require a username, but the script currently requires it. Can someone with experience with freeDNS comment as to whether or not freeDNS requires a username. dyndns.class does not currently check that the server returned a sensible HTTP Status, only that the match string is equal. Also, it would be nice to eventually allow multiple match strings. [dyndns.class.txt](/public/_imported_attachments_/1/dyndns.class.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) -
Version 2:
Much better GUI, and multiple match strings.
Patches now go the right direction, so just install the patches with```
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.txtTested to work with tunnelbroker.net on the latest snapshot. Notes: Currently, the cache file used is {$g['conf_path']}/dyndns_{$dyndns['interface']}{$dyndns['type']}.cache, which will result in a shared cache file for any two DDNS settings on the same provider, this might cause problems for people with multiple Custom Entries. The GUI of the current version states that freeDNS does not require a username, but the script currently requires it. Can someone with experience with freeDNS comment as to whether or not freeDNS requires a username. dyndns.class does not currently check that the server returned a sensible HTTP Status, only that the match string is equal. [dyndns.class.txt](/public/_imported_attachments_/1/dyndns.class.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) -
I haven't had a chance to test this (been a busy day) but it looks promising.
You could get the ID of the dyndns instance and append that to the name after the dyndns type perhaps, to make it more precise.
-
Version 3:
Allows for custom script execution on update failure,
Allows for requests to originate from an interface other than the one monitored (useful to call LAN scripts on update),
Uses a unique id in cache and debug files.Once again patch with```
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.txtIssues: The GUI of the current version states that freeDNS does not require a username, but the script currently requires it. Can someone with experience with freeDNS comment as to whether or not freeDNS requires a username. dyndns.class does not currently check that the server returned a sensible HTTP Status, only that the match string is equal. When an entry is deleted, the script rechecks all interfaces and removes all cache files, it should gracefully move all cache files to the appropriate new ID number. [dyndns.class.txt](/public/_imported_attachments_/1/dyndns.class.txt) [services_dyndns.php.txt](/public/_imported_attachments_/1/services_dyndns.php.txt) [services.inc.txt](/public/_imported_attachments_/1/services.inc.txt) [services_dyndns_edit.php.txt](/public/_imported_attachments_/1/services_dyndns_edit.php.txt) -
Please clarify the license of this(mostly if they can be committed to the repo).
I do not agree totally with this patches and will make some modifications of them: -
Have fun do what you want - I do not claim any copyright to the above patches.
-
Hi!
While you are modifying the DDNS behavior, is it possible to add OpenVPN as an interface? I am using OpenVPN as a Client, and I am routing all my traffic through a public VPN provider. I am solving the DDNS issue now by using the DynDNS client on a server connected to the LAN, but of course, the ideal thing is to use pfSense for this.Thanks!
-
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.
-
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.
-
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.
-
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.txtAgain, 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 -
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.txtThis 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) -
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.
-
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.
-
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. -
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 -
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
