pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162019-06-05T13:24:48ZpfSense bugtracker
Redmine pfSense - Feature #9575 (New): RFC 7078 - Distributing Address Selection Policy Using DHCPv6https://redmine.pfsense.org/issues/95752019-06-05T13:24:48ZCarsten Grafflage
<p>Hi,</p>
<p>would it be possible to implement RFC 7078 in pfSense? I guess most of the client systems don't support it yet, but maybe others would follow if you lead. I think this feature should be fairly easy to implement, and could help a lot of people solving different routing issues (for example: Netflix is offering/using IPv6, but is blocking Hurricane Electric IPv6 Tunnel addresses for streaming).</p>
<p>Thanks and Regards,<br />Carsten</p> pfSense - Feature #9336 (New): Make Dynamic DNS update notification e-mail optionalhttps://redmine.pfsense.org/issues/93362019-02-18T10:18:26ZSven L
<p>I'd like to keep pfsense email notifications enabled, unfortunately we have a dynamic ip that changes every day and we use dyndns. That means I get a notification every day when the ip changes and pfsense updates dyndns. Please let me disable this notification for ip changes.</p> pfSense - Bug #9140 (New): Unexpected rule can be displayed when looking up filter log entry with...https://redmine.pfsense.org/issues/91402018-11-20T07:48:51ZS P
<p>When using Port aliases, in the firewall log, when clicking on 'action' the triggering port seems to always be the first of the list.</p>
<p>As for the images, the triggering port is the 21, the port shown in 'detail' is 1001<br />the port list goes something like: 1001, 21, ...</p> pfSense - Feature #8879 (New): DHCP options ADD force optionshttps://redmine.pfsense.org/issues/88792018-09-07T09:11:16Zjonathan MANTOVANI
<p>DHCP server offer the possiblilty to add DHCP options.<br />Maybe add for options the possibility to force the options (with a checkbox).<br />exemple on dnsmasq conf : --dhcp-option-force=208,f1:00:74:7e INSTEADOF --dhcp-option=208,f1:00:74:7e</p> pfSense - Feature #8694 (New): Client CA Auth for PFSense WebGuihttps://redmine.pfsense.org/issues/86942018-07-26T07:13:47ZStefan Bühler
<p>Hi all<br />Could you add the possibility to authentificate with a client certificate for accessing the pfsense webgui</p>
<p>Stefan</p> pfSense - Feature #8599 (New): IPv6 flow labelshttps://redmine.pfsense.org/issues/85992018-06-25T11:38:02ZIsaac McDonald
<p>Here's a short list of possible uses for IPv6 flow labels in pfSense:</p>
<ul>
<li>Ability to apply QOS based on IPv6 flow labels</li>
<li>Using the IPv6 Flow Label for Load Balancing in Server Farms[<a class="external" href="https://tools.ietf.org/html/rfc7098">https://tools.ietf.org/html/rfc7098</a>]</li>
<li>Utilize IPv6 flow labels in Equal Cost MultiPath (ECMP) or Link Aggregation (LAG) implementations [<a class="external" href="https://tools.ietf.org/html/rfc6438">https://tools.ietf.org/html/rfc6438</a>]</li>
</ul>
<p>Windows 10 now populates IPv6 flow labels by default: [[<a class="external" href="https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stack-features-in-the-creators-update-for-windows-10/">https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stack-features-in-the-creators-update-for-windows-10/</a>]]</p>
<p><code>Beginning with the Creators Update, outbound TCP and UDP packets over IPv6 have this field set to a hash of the 5-tuple (Src IP, Dst IP, Src Port, Dst Port). Middleboxes can use the FlowLabel field to perform ECMP for in-encapsulated native IPv6 traffic without having to parse the transport headers. This will make IPv6 only datacenters doing load balancing or flow classification more efficient.</code></p>
<p>FreeBSD also includes support for IPv6 flow labels.</p>
<p>Thanks</p> pfSense - Todo #8270 (New): Fix grammatically erroneous repetitionhttps://redmine.pfsense.org/issues/82702018-01-10T16:06:23ZMaxwell Cody
<p>The pfSense web interface has some grammatically incorrect repetition due to, what I suspect to be, a very lackadaisical use of initialisms. You will notice that on at least four different pages, the phrase "IP Protocol" is used to refer to the delineation between Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6). The grammatical error here is rather simple to notice by simply deconstructing the initialism. By deconstructing the initialism you will see that the deconstructed phrase reads "Internet Protocol Protocol." This is grammatically incorrect.</p>
<p>I've personally come up with two unique and novel solutions to this issue.</p>
<p>1. Change the phrase to read simply "Protocol." <br />2. Change the phrase to read "IP Version." (Deconstructing the initialism here may be preferable)</p>
Pages affected:
<ul>
<li>status_logs_settings.php</li>
<li>diag_testport.php</li>
<li>diag_traceroute.php</li>
<li>diag_ping.php</li>
</ul> 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 - Bug #8157 (New): Traffic Graph clutter from time to timehttps://redmine.pfsense.org/issues/81572017-12-03T06:40:58ZIngo-Stefan Schillingischilling@hotmail.com
<p>When traffic is more occasional with (great) peaks the graph clutters. See attached file. This happens since version 2.4 and is here in 2.4.2-RELEASE (amd64) .</p> pfSense - Feature #7934 (New): format support phone# for international usehttps://redmine.pfsense.org/issues/79342017-10-12T16:10:20ZAdam Thompsonathompso@athompso.net
<p>In the new 2.4.0 release, the Netgate Services and Support dashboard gadget shows the phone# to call. (Good idea, btw!)<br />So that international users know where to call, the phone# should include the country code as "+1".<br />ITU-standard formatting is "+1 (512) 900-2546", but I guess "+1-512-900-2546" would also be recognized by pretty much everyone.<br />You have people in Brazil - check to see which format they would normally expect to see.<br />The important part is the "+" followed by "1", not the punctuation.</p> pfSense - Bug #7857 (New): Interfaces Widget U/I fails to wrap IPV6 addresses when the string is ...https://redmine.pfsense.org/issues/78572017-09-13T03:43:10ZBryan Stenson
<p>Strictly a U/I issue, the widget fails to wrap when the browser window is set small enough to make the string too wide for the box.</p> pfSense - Bug #7648 (New): SPAN ports on an interface renders CARP HA inoperativehttps://redmine.pfsense.org/issues/76482017-06-14T21:05:03ZDavid Van Cleef
<p>When a SPAN port is added to an interface, CARP breaks.</p>
<p>The source address of the CARP announcement, which should be from the IETF VRRP mac range changes to the mac of the physical interface.</p> pfSense - Feature #7030 (New): New Feature Load Balance Per Amount Of GBhttps://redmine.pfsense.org/issues/70302016-12-21T12:45:15Zchristian alfideo arminio
<p><a class="external" href="https://forum.pfsense.org/index.php?topic=122752.0">https://forum.pfsense.org/index.php?topic=122752.0</a></p> pfSense - Feature #6804 (New): Add row counter into Diagnostics -> Edit Filehttps://redmine.pfsense.org/issues/68042016-09-21T21:23:13ZTCI User
<p>Will be extremely helpful if the rows in the Diagnostics -> Edit File window are presented with a number.</p>
<p>In this case you cannot get lost while scrolling up and down into a file.</p>
<p>NOTE: As a work around at the moment I copy the file into my external text editor (Notepad++), make the necessary changes and then copy it back.</p> pfSense - Feature #5835 (New): Improve OpenVPN client gateway detection in edge cases where the r...https://redmine.pfsense.org/issues/58352016-02-01T08:37:46ZJim Pingle
<p>There are a few edge cases where OpenVPN does not set the "route_vpn_gateway" or "ifconfig_remote" environment variables so the "up" script cannot determine the gateway.</p>
<p>Currently the script falls back to using the local IP address in this case, which works OK for some things like policy routing when the interface is assigned, but it causes the wrong IP address to be monitored.</p>
The problem scenario requires BOTH of the following to be true:
<ul>
<li>tap mode OR tun+topology subnet is used</li>
<li>Server does not push ANY routes</li>
</ul>
<p>In that case, the only possible way for the client to determine the gateway is by subnet calculation, assuming the gateway is the first IP address in the block. Our code currently falls back to using the client adapter address in this case when the other two variables are unset.</p>
<p>Fixing it would require the ability to do subnet math or similar calculation from a shell script, or perhaps pulling the config off the interface using ifconfig or another similar function.</p>
<p>Since it appears to work fine from a user perspective aside from picking the right monitor IP address, it's pretty minor as far as I can tell so far.</p>