Project

General

Profile

Actions
Copy link

Bug #5958

closed

Stale Aliases - upstream DNS changes do not update firewall rules that are based on aliases

Added by Mike Depot over 9 years ago. Updated almost 8 years ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
Rules / NAT
Target version:
-
Start date:
03/06/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2.5
Affected Architecture:

Description

I'm seeing a problem where pfSense starts blocking connections that it had previously been allowing through. When this happens, simply rebooting pfSense fixes the problem. This seems to occur periodically when there are firewall rules that refer to aliases.

Here is my situation:

I have a alias by the name of "MailOut" that maps to the value "smtp.comcast.net, smtp.googlemail.com"

I have firewall rules that refer to this MailOut alias, in this case passing outgoing traffic from the LAN net to the MailOut alias for smtp ports.

Everything will work just fine for weeks to months, but sooner or later my mail starts getting blocked. When that happens, simply rebooting pfSense fixes the problem.

I haven't been able to reliably confirm all the details, but what I suspect is happening is that when a firewall rule is created that refers to an alias, and that alias in turn is based on DNS hostname(s) rather than pure ip address(es), then a dns lookup is done and the resulting ip address(es) are used to create the firewall rule. However, I suspect this dns lookup is only happening once when the rule is first created, and then again at bootup. It does not appear to be periodically refreshed during normal operation of the system.

The result of this is that if the upstream DNS owner updates their DNS mappings, pfSense doesn't notice the change, and therefore does not update the firewall rules. What probably should happen is pfSense should note the TTL when the DNS lookup for the alias is done, and then when that TTL expries, it should requery DNS and update any firewall rules that were created based on that alias.

I'm not sure if it's relevant, but I happen to still be using the dnsmasq based forwarder instead of the newer one. I'm reporting this on version 2.2.6, but as I write this 2.2.5 is the newest option I can pick on the redmine Affected Version dropdown.

Actions
Copy link

Also available in: Atom PDF