pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162019-08-19T12:57:00ZpfSense bugtracker
Redmine pfSense - Bug #9689 (Duplicate): DHCP server should be able to advertise interface IP automatical...https://redmine.pfsense.org/issues/96892019-08-19T12:57:00ZChaos215 Bar2
<p>The text below the "DNS servers" fields on the DHCP server configuration reads "Leave blank to use the system default DNS servers: this interface's IP if DNS Forwarder or Resolver is enabled, otherwise the servers configured on the System / General Setup page.".</p>
<p>This is limiting, when using an alternative DNS service (such as the BIND package), especially for IPv6 where IPs are likely not to be static. There should be a way to access the later part of this functionality, advertising the interface IP as the DNS server, even without the DNS forwarder or resolver packages enabled.</p>
<p>The request is for a checkbox to tell the DHCP server to advertise an interface's IP address as the DNS server rather than defaulting to the servers configured on the System / General Setup page, as the servers used by the router for DNS resolution may well not be what you want to advertise to clients. This does not require any knowledge of the fact that a DNS server is or is not running on the interface; if one isn't, then DNS resolution will simply be broken for DHCP clients until the admin fixes the misconfiguration.</p> pfSense - Feature #8257 (Resolved): pfSense Diagnostics -> Packet Capture support for loopback in...https://redmine.pfsense.org/issues/82572018-01-04T18:47:06ZChaos215 Bar2
<p>I can't overstate how useful the GUI Packet Capture feature is for debugging all variety of networking issues, but it's missing an option to capture traffic on the loopback interface. This would be a very useful and, I believe, fairly simple feature to implement.</p> pfSense - Feature #8236 (New): Ability to configure "forward-first" and "forward-host" options fo...https://redmine.pfsense.org/issues/82362017-12-25T23:43:57ZChaos215 Bar2
<p>It would be great to have the option to configure both forward-first (a simple checkbox) and forward-host (perhaps an extension of the "IP Address" field currently provided) directives for domain overrides, as the current option to configure only an explicit IP address via forward-addr is limiting and can lead to fragile configurations.</p>
<p>My specific use case is a split DNS configuration where the internal DNS server lies on the other side of a site-to-site VPN tunnel. If the tunnel goes down, without a "forward-first yes" on the zone, all DNS resolution under my hostname will fail rather than simply falling back to the publicly routable IPs everyone outside my network sees. This also makes handling of the VPN server's FQDN itself difficult, as I must either define it explicitly as a host override or place it under a different domain which is not forwarded. Again, the forward-first directive should handle this automatically.</p>
<p>It would also be very useful to have the option to specify a FQDN for a domain override. There are any number of reasons a privately operated DNS server might need to change IPs, but ensuring the server is resolvable via public DNS record would mitigate this.</p> pfSense - Feature #8234 (Rejected): DHCP server should be able to advertise interface IP automati...https://redmine.pfsense.org/issues/82342017-12-22T22:01:03ZChaos215 Bar2
<p>The text below the "DNS servers" fields on the DHCP server configuration reads "Leave blank to use the system default DNS servers: this interface's IP if DNS Forwarder or Resolver is enabled, otherwise the servers configured on the System / General Setup page.".</p>
<p>This is limiting, when using an alternative DNS service (such as the BIND package), especially for IPv6 where IPs are likely not to be static. There should be a way to access the later part of this functionality, advertising the interface IP as the DNS server, even without the DNS forwarder or resolver packages enabled.</p> pfSense - Bug #8233 (New): NAT reflection back to originating host broken when using FQDN-based I...https://redmine.pfsense.org/issues/82332017-12-22T12:46:33ZChaos215 Bar2
<p>It appears NAT reflection is slightly broken when targeted at an IP alias which is defined via FQDN (rather than IP address). In this case, reflection works from hosts on subnets other than the one that the NAT target is on, but not from the same subnet. Within the same subnet, it appears traffic it redirected to the target host, but the originating IP is not translated.</p>
<p>To put this in context, let's say I have a host ns.example.com at IP 10.0.0.10, and I want to redirect traffic sent to 1.2.3.4 to this host. Let's say I create an alias "NameServer", and create a NAT rule to translate traffic arriving on the WAN interface destined for the address 1.2.3.4, port 53 to "NameServer" port 53, and enable reflection. ("Enable NAT Reflection for 1:1 NAT" and "Enable automatic outbound NAT for Reflection" are enabled and 1.2.3.4 is an IP alias with an outbound NAT rule mapping traffic from "NameServer" to the NAT address 1.2.3.4, FWIW.)</p>
<p>If the alias "NameServer" points at the FQDN ns.example.com (which resolved internally to 10.0.0.10), then I run into this problem. If I make a DNS request to 1.2.3.4 from outside the server's subnet (let's say outside 10.0.0.0/24), everything is fine (even from interfaces other than WAN, so reflection is working… sort of). If I make a request from within the same subnet, I do see a response, but it comes directly from 10.0.0.10, not 1.2.3.4. (i.e. The request packet was clearly redirected to 1.2.3.4, but it doesn't actually seem to have gone through NAT.)</p>
<p>If the alias "NameServer" points at the IP 10.0.0.10, then everything works, and I see several <em>additional</em> translation rules:<br /><pre>
no nat on lagg0 inet proto tcp from 10.0.0.1 to <NameServer> port = domain
no nat on lagg0 inet proto udp from 10.0.0.1 to <NameServer> port = domain
nat on lagg0 inet proto tcp from 10.0.0.0/24 to <NameServer> port = domain -> 10.0.0.1 port 1024:65535
nat on lagg0 inet proto udp from 10.0.0.0/24 to <NameServer> port = domain -> 10.0.0.1 port 1024:65535
</pre></p>
<p>These are in addition to rules of the following form, that exist either way:<br /><pre>
nat on igb1 inet from <NameServer> to any -> 1.2.3.4 static-port
no rdr proto carp all
rdr-anchor "relayd/*" all
rdr-anchor "tftp-proxy/*" all
<Above rules here>
rdr on igb1 inet proto tcp from any to 1.2.3.4 port = domain -> <NameServer> round-robin
rdr on igb1 inet proto udp from any to 1.2.3.4 port = domain -> <NameServer> round-robin
rdr on igb0 inet proto tcp from any to 1.2.3.4 port = domain -> <NameServer> round-robin
rdr on igb0 inet proto udp from any to 1.2.3.4 port = domain -> <NameServer> round-robin
rdr on lagg0 inet proto tcp from any to 1.2.3.4 port = domain -> <NameServer> round-robin
rdr on lagg0 inet proto udp from any to 1.2.3.4 port = domain -> <NameServer> round-robin
</pre></p>
<p>(The DNS server is located on lagg0, on which the router has the IP 10.0.0.1. igb1 is WAN, and igb0 is the regular LAN interface.)</p>
<p>It appears the problem is that pfSense can't resolve the interface the host pointed to by "NameServer" will lie on at the time of rule creation, so is unable to create the necessary NAT rules to allow reflection to work within the same subnet. Perhaps either a new kind of "rdr" style rule that performs NAT when reflecting back out to the same subnet is necessary, or an option to specify an interface in addition to (perhaps connected to) a host alias is needed, to enable creation of these rules.</p> pfSense Packages - Feature #8210 (Rejected): DHCP servers do not automatically advertise interfac...https://redmine.pfsense.org/issues/82102017-12-14T21:32:45ZChaos215 Bar2
<p>The text on the DNS Servers field of the DHCP server configuration pages reads "Leave blank to use the system default DNS servers, this interface's IP if DNS forwarder is enabled, or the servers configured on the "General" page.". This should apply to the BIND package as well. Alternatively, there should be a checkbox to enable this option regardless of whether the DNS forwarder or resolver packages are currently enabled.</p> pfSense Packages - Feature #8199 (New): Support reordering and/or sort alphabetically across BIND...https://redmine.pfsense.org/issues/81992017-12-12T02:05:41ZChaos215 Bar2
<p>The BIND package has many lists (ACLs, Views, Zones, Zone Domain records, etc.) whose order seems to be fixed permanently and defined by the order in which the entries were created. This can quickly make it difficult to locate entries as the lists grow organically, and there's no easy way to correct the ordering. The lists should either simply be sorted in some well-defined order, to make it easy to locate entries, or, for bonus points, allow manual reordering.</p> pfSense Packages - Bug #8197 (New): BIND UI fails to properly update zone with inline DNSSEC sign...https://redmine.pfsense.org/issues/81972017-12-12T01:56:29ZChaos215 Bar2
<p>2.4.2-RELEASE with BIND 9.11_9 on SG-4860</p>
<p>Steps to reproduce:<br />1) Install pfSense 2.4.2-RELEASE and the BIND package, and setup a standard configuration with LAN and WAN port.<br />2) Disable built-in DNS Resolver and DNS Forwarder packages.<br />3) Enable BIND and configure it to listen on all interfaces. Confirm BIND responds to requests on the LAN interface IP.<br />4) Configure a master zone for the domain of your choice, enable inline DNSSEC signing on this zone, and confirm BIND responds to requests for DNS records in this zone.<br />5) Add a new A record for the host "test" under this zone, with the IP of your choice, and save. At this point, BIND should respond to requests for this host.<br />6) Remove this host "test", and save. At this point, BIND still responds to requests for the now-deleted record.</p>
<p>I've confirmed that the zone's ".DB" file (in /cf/named/etc/namedb/master/<view>) is correct at this point, but the problem seems to be one or more of the ".DB.jbk", ".DB.signed", and ".DB.signed.jnl" files. Disabling inline DNSSEC signing in the UI will correct the problem with no further action, at the expense of DNSSEC of course. Removing these three files and restarting BIND also appears to correct the problem by causing the files to be regenerated without the now-removed DNS record. Presumably the UI is missing some step that should cause this update to occur in a less destructive manner.</p> pfSense Packages - Bug #8195 (Closed): BIND packages launches two instances of /usr/local/sbin/na...https://redmine.pfsense.org/issues/81952017-12-12T01:47:20ZChaos215 Bar2
<p>2.4.2-RELEASE with BIND 9.11_9 on SG-4860</p>
<p>With the BIND package installed and enabled, I see two identical "/usr/local/sbin/named -c /etc/namedb/named.conf -u bind -t /cf/named/" processes running after a reboot. This does not appear to affect functionality (presumably one simply fails to bind to any interfaces), but nevertheless seems like behavior that should be fixed.</p> pfSense Packages - Bug #8194 (Closed): BIND fails to respond after interface goes downhttps://redmine.pfsense.org/issues/81942017-12-12T01:44:35ZChaos215 Bar2
<p>2.4.2-RELEASE with BIND 9.11_9 on SG-4860</p>
<p>Steps to reproduce:<br />1) Install pfSense 2.4.2-RELEASE and the BIND package, and setup a standard configuration with LAN and WAN port.<br />2) Disable built-in DNS Resolver and DNS Forwarder packages.<br />3) Enable BIND and configure it to listen on all interfaces. Confirm BIND responds to requests on the LAN interface IP.<br />4) Disconnect and reconnect cable to the router's LAN port.<br />5) Router no longer responds to DNS queries on its LAN interface IP.</p>
<p>This behavior is also triggered if an attached switch is rebooted, causing the LAN interface to go down briefly, or even when powering both the router and the switch on, if the switch is slower to come up than the router. And configuration changes to the BIND packages will cause it to once again listen on all interfaces that are up at the time of the settings change.</p> pfSense - Bug #8179 (Resolved): Incorrect reverse DNS zone in DHCP server config for non-octet-al...https://redmine.pfsense.org/issues/81792017-12-10T21:27:50ZChaos215 Bar2
<p>I have a DHCP server running on pfSense 2.4.2 on an interface with subnet 172.24.208.0 and subnet mask 255.255.254.0. Upon configuring dynamic DNS, I saw that regular DNS records were being correctly inserted into my DNS server, but PTR records were not. Near the bottom of /var/dhcpd/etc/dhcpd.conf, I found the following:<br /><pre>
zone 0-23.208.24.172.in-addr.arpa {
primary 127.0.0.1;
}
</pre><br />This should have been:<br /><pre>
zone 208-209.24.172.in-addr.arpa {
primary 127.0.0.1;
}
</pre></p>
<p>The code responsible is in /etc/inc/services.inc. I believe I was able to restore correct behavior by replacing the entire <code>switch ($ifcfgsn)</code> statement with the following:<br /><pre>
$subnet_mask_bits = 32 - $ifcfgsn;
$start_octet = $subnet_mask_bits >> 3;
$octet_mask_bits = $subnet_mask_bits & 3;
if ($octet_mask_bits) {
$octet_mask = (1 << $octet_mask_bits) - 1;
$octet_start = $revsubnet[$start_octet] & ~$octet_mask;
$revsubnet[$start_octet] = $octet_start . "-" . ($octet_start + $octet_mask);
}
</pre><br />(Please use the above as a reference only; the code could undoubtably be improved.)</p>