pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162020-09-30T14:19:21ZpfSense bugtracker
Redmine pfSense Packages - Bug #10941 (Closed): pfBlockerNG-devel Bug in ipv6 lists when updatinghttps://redmine.pfsense.org/issues/109412020-09-30T14:19:21ZRick Coats
<p>I posted initially in the forum with screenshots in case it is something I am doing but during update the pfblocker ipv6 alias's get clobbered in the rules. This has happened before, so it is not a new issue with today's update.</p>
<p>During update the ipv6 Alias's get a _v4 added to the end of the alias name, and it was changed to protocol IPv4. Of course, then the firewall throws all kinds of errors since it doesn't see it as a legit alias. My rules are in an interface group if that makes a difference, but I have seen it happen when I had rules in the WAN interface also in the past.</p>
<p><a class="external" href="https://forum.netgate.com/topic/157274/bug-in-ipv6-lists-when-updating">https://forum.netgate.com/topic/157274/bug-in-ipv6-lists-when-updating</a></p>
<p>Is there a reason why a separate _v4 and _v6 alias needs to be generated? Seems like a single Alias with both types would work just as well.</p>
<p>I am on:<br />pfBlockerNG-devel 2.2.5_35 but it has been in the prior versions also.</p>
<p>2.4.5-RELEASE-p1 (amd64)<br />built on Tue Jun 02 17:51:17 EDT 2020<br />FreeBSD 11.3-STABLE</p> pfSense - Bug #10694 (Resolved): Firewall Alias does not allow an ipv6 network alias in the forma...https://redmine.pfsense.org/issues/106942020-06-23T23:00:23ZRick Coats
<p>Firewall Alias does not allow an ipv6 network alias in the format described by RFC4291 par 2.2.2 in the format x:x:x:x:x:x:d.d.d.d where the 'd's are the decimal values of the four low-order 8-bit pieces of the address (standard IPv4 representation).</p>
<p>Example:<br />If I was using NAT64 I would like to create an alias for network 64:ff9b::10.11.12.0/120 to correspond to 10.11.12.0/24<br />The Error I get is:</p>
<p>The following input errors were detected:</p>
<p>64:ff9b::10.11.12.0/120 is not a valid subnet.</p>
<p>I can add individual hosts (64:ff9b::10.11.12.13) as an alias but not the network alias.</p> pfSense - Bug #10586 (Duplicate): IPv6 interfaces seem to have hardcoded Link Local Address https://redmine.pfsense.org/issues/105862020-05-22T17:06:16ZRick Coats
<p>The link-local address of each non-WAN interface seems to be hard coded to fe80::1:1. This causes a problem when multiple pfSense routers are connected to the same layer 2.</p>
<p>An example of where this would be a problem would be when you have multiple WAN interfaces with different prefixes being used for redundant paths. You can not have multiple nodes using the same link-local address on one network.</p>
<p>One solution would be to use the same process as is used on the WAN interface Link-Local Address on all of the interfaces. This appears to be via SLAAC and but regardless it should perform Duplicate Address Detection.</p> pfSense Packages - Feature #10547 (New): Add package addrwatch. Addrwatch is like arpwatch but w...https://redmine.pfsense.org/issues/105472020-05-10T20:10:46ZRick Coats
<p>From the developer website:</p>
<blockquote>
<p>This is a tool similar to arpwatch. It main purpose is to monitor network and log discovered ethernet/ip pairings.</p>
<p>Main features of addrwatch:</p>
<p>IPv4 and IPv6 address monitoring<br />Monitoring multiple network interfaces with one daemon<br />Monitoring of VLAN tagged (802.1Q) packets.<br />Output to stdout, plain text file, syslog, sqlite3 db, MySQL db<br />IP address usage history preserving output/logging<br />Addrwatch is extremely useful in networks with IPv6 autoconfiguration (RFC4862) enabled. It allows to track IPv6 addresses of hosts using IPv6 privacy extensions (RFC4941).</p>
</blockquote>
<p>It has already been added as a package to the FreeBSD Ports<br /><a class="external" href="https://github.com/pfsense/FreeBSD-ports/tree/devel/net/addrwatch">https://github.com/pfsense/FreeBSD-ports/tree/devel/net/addrwatch</a></p>
<p>Example system log entries generated by addrwatch installed on a FreeBSD 11.3 system(cleaned up ipv6):</p>
<blockquote>
<p>addrwatch 1589156272 hn0 0 e0:33:8e:28:a1:95 10.23.30.240 ARP_REQ<br />addrwatch 1589156274 hn0 0 02:15:5d:0a:0a:03 10.23.30.117 ARP_REP<br />addrwatch 1589156331 hn0 0 02:15:5d:0a:0a:03 fe80::15:5dff:fe0a:a03 ND_NS<br />addrwatch 1589156349 hn0 0 e0:33:8e:28:a1:95 fe80::18cf:72c4:e997:8617 ND_DAD<br />addrwatch 1589156350 hn0 0 d0:03:4b:01:4a:4d fe80::20:b2d3:f1eb:443b ND_NS<br />addrwatch 1589156350 hn0 0 44:61:32:ca:4d:d6 fe80::4661:32ff:feca:4dd6 ND_NS<br />addrwatch 1589156350 hn0 0 44:61:32:68:e4:07 fe80::4661:32ff:fe68:e407 ND_NS<br />addrwatch 1589156350 hn0 0 e0:33:8e:28:a1:95 2605:xxxx:xxxx:xxxx:xxxx:d8b0:c2bf:1f4a ND_DAD<br />addrwatch 1589156350 hn0 0 e0:33:8e:28:a1:95 2605:xxxx:xxxx:xxxx:xxxx:9676:d3b1:dd7b ND_DAD<br />addrwatch 1589156350 hn0 0 02:15:5d:ff:2b:0b fe80::1:1 ND_NS<br />addrwatch 1589156377 hn0 0 64:52:99:23:65:9b 10.23.30.40 ARP_REQ<br />addrwatch 1589156379 hn0 0 02:15:5d:ff:2b:0b 2605:xxxx:xxxx:xxxx:xxxx:5dff:feff:2b0b ND_NS<br />addrwatch 1589156380 hn0 0 e0:33:8e:28:a1:95 10.23.30.240 ARP_REQ</p>
</blockquote>
<p>Developer: WWW: <a class="external" href="https://github.com/fln/addrwatch">https://github.com/fln/addrwatch</a></p> pfSense - Feature #10204 (New): Possible clarification of Track IPv6 Interface Subnet IDhttps://redmine.pfsense.org/issues/102042020-01-23T13:04:19ZRick Coats
<p>On the Interface Configuration / Track IPv6 Interface:<br />Suggest change “IPv6 Prefix ID” to “IPv6 Subnet ID” or “IPV6 Prefix Subnet ID”</p>
<p>Reason:<br />I have seen some confusion by those new to IPv6 that this field is referring to the subnet ID. This might be clearer if it is more in agreement with "RFC 4291 IP Version 6 Addressing Architecture" terminology. </p>
<pre><code>2.5.4. Global Unicast Addresses<br /> The general format for IPv6 Global Unicast addresses is as follows:</code></pre>
<pre><code>| n bits | m bits | 128-n-m bits |<br /> <ins><del>----------------------</del></ins>-----------+----------------------------+
| global routing prefix | subnet ID | interface ID |<br /> <ins><del>----------------------</del></ins>-----------+----------------------------+<br /> where the global routing prefix is a (typically hierarchically-<br /> structured) value assigned to a site (a cluster of subnets/links),<br /> the subnet ID is an identifier of a link within the site, and the<br /> interface ID is as defined in Section 2.5.1.</code></pre>
<p>Also in Section 2.</p>
<pre><code>In this document, fields in addresses are given a specific name, for<br /> example, "subnet". When this name is used with the term "ID" for<br /> identifier after the name (e.g., "subnet ID"), it refers to the<br /> contents of the named field. When it is used with the term "prefix" <br /> (e.g., "subnet prefix"), it refers to all of the address from the<br /> left up to and including this field.</code></pre> pfSense - Bug #9893 (Duplicate): RDNSS is broken in 2.5 for Android and leightweight Clients https://redmine.pfsense.org/issues/98932019-11-11T17:10:52ZRick Coats
<p>Version of PfSense under Test:<br />2.5.0-DEVELOPMENT (amd64)<br />built on Sun Nov 10 20:08:03 EST 2019<br />FreeBSD 12.0-RELEASE-p10</p>
<p>The changes in <a class="external" href="https://redmine.pfsense.org/issues/9302">https://redmine.pfsense.org/issues/9302</a> break RDNSS when using Managed or Stateless DHCP on the RA Tab of the DHCPv6 Server & RA Setup.</p>
<p>Looking in the /var/etc/radvd.conf shows the RDNSS and DNSSL entries are missing.</p>
<p>The effect is that clients which do not utilize DHCP for DNS (ie Android and other light weight devices ) no longer get DNS information. It should be noted that these clients work as expected in 2.4.4 and even with Managed or Stateless DHCP it is a valid use case that these clients are to work.</p>
<p>Fix would be to roll back change 9302.</p>
<p>Bug 9302 should never have been accepted as a bug. pfSense was working correctly per RFC before change 9302 was incorporated.</p>
<p>RFC 8504 Chapter 8 provides overview of Configuring Non-Address Information and states that IPv6 Router Advertisement Implementations MUST include support for the DNS RA option [RFC8106]. This has been in effect since 2017.</p>
<p>This is regardless of the Flags (M or O) as these are to inform the client of the availability of a DHCP server, not to tell the router to turn off Router Announcement Functionality.</p>
<p>RFC 8106 Chapter 5.3 spells out what hosts are to do when they receive DNS Servers from both DHCPv6 and RDNSS.</p>
<p>In my production Network using 2.4.4 with Stateless DHCP, a Windows ipconfig /all shows:<br /><pre>
DNS Servers . . . . . . . . . . . : 2605:e000:fe8c:8f64:a:b:c:2b0b (address of pihole DNS provided by DHCPv6)
10.23.64.15 (address of pihole DNS provided by DHCPv4)
2605:e000:fe8c:8f10:a:b:c::2b01 (address of System DNS provided by RDNSS)
</pre></p>
<p>The Windows machine will use the DNS servers in the order as shown as is required by RFC 8106. In my configuration if the pihole server DNS were to go down then the system DNS will still be operational. This is especially useful if the prefix provided by the ISP were to change as the DHCP DNS servers will have to be manually edited, but system DNS is automatically updated to the new prefix.</p>
<p>In the Test of 2.5.0 the last entry is no longer being provided via RDNSS so there is no way to provide the system DNS as the fallback DNS.</p>
<p>I left more feedback at <a class="external" href="https://redmine.pfsense.org/issues/9302">https://redmine.pfsense.org/issues/9302</a></p> pfSense - Bug #9654 (New): After reboot, the DNS resolver must be restarted before it will advert...https://redmine.pfsense.org/issues/96542019-07-28T14:53:03ZRick Coats
<p>When pfsense ipv6 is configured with DHCPv6 disabled and RA in "Unmanaged" mode, then after reboot, until the resolver is restarted the DNS does not know that the router has an ipv6 address.</p>
<p>In my configuration I have the DCHP Registration unchecked in the resolver, so I do not have unbound getting restarted due to DHCP events.</p>
<p>After reboot, with a working ipv6 setup, if you go to Diagnostics/DNS lookup and lookup pfsense.mydomain.com, it will only reply with ipv4 address of router.</p>
<p>Examining /var/unbound/host_entries.conf I see that the local-data: lines for the ipv6 for router are missing.</p>
<p>Looking at /var/etc/radvd.conf is missing a lot of information as if it hasn't been configured yet.</p>
<p>Packet capture of RA packets show that indeed, the DNS is not being advertised.</p>
<p>Manually restarting unbound service fixes all of this and it is good until next reboot.</p>
<p>Posted at:<br /><a class="external" href="https://forum.netgate.com/topic/145162/after-reboot-the-dns-resolver-must-be-restarted-before-it-will-advertise-the-ipv6-address-of-the-resolver">https://forum.netgate.com/topic/145162/after-reboot-the-dns-resolver-must-be-restarted-before-it-will-advertise-the-ipv6-address-of-the-resolver</a></p>
<p>I am running 2.4.4-RELEASE-p3 (amd64) <br />Installed Packages (latest version):<br />acme<br />Avahi <br />nut<br />openvpn-client-export</p> pfSense - Bug #8977 (Resolved): Dynamic DNS - Custom (V6) - Throws Error "php-fpm: /services_dynd...https://redmine.pfsense.org/issues/89772018-09-29T16:51:48ZRick Coats
<p>The Dynamic DNS - Custom (v6) when it runs, throws the following error, even though it successfully updated:<br />php-fpm: /services_dyndns_edit.php: phpDynDNS: (ERROR!) No Hostname Provided.</p>
<p>Since there is no Hostname provided for Custom (v6) this is an error but has no impact since it still works.<br />It should be noted that the v4 version of custom does not throw the error.</p>
<p>Looking in the source at <a class="external" href="https://github.com/pfsense/pfsense/blob/master/src/etc/inc/dyndns.class#L261">https://github.com/pfsense/pfsense/blob/master/src/etc/inc/dyndns.class#L261</a><br />Line 261 has case 'custom"</p>
<p>I think there should be an additional line below 261</p>
<p>case 'custom-v6':</p>
<p>This would have 'custom' and 'custom-v6' act the same.</p> pfSense Docs - Correction #8865 (Rejected): Feedback on Networking Concepts — IPv6 — IPv6 Subnettinghttps://redmine.pfsense.org/issues/88652018-08-31T22:40:00ZRick Coats
<p><strong>Page:</strong> <a class="external" href="https://www.netgate.com/docs/pfsense/book/network/ipv6-subnets.html">https://www.netgate.com/docs/pfsense/book/network/ipv6-subnets.html</a></p>
<p><strong>Feedback:</strong><br />IPv6 Subnet Table <br />IPv6 Subnet Table shows examples of Prefix with numbers greater than 64 (ie 68 – 128). In reality ipv6 subnets cannot be greater than /64. <br />Per RFC 4291 Section 2.5.4. Global Unicast Addresses<br />“All Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in Section 2.5.1.”<br />IPv6 global unicast addresses consist of 64 bits of global routing prefix and subnet ID and 64 bits of interface ID. The only special exceptions are those which are granted to large ISPs for point to point links, but these must be kept separate from the rest of IPv6 since they break IPv6.<br />So that new users are not confused it would be better to delete the table lines after 64 prefix.</p>
<p>The paragraph:<br />“Assignments larger than /64 usually adopt the first /64 for LAN and subdivide the rest for requirements such as VPN tunnel, DMZ, or a guest network.”<br />Should be just deleted since it isn’t allowed in the RFC IPv6 spec to subdivide a /64 in the general user case, especially not in the specific examples given.</p>