pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162023-10-11T07:53:52ZpfSense bugtracker
Redmine pfSense Packages - Feature #14863 (New): WireGuard suppport for aliaseshttps://redmine.pfsense.org/issues/148632023-10-11T07:53:52ZBob Dig
<p>Allow to use aliases in "Allowed IPs" in the WireGuard Peer config. That would match with the general ability to use aliases for static routes in pfSense, see <a class="external" href="https://forum.netgate.com/topic/183339/feature-request-support-for-aliases">https://forum.netgate.com/topic/183339/feature-request-support-for-aliases</a>.</p> pfSense - Bug #14604 (New): Bugs in dhclient implementation according to RFC 2131https://redmine.pfsense.org/issues/146042023-07-23T14:11:19ZNazar Mokrynskyi
<p>I had issues with one of the ISPs on pfSense and after talking to their tech support and observing what is happening I believe there are bugs in dhclient used by pfSense.<br />It is likely an upstream issue, but I don't use FreeBSD, so I report it here.<br />This is what triggers <a class="external" href="https://redmine.pfsense.org/issues/14237">https://redmine.pfsense.org/issues/14237</a> (which I believe is a buggy gateway groups implementation in pfSense and is a distinct issue, this one is just one way to trigger it, but maybe not the only one).</p>
<p>Dump of communication between pfSense and DHCP server of ISP is also attached.<br />The issue happened on 2.6.x and still happens on 2.7.0 that I'm currently running.</p>
<p>Below is basically an English translation of the response from IPS support representative.</p>
<p>The first thing that is believed to be handling DHCPDISCOVER. According to RFC 2131:<br /> The client begins in INIT state and forms a DHCPDISCOVER message.<br /> The client SHOULD wait a random time between one and ten seconds to<br /> desynchronize the use of DHCP at startup.</p>
<p>So client must wait for DHCPOFFER up to 10 seconds. During this time client can receive answers from multiple DHCP servers and pick settings it prefers.</p>
<p>The other issue is that according to RFC 2131 Unicast request Request Renew must be done between T1 and T2. Time approximately equal tothe lease time<br />(with slight random offset) - T1 timer. pfSense's dhclient only uses T2 (0.85*lease time), this is not quite correct, request according to T2 timer is usually<br />done in case first request to extend lease failed (depends on implementation and DHCP client settings). According to RFC after T2 time client must switch to<br />REBINDING and make boardcast request, which is what happened. If cient doesn't send request/doesn't receive response within lease time then settings must be<br />cleared and procedure of obtaining IP address start over.<br />Current lease time is 10 minutes (600 seconds).<br />Separately sometimes dhclient doesn't send DHCPREQUEST within lease time, for instance record <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Todo: PPTP users integration with user manager (Closed)" href="https://redmine.pfsense.org/issues/34">#34</a> and 37, between then there was more than 600 seconds and<br />procedure to get IP address started over, which is when Internet access was temporarily lost.</p> pfSense - Bug #14397 (New): DHCPv4 client (dhclient) does not use 802.1p Priority tagging on DHCP...https://redmine.pfsense.org/issues/143972023-05-19T14:52:52ZTue Madsen
<p>Some ISPs using VLANs for service, require DHCPv4/v6 Frames to be 802.1p priority tagged. <br />pfSense has the option to do this by either:<br />- Setting VLAN priority tagging in the Interface DHCP options (if you are not using Advanced configuration or a predefined configuration file)<br />- If using advanced configuration: By adding “vlan-pcp x” in the advanced modifier options.</p>
<p>BUG:<br />This priority setting in only used in DISCOVER and RELEASE frames sent by dhclient - NOT in RENEW or REBIND.</p>
<p>This is now causing major problems in France where Orange (Major ISP) has upgraded to also requiring the RENEW frames to be properly VLAN Priority tagged.<br />This causes the uplink to stop working when a renew is due. (About once a day)</p>
<p>I don’t know if the issue is the same in DHCPv6</p>
<p>The issue was patched in OPNsense about a month ago, and they decided to drop the advanced options overwrite of the VLAN priority setting in interface DHCP options. <br />Instead they let the user choose if VLAN priority should be used via the interface DHCP VLAN Priority setting already available. <br />If selected it would - apart from adding “vlan-pcp x” to the dhclient config - also set the priority tag in the builtin pffilter rule that passes Interface DHCP client traffic. This adds the tag to RENEW and REBIND frames.</p>
<p>The issue occurs because dhclient uses a bfg interface for DISCOVER and RELEASE - thus respecting the vlan-pcp settings. But for RENEW it uses a simple socket, and that causes it not to be tagged correctly. In pfSense you cannot create a floating match rule to manually tag the traffic that has higher priority than the builtin pass quick rule for the interface DHCP client.</p> pfSense Packages - Todo #14333 (New): Reduce config writeshttps://redmine.pfsense.org/issues/143332023-05-01T15:28:11ZMarcos M
<p>When the service is started, multiple config writes are performed. System logs (reversed) show:<br /><pre>
May 1 09:12:32 check_reload_status 1213 Reloading filter
May 1 09:12:31 check_reload_status 1213 Syncing firewall
May 1 09:12:31 php_wg 15988 /usr/local/pkg/wireguard/includes/wg_service.inc: Configuration Change: (system): [pfSense-pkg-WireGuard] Applied package default settings as necessary.
May 1 09:12:31 php_wg 15988 /usr/local/pkg/wireguard/includes/wg_service.inc: Configuration Change: (system): [pfSense-pkg-WireGuard] Installed Unbound ACL group (WireGuard).
May 1 09:12:30 php_wg 15988 /usr/local/pkg/wireguard/includes/wg_service.inc: Configuration Change: (system): [pfSense-pkg-WireGuard] De-installed Unbound ACL group (WireGuard).
May 1 09:12:30 php_wg 15988 /usr/local/pkg/wireguard/includes/wg_service.inc: Configuration Change: (system): [pfSense-pkg-WireGuard] Installed interface group (WireGuard).
May 1 09:12:30 php_wg 15988 /usr/local/pkg/wireguard/includes/wg_service.inc: Configuration Change: (system): [pfSense-pkg-WireGuard] De-installed interface group (WireGuard).
May 1 09:12:30 check_reload_status 1213 Syncing firewall
May 1 09:12:30 php_wg 15988 /usr/local/pkg/wireguard/includes/wg_service.inc: Configuration Change: (system): [pfSense-pkg-WireGuard] Installed earlyshellcmd(s).
May 1 09:12:30 check_reload_status 1213 Syncing firewall
May 1 09:12:30 php_wg 15988 /usr/local/pkg/wireguard/includes/wg_service.inc: Configuration Change: (system): [pfSense-pkg-WireGuard] De-installed earlyshellcmd(s).
May 1 09:12:29 kernel tun_wg0: link state changed to UP
May 1 09:12:29 kernel wg0: changing name to 'tun_wg0'
May 1 09:12:28 check_reload_status 1213 Syncing firewall
May 1 09:12:28 php_wg 15988 /usr/local/pkg/wireguard/includes/wg_service.inc: Configuration Change: (system): [pfSense-pkg-WireGuard] Applied package default settings as necessary.
May 1 09:12:28 php_wg 15988 /usr/local/pkg/wireguard/includes/wg_service.inc: Configuration Change: (system): [pfSense-pkg-WireGuard] Installed Unbound ACL group (WireGuard).
May 1 09:12:28 php_wg 15988 /usr/local/pkg/wireguard/includes/wg_service.inc: Configuration Change: (system): [pfSense-pkg-WireGuard] De-installed Unbound ACL group (WireGuard).
May 1 09:12:28 php_wg 15988 /usr/local/pkg/wireguard/includes/wg_service.inc: Configuration Change: (system): [pfSense-pkg-WireGuard] Installed interface group (WireGuard).
May 1 09:12:28 php_wg 15988 /usr/local/pkg/wireguard/includes/wg_service.inc: Configuration Change: (system): [pfSense-pkg-WireGuard] De-installed interface group (WireGuard).
May 1 09:12:27 check_reload_status 1213 Syncing firewall
May 1 09:12:27 php_wg 15988 /usr/local/pkg/wireguard/includes/wg_service.inc: Configuration Change: (system): [pfSense-pkg-WireGuard] Installed earlyshellcmd(s).
May 1 09:12:27 check_reload_status 1213 Syncing firewall
May 1 09:12:27 php_wg 15988 /usr/local/pkg/wireguard/includes/wg_service.inc: Configuration Change: (system): [pfSense-pkg-WireGuard] De-installed earlyshellcmd(s).
May 1 09:12:26 php-fpm 4806 /status_services.php: The command '/usr/local/etc/rc.d/wireguardd stop' returned exit code '1', the output was ''
May 1 09:12:17 kernel tun_wg0: link state changed to DOWN
</pre></p>
<p>This leads to 4 new config history entries. Since this happens any time packages are restarted (e.g. due to WAN events), it adds up quickly. The issue is compounded when ACB is enabled and set to back up on config changes rather than a schedule.</p>
<p>Additionally, it seems there may be an error here:</p>
<blockquote>
<p>May 1 09:12:26 php-fpm 4806 /status_services.php: The command '/usr/local/etc/rc.d/wireguardd stop' returned exit code '1', the output was ''</p>
</blockquote> pfSense Plus - Feature #13740 (New): Feature Request: Mark Boot Environments with different prope...https://redmine.pfsense.org/issues/137402022-12-09T14:04:10ZJonas R
<p>Boot snapshots are awesome. However. I see huge potential for expanding the features on these. So here are a few suggestions</p>
<p>Mark a snapshot as forbidden to boot.<br />This comes from a weird situaton from my 6100. Where the first boot would work just perfectly. However, ever subsequent boot would result in a completely broken LAN. So I had to be suuuper careful not to boot the last remaining snapshot of my "working" system whilst trouble shooting. But if I had been able to mark it so it wasn't allowed to be booted. Then this would've been real handy.</p>
<p>Mark snapshot with Deletion Prevention:<br />This is basically an option to mark a specific snapshot so that it isn't allowed to be deleted, whilst the "Prevent from being deleted"-flag is set. Or something similar. Suggestion is to have it as a check box from within the edit-page. This could then disable the Trash-icon on the main paige.</p> pfSense Packages - Feature #13474 (New): Don't set ListenPort in wireguardhttps://redmine.pfsense.org/issues/134742022-09-06T19:08:51ZFlole Systems
<p>Currently it is not possible to not set the ListenPort setting for wireguard. I suggest to use the special value 0 as a port and then mentioning that setting it to 0 disables this.</p> pfSense Packages - Bug #12924 (New): DNS Resolver WireGuard ACL Inconsistencyhttps://redmine.pfsense.org/issues/129242022-03-09T10:59:57ZKevin Mychal Ong
<p>Initially, I had two pfsense nodes connected via the WireGuard package. My tunnel network was 10.0.3.0/30 for p2p. I then added another pfsense node to make the topology hub and spoke. Naturally, I had to make my tunnel network larger, so I changed the WG interface subnets to /29 instead and proceeded with adding the third node. Everything is working properly except for the fact that the Unbound ACL that's created by WireGuard on the first two nodes did not change from /30 to /29. It says in the description not to touch those but I manually changed them to /29 instead just to make things consistent. However, after restarting the pfsense box, it just goes back to /30.</p> pfSense Packages - Bug #12760 (New): Link-local addresses disallowed on Wireguard interfaceshttps://redmine.pfsense.org/issues/127602022-02-06T00:46:58ZAlex Chang-Lam
<p>Wireguard supports link-local IPv6, however adding a static link-local to interfaces is not allowed, even for interfaces of type tun_wg.</p>
<p>This is particularly necessary for dn42.</p> pfSense Docs - Todo #12756 (New): Add information on correct MTU to use with WireGuardhttps://redmine.pfsense.org/issues/127562022-02-04T08:51:57ZViktor Gurov
<p><strong>Page:</strong> <a class="external" href="https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-ra.html">https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-ra.html</a></p>
<p><strong>Feedback:</strong></p>
<p>In all four Wireguard configuration recepies, there is no mention of changing the MTU and MSS values</p> pfSense - Bug #12715 (New): Long system startup time when LDAP is configured and unavailable duri...https://redmine.pfsense.org/issues/127152022-01-21T15:36:42ZChristian McDonaldcmcdonald@netgate.com
<ol>
<li>Currently if LDAP is unavailable at system startup, several LDAP queries have to timeout before the system will proceed with startup. There is no recycling of connections, so <em>n</em> LDAP queries requires <em>n</em> separate connections, and thus <em>n</em> separate timeouts. This results in a hang at startup that is several minutes long in some cases, probably dependent on the number of LDAP calls that are required (e.g. <em>n</em> * LDAP_timeout).</li>
<li>If LDAP is unavailable during system startup, the system will appear to hang at "Synchronizing user settings..." </li>
<li>This is unavoidable if LDAP connectivity relies on a VPN (e.g. IPsec, WireGuard, etc.), FRR for dynamic routes, etc...these services are started later in the startup process.</li>
<li>We should implement some sort of global state that will prevent subsequent LDAP queries if one times out during system startup, as subsequent attempts are likely to fail as well.</li>
</ol>
<p>Related to <a class="external" href="https://redmine.pfsense.org/issues/11644">https://redmine.pfsense.org/issues/11644</a></p> pfSense Packages - Bug #12608 (New): WireGuard tunnels monitored by dpinger causing system to sto...https://redmine.pfsense.org/issues/126082021-12-16T15:14:54ZChristian McDonaldcmcdonald@netgate.com
<p>Current workaround is to disable gateway monitoring on WireGuard tunnel gateways.</p>
<p>(I will be noting observations here as I unpack this)</p> pfSense Packages - Feature #12526 (New): WireGuard Widgethttps://redmine.pfsense.org/issues/125262021-11-16T14:48:56ZB. B.
<p>Hellow,</p>
<p>I want to request a feature to the WireGuard widget, probably not so important for many others.<br />Do you think it is possible to add a "Widget title" to the WireGuard widget?<br />So we can change the name of the widget :)</p> pfSense Packages - Feature #12525 (New): WireGuard Tunnel restore configurationhttps://redmine.pfsense.org/issues/125252021-11-16T14:45:43ZB. B.
<p>Hi,</p>
<p>I see the function for downloading the configuration "files" in the WireGuard - Tunnels (nice to backup the config files)<br />But it would also be nice if it was possible to restore it.<br />It would save you a lot of time if we're unlucky and messed up the tunnel/peers. :)</p> pfSense Packages - Feature #12513 (New): WireGuard Utilization Status (Beyond Active Connection)https://redmine.pfsense.org/issues/125132021-11-09T15:46:45ZJum Pers
<p>WG and pfSense are working very well together these days - thank you for the continued code and UI updates.</p>
<p>A feature that would be quite helpful on the SysAdmin side (for knowing when one can perform some client systems maintenance in scenarios where users can work whenever) is if, for both the WG Status page and (ideally) WG Widget (also), there was a set-able level (transfer threshold) that would indicate that a WG connection was actually being used rather than merely connected.</p>
<p>Perhaps this could be achieved by polling the transfer rates (RX, TX) every so many seconds (30s?) and subtracting the previous values from the present values (to see if they are above the threshold). In this way, setting a threshold for common RDP activity would provide a way of knowing whether the remote user was actively using their remote system.</p>
<p>Suggestion-wise, a colorized (green, yellow [optional: could be used for when close to threshold], red) icon, perhaps even just a small-to-medium sized (not-too-distracting) dot, to the right of the Peer name (or to the immediate right of the handshake icon if preferable) would do the trick. Or any such visual indicator.</p>
<p>Presently, it takes a lot of memorization ;) and page reloads to try to gauge which WG connections are actually being used.</p> pfSense - Todo #10199 (New): Improve Spanish translation interfacehttps://redmine.pfsense.org/issues/101992020-01-22T09:20:34ZAluisco Miguel Ricardo Mastrapa