RFC2136 Updates fail after upgrade to 2.4.x

macralf

I've had RFC2136 Dynamic DNS updates working perfectly on several of my pfsense boxes for years. As soon as I updated 1 of them to 2.4 it stopped working, I'm now on the latest 2.4.2-1 and it's still not working. I have not changed any configuration since the 2.3.5 when it was working. I still have several older pfsense boxes running 2.3.5 that work perfectly, so it's not a DNS server change that is at play here either.

Excerpt from log:

Dec 20 00:24:44 php-fpm 45959 /rc.dyndns.update: phpDynDNS: ERROR while updating IP Address (A) for pfsensefirewall.domain.net (X.X.X.X)
Dec 20 00:24:44 php-fpm 45959 /rc.dyndns.update: The command '/usr/local/bin/nsupdate -k /var/etc/K0keyname.+157+00000.key /var/etc/nsupdatecmds0' returned exit code '1', the output was '; Communication with Y.Y.Y.Y#53 failed: timed out dns_request_createvia: address family mismatch'

X.X.X.X - > public IP
Y.Y.Y.Y - > DNS server IP

I'm not seeing anything in the logs of the DNS server (bind on RHEL)
From a quick search of the internet, I think "Address family mismatch" has something to do with IPv6 vs IPv4. I do not have IPv6 enabled on this firewall, none of the interfaces have an IPv6 address, and the DNS server it's talking does not have IPv6 enabled either. Any help would be appreciated.

Gertjan

@macralf:

I've had RFC2136 Dynamic DNS updates working perfectly on several of my pfsense boxes for years. As soon as I updated 1 of them to 2.4 it stopped working, I'm now on the latest 2.4.2-1 and it's still not working. I have not changed any configuration since the 2.3.5 when it was working. I still have several older pfsense boxes running 2.3.5 that work perfectly, so it's not a DNS server change that is at play here either.

Excerpt from log:

Dec 20 00:24:44 php-fpm 45959 /rc.dyndns.update: phpDynDNS: ERROR while updating IP Address (A) for pfsensefirewall.domain.net (X.X.X.X)
Dec 20 00:24:44 php-fpm 45959 /rc.dyndns.update: The command '/usr/local/bin/nsupdate -k /var/etc/K0keyname.+157+00000.key /var/etc/nsupdatecmds0' returned exit code '1', the output was '; Communication with Y.Y.Y.Y#53 failed: timed out dns_request_createvia: address family mismatch'

X.X.X.X - > public IP
Y.Y.Y.Y - > DNS server IP

I'm not seeing anything in the logs of the DNS server (bind on RHEL)

That is what 'nsupdate' (running from within pfSEnse) already told you. It can't communicate with " Y.Y.Y.Y".
Or, more basic : It can't get out.
Or, even simpler : your pfSense itself can't communicate with "Internet".

I tried to use nsupdater manually, thus from pfSense to my DNS server (I'm using RFC2136 also for long time - using 2.4.2-RELEASE-p1 (amd64) now) :

[2.4.2-RELEASE][admin@pfsense.brit-hxtxl-fumel.net]/var/etc: /usr/local/bin/nsupdate -k K0bbbkey.+157+00000.key /var/etc/nsupdatecmds0

This is what I saw in the log of my DNS server (a bind DNS server) :

20-Dec-2017 16:31:38.331 update: client 2001:470:1f12:5xx::2#63811/key bbbkey: updating zone 'home.brit-hxtxl-fumel.fr/IN': deleting rrset at 'home.brit-hxtxl-fumel.fr' A
20-Dec-2017 16:31:38.332 update: client 2001:470:1f12:5xx::2#63811/key bbbkey: updating zone 'home.brit-hxtxl-fumel.fr/IN': adding an RR at 'home.brit-hxtxl-fumel.fr' A

=> looks good.

20-Dec-2017 16:31:38.331 update: client 2001:470:1f12:5c0::2#63811/key britkey: updating zone 'home.brit-hxtxl-fumel.fr/IN': deleting rrset at 'home.brit-hxtxl-fumel.fr' A
20-Dec-2017 16:31:38.332 update: client 2001:470:1f12:5c0::2#63811/key britkey: updating zone 'home.brit-hxtxl-fumel.fr/IN': adding an RR at 'home.brit-hxtxl-fumel.fr' A

contains the correct instructions for "nsupdate"

server brit-hxtxl-fumel.fr
update delete home.brit-hxtxl-fumel.fr. A
update add home.brit-hxtxl-fumel.fr. 300 A 82.127.34.254
local 192.168.10.11

82.127.34.254 is my WAN IPv4
192.168.10.11 is the WAN IP of pfSense. (dono why nsupdate needs that, but it is there).

@macralf:

From a quick search of the internet, I think "Address family mismatch" has something to do with IPv6 vs IPv4. I do not have IPv6 enabled on this firewall, none of the interfaces have an IPv6 address, and the DNS server it's talking does not have IPv6 enabled either. Any help would be appreciated.

In this case, you are working with IP's (right ?!) so DNS not needed. A DNS ill not resolve an IP like "Y.Y.Y.Y" to "Y.Y.Y.Y".

macralf

I have gone into the command line on the pfsense and I can ping the DNS server. I can also do an nslookup, set the server to Y.Y.Y.Y and successfully query the DNS sever for zones hosted on it. This does not seem to be a problem with the communication to the DNS server, at least not from an OS level.

One more thing to note, the DNS server I'm trying to update is internal to the firewall. In fact there's another Firewall between this one and the DNS server. FW1 (the problem firewall) has to go from its LAN through FW2 (WAN->LAN) to get to the DNS sever. When I do the ping and nslookup, I can see the traffic in the logs on FW2. When I do the nsupdate either via commandline or "save and force update" button, there is no traffic on the FW2 logs.

Again, this process worked perfectly until the 2.4.x upgrade. So due to the lack of traffic, this seems to be a problem inside of the nsupdate process itself.

vizavi

I got same issue after upgrade to 2.3.4->2.4.2

Jan 9 22:07:39 php-fpm[19583]: /services_rfc2136_edit.php: The command '/usr/local/bin/nsupdate -k /var/etc/K0wan2.dyn.net4user.com.+157+00000.key -v /var/etc/nsupdatecmds0' returned exit code '1', the output was '; Communication with 192.168.6.23#53 failed: timed out dns_request_createvia: address family mismatch'

It looks like it is trying to communicate to DNS located inside a LAN over a WAN interface

So it only work , if you select LAN interface on " Interface" on

Services-> Dynamic DNSRFC 2136 ->Clients->Edit

I this case it update itself will work .

But this not really useful , since LAN have static IP anyway.

So . it will possibly also work , if dynamic update will be over WAN interface ( say really external server )

It sounds like regression in 2.4

Derelict

Hmm. It's working here. Address family mismatch sounds like IPv4 vs IPv6.

You could look at /var/etc/nsupdatecmds0 and see if it looks sane when compared against:

https://www.freebsd.org/cgi/man.cgi?query=nsupdate&apropos=0&sektion=0&manpath=FreeBSD+11.1-RELEASE+and+Ports&arch=default&format=html

vizavi

#It looks like GUI page producing incorrect config

server vs local statement

#as per wiki from previous post
https://www.freebsd.org/cgi/man.cgi?query=nsupdate&apropos=0&sektion=0&manpath=FreeBSD+11.1-RELEASE+and+Ports&arch=default&format=html

server {servername} [port]
Sends all dynamic update requests to the name server servername.
When no server statement is provided, nsupdate will send updates to
the master server of the correct zone. The MNAME field of that
zone's SOA record will identify the master server for that zone.
port is the port number on servername where the dynamic update
requests get sent. If no port number is specified, the default DNS
port number of 53 is used.

local {address} [port]
Sends all dynamic update requests using the local address. When no
local statement is provided, nsupdate will send updates using an
address and port chosen by the system. port can additionally be
used to make requests come from a specific port. If no port number
is specified, the system will assign one.

So it worked , if local statement removed.

#exact workaround as below:

[2.4.2-RELEASE][admin@gw.net.com]/root: diff /var/etc/nsupdatecmds0 /var/etc/nsupdatecmds0.backup
3c3,5
< update add wan2.dyn.net.com. 30 A 77.88.777.88
–-

update add wan2.dyn.net.com. 30 A 77.88.777.88
local 77.88.777.88

/usr/local/bin/nsupdate -k /var/etc/K0wan2.dyn.net.com.+157+00000.key -v /var/etc/nsupdatecmds0

ping wan2.dyn.net.com
PING wan2.dyn.net.com (77.88.777.88): 56 data bytes
64 bytes from 77.88.777.88: icmp_seq=0 ttl=64 time=0.118 ms

#bind logs
Jan 10 19:45:45 named[9298]: client @0x7f1de1379190 192.168.0.1#15166/key wan2.dyn.net.com: view Internal: updating zone 'dyn.net.com/IN': adding an RR at 'wan2.dyn.net.com' A 77.88.777.88

And it explain why , in my case ,
with local statement in place it communicate with DNS over WAN

Not sure what should be fixed on page
ServicesDynamic DNSRFC 2136 Clients

To make it work correctly

Again 2.3.4 was working before

Derelict

No. The local options just tells nsupdate what address to bind to to make the update connection. It is the source address.

It was broken before in certain multi-wan scenarios.

vizavi

without local option , it use proper source address on LAN to communicate to internal DNS server. Otherwise it use WAN address as source , and it sent update request via Inet with LAN address destination

May be in GUI , it should be local option configurable with check box to disable it (remove from config ) . Since current logic ( assigning WAN address to bind looks broken )

Derelict

It should not matter what the source address is if the destination address is internal and int he routing table.

You must have something else going on such as policy routing to the DNS update server.

macralf

I'm not sure which policy you're referring to about routing to the DNS server. If you look at my earlier posts, I can ping and do nslookups to the server in question with out issue. The problem is specific to nsupdate.

I can confirm that if I change the /var/etc/nsupdatecmds0 file I can make it work.

If I change the "Local Z.Z.Z.Z" to the internal LAN interface on my firewall, and not the WAN interface, the update works perfectly.

I checked some of my other firewalls running the old version. In the 2.3.X, that file didn't include the Local parameter. This problem was introduced in 2.4.x because it's added to that file now.

pfsense either needs to update the GUI to make that parameter settable, or they need to stop including the local parameter in the file.

Derelict

Sounds like something that the internal DNS server could allow but doesn't.

Though that local directive does assume that the update will be going out the interface that is being monitored. That should probably have a source interface selector, with any being a choice for no local directive, instead of making that assumption.

It is not a regression. It is something done to fix the far-more-common dynamic DNS scenario (updating an outside service) that is tickling your far-less-common scenario (updating an inside service that is apparently has an ACL to only accept updates from that subnet or something.)

A workaround would be to tell your DNS to accept updates from the outside address. The server's default gateway would need to be pfSense for the reply traffic.

Alternately you could outbound NAT that on the inside interface so the request comes from the inside interface address. That is probably the way to go since it does not require any changes on the DNS server.

Derelict

FYI: https://redmine.pfsense.org/issues/8278

macralf

You keep thinking I need to change the DNS server, you're wrong. Again, if you read my earlier notes you'll see why this is not the problem.

@macralf:

One more thing to note, the DNS server I'm trying to update is internal to the firewall. In fact there's another Firewall between this one and the DNS server. FW1 (the problem firewall) has to go from its LAN through FW2 (WAN->LAN) to get to the DNS sever. When I do the ping and nslookup, I can see the traffic in the logs on FW2. When I do the nsupdate either via commandline or "save and force update" button, there is no traffic on the FW2 logs.

Also, My DNS server does accept outside updates, as I have 3 PFsense firewalls updating to that server, only 1 of which is one site. The other two update over their WAN from other locations. So the DNS server works just fine.

Derelict

I know exactly what the problem is.

Look. It WORKS to an inside DNS server that accepts updates sourced from the WAN address. I am doing it here. Yours apparently does not. That's OK.

Something in your specific configuration is denying the update. You have posted the logs yourself. Perhaps you have something strange in your routing. Where is BIND in relation to your firewall?

If the only thing you are changing is the local directive to nsupdate, then the only thing changing is the source address of the update.

Alternately you could outbound NAT that on the inside interface so the request comes from the inside interface address. That is probably the way to go since it does not require any changes on the DNS server.

Another workaround that does not involve changing the DNS server.

Gertjan

Added to that, "nsupdate" is a tool, part of FreeBSD, not pfSense.
So, I'm pretty confident that FreeBSD didn't 'break' nsupdate, even in your case. Because it would have been known by now.

Is it possible that you 'skip' (== remove) this FW2 ? Or open up FW2 so any port to any port is possible ? I tend to thing the 'nsupdate' connections are not possible, blocked by something - and this something is FW2.

vizavi

my workaround was :

#outbound NAT
LAN This Firewall tcp/udp/* int.dns.ip.ip/32 tcp/udp/ 53 lan.int.ip.ip/32 * DNS dynamic update from WAN to internal DNS server
( host alias with LAN IP )

#bind logs
Jan 14 17:45:44 named[7341]: client @0x7f83d8856e60 lan.int.ip.ip#8480/key wan2.dyn.net.com (wan2.dyn.net.com): view Internal: query: wan2.dyn.net.com IN SOA -S (int.dns.ip.ip)
Jan 14 17:45:44 named[7341]: client @0x7f83d024af50 lan.int.ip.ip#39086/key wan2.dyn.net.com: view Internal: updating zone 'dyn.net.com/IN': deleting rrset at 'wan2.dyn.net.com' A
Jan 14 17:45:44 named[7341]: client @0x7f83d024af50 lan.int.ip.ip#39086/key wan2.dyn.net.com: view Internal: updating zone 'dyn.net.com/IN': adding an RR at 'wan2.dyn.net.com' A 77.88.77.88

working now!

Thanks everyone!

Derelict

Added in 2.4.3-DEV

![Screen Shot 2018-01-22 at 11.36.20 AM.png](/public/imported_attachments/1/Screen Shot 2018-01-22 at 11.36.20 AM.png)
![Screen Shot 2018-01-22 at 11.36.20 AM.png_thumb](/public/imported_attachments/1/Screen Shot 2018-01-22 at 11.36.20 AM.png_thumb)

vizavi

working as expected in 2.4.3

#Choose internal interface as upgrade source
#outbound NAT ( with this workaround rule disabled )
LAN This Firewall tcp/udp/* int.dns.ip.ip/32 tcp/udp/ 53 lan.int.ip.ip/32 * DNS dynamic update from WAN to internal DNS server

Thanks !