pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162021-08-05T05:06:14ZpfSense bugtracker
Redmine pfSense - Regression #12215 (Closed): OpenVPN does not resync when running on a gateway grouphttps://redmine.pfsense.org/issues/122152021-08-05T05:06:14ZJames Webb
<p>Hi all,</p>
<p>It seems that quite a bit of the codebase has changed in the relevant files since the fix I implemented in <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: OpenVPN does not resync when running on a gateway group (Resolved)" href="https://redmine.pfsense.org/issues/9595">#9595</a>. This change has caused a regression and as such the same issue that was originally defined in <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: OpenVPN does not resync when running on a gateway group (Resolved)" href="https://redmine.pfsense.org/issues/9595">#9595</a> is now reoccuring. This is likely causing issues in quite a few deployments.</p>
<p>Best wishes,<br />James.</p> pfSense - Bug #9595 (Resolved): OpenVPN does not resync when running on a gateway grouphttps://redmine.pfsense.org/issues/95952019-06-19T08:38:53ZJames Webb
<p>When OpenVPN clients/servers are running on a gateway group interface, they should always bind to the most preferable interface within that group. In cases when cables are disconnected/reconnected or when IP changes occur, OpenVPN will often hug a lower priority interface and not resume operation on the most preferable online interface within a gateway group.</p>
<p>This is due to the following reason:</p>
<p>IP changes are monitored by the <code>rc.newwanip</code> file which in turn executes the function <code>openvpn_resync_all</code> in <code>/etc/inc/openvpn.inc</code></p>
<p>An excerpt from this function is shown below:</p>
<pre><code class="php syntaxhl"><span class="k">if</span> <span class="p">(</span><span class="nb">is_array</span><span class="p">(</span><span class="nv">$config</span><span class="p">[</span><span class="s1">'openvpn'</span><span class="p">][</span><span class="s1">'openvpn-client'</span><span class="p">]))</span> <span class="p">{</span>
<span class="k">foreach</span> <span class="p">(</span><span class="nv">$config</span><span class="p">[</span><span class="s1">'openvpn'</span><span class="p">][</span><span class="s1">'openvpn-client'</span><span class="p">]</span> <span class="k">as</span> <span class="o">&</span> <span class="nv">$settings</span><span class="p">)</span> <span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="nv">$interface</span> <span class="o"><></span> <span class="s2">""</span> <span class="o">&&</span> <span class="nv">$interface</span> <span class="o">!=</span> <span class="nv">$settings</span><span class="p">[</span><span class="s1">'interface'</span><span class="p">])</span> <span class="p">{</span>
<span class="k">continue</span><span class="p">;</span>
<span class="p">}</span>
<span class="nf">openvpn_resync</span><span class="p">(</span><span class="s1">'client'</span><span class="p">,</span> <span class="nv">$settings</span><span class="p">);</span>
<span class="p">}</span>
<span class="p">}</span>
</code></pre>
<p>This excerpt sadly does not take account of the situation when OpenVPN instances are bound to gateway groups because the interface in question will never be equal to the OpenVPN interface, thus OpenVPN instances are never resynced when these situations occur.</p>
<p>The solution I propose will bring OpenVPN resyncs more in line with that currently implemented within <code>rc.openvpn</code> to allow for instances operating on gateway group interfaces to behave correctly.</p>
<p>I will submit a PR for review shortly.</p>
<p>Best wishes,<br />James.</p> pfSense - Bug #9040 (Not a Bug): Invalid status for OpenVPN Point-to-Point Linkshttps://redmine.pfsense.org/issues/90402018-10-13T06:44:01ZJames Webb
<p><strong>Background:</strong><br />If one defines multiple OpenVPN servers in a tun point-to-point mode (i.e. use a /30 subnet in the IPv4 tunnel network field) the status for each respective server reported by pfSense is incorrect when more than one server instance is instantiated.</p>
<strong>Steps to replicate:</strong><br /><ins>Server</ins>
<ul>
<li>Create two OpenVPN p2p server instances on a pfSense machine. Do this by specifying a unique tunnel network of /30 on each instance. The pfSense OpenVPN status widget will then group the server instances as per Figure 1 below.</li>
</ul>
<ins>Client</ins>
<ul>
<li>Create two client instances on other pfSense machines to dial into the two servers respectively. Ensure each server tunnel network is specified in the client tunnel network field too.</li>
</ul>
<p>The clients will successfully connect as per Figure 2 and Figure 3. However, the server status on Figure 1 shows only one connection.</p>
<p>I am not sure whether this is a limitation of the OpenVPN management sockets or an issue in pfSense, but I thought I would raise it here to make the relevant people aware of it's existence regardless.</p>
<p>I connected to the OpenVPN management socket manually for the OpenVPN server instances and it seems that the status messages are extremely vague when operating in p2p mode compared to remote access mode. See output of server1 below:</p>
<p><code>>INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info<br />OpenVPN STATISTICS<br />Updated,Sat Oct 13 12:40:23 2018<br />TUN/TAP read bytes,2957<br />TUN/TAP write bytes,1928<br />TCP/UDP read bytes,14492<br />TCP/UDP write bytes,14092<br />Auth read bytes,2792<br />pre-compress bytes,0<br />post-compress bytes,0<br />pre-decompress bytes,0<br />post-decompress bytes,0<br />END</code></p>
<p>Best wishes,<br />James</p> pfSense - Bug #8617 (Resolved): Error on RADIUS Authenticationhttps://redmine.pfsense.org/issues/86172018-07-04T12:21:27ZJames Webb
<p>After switching to pfSense development snapshots I've noticed that the freeradius package has been producing some fatal errors when testing authentication.</p>
<p><strong>Steps to replicate:</strong><br />- Install the freeradius package on 2.4.4-DEVELOPMENT.<br />- Configure a freeradius server with a test user and local NAS.<br />- Add the RADIUS authentication server in System->User Manager->Authentication Servers.<br />- Try authentication by entering the test user's credentials on Diagnostics->Authentication with the RADIUS server selected.</p>
<p>The error produced is attached in the <code>PHP_errors.log</code> file.</p>
<p>Thanks,<br />James</p> pfSense - Bug #8380 (New): OpenVPN RADIUS password length is not constanthttps://redmine.pfsense.org/issues/83802018-03-19T13:28:28ZJames Webb
<p>Hi there,</p>
<p>I've been running a production OpenVPN server on pfSense for the past year and I have recently switched to a RADIUS based architecture for authentication of users.</p>
<p>The maximum password length that OpenVPN (or RADIUS) seem to support when integrated together is set at 256 bits (64 hex characters). This has been working fine. However, recently we received a few complaints of the VPN failing (100% packet loss) after an hour or so. Instantly I thought this is due to the default <code>reneg-sec</code> value of 3600. Upon further testing it turns out that pfSense was reporting an authentication error when the client was trying to initiate a key renegotiation for the data channel. After a lot of time and effort I tried manipulating the password lengths and it turns out that the server would only re-negotiate with passwords that are of 216 bits or less (54 hex characters). I'm not sure why this is or whether this is due to the implementation of pfSense's integration with RADIUS and OpenVPN, but I'd thought I'd make you aware of it as it may cause other users to come across the same issue.</p>
<p>This seems rather odd to me, I think the max password lengths for initial authentication and subsequent renegotiations should be the same.</p>
<p>So to sum up - steps to reproduce:<br />- Setup an OpenVPN remote access server using the pfSense WebGUI (I used OpenVPN version 2.4.4, AES-256-GCM, ECDHE & TLS-CRYPT).<br />- Use RADIUS as the authentication mechanism (mine points to an SQL server with <code>radcheck</code> as the user/password table).<br />- Export a client certificate for the server you created and add the directive <code>reneg-sec 5</code> to speed up the testing process.<br />- In the radcheck table add 2 users: one with a password length of 64 hex digits (this way you can easily verify the bit length) and another with a hex password length of 54 or less. I used the VARCHAR field type.<br />- Connect both clients and observe the server logs on pfSense with a verbosity level of 5.<br />- Client 1 will initially connect successfully and then fail subsequently for each renegotiation (every 5 seconds). Client 2 will connect successfully and succeed for all subsequent renegotiations.</p>
<p>Best wishes,<br />James</p> pfSense - Bug #8080 (Resolved): DHCPv6 + SLAAC SG1000https://redmine.pfsense.org/issues/80802017-11-10T18:55:42ZJames Webb
<p>Hi,</p>
<p>I recently bought an SG1000 device for use on a corporate network.<br />I have had quite a bit of experience with pfSense before and am having trouble getting DHCPv6 and SLAAC to work on the SG1000.</p>
<p>As standard, when setting up DHCPv6+RA on a LAN you can input the DHCPv6 ranges and set the RA flags to assisted to get local devices to be allocated IPv6 addresses within a routed subnet. However, on the SG1000, no local LAN devices are being given any IPv6 addresses.</p>
<p>The LAN address on the SG1000 has an IPv6 address set to <code>[routed_subnet]::1/64</code>. The DHCPv6 and router advertisements then simply work off that /64 subnet. However, on closer examination of the log files the DHCPv4 server seems to work absolutely fine, but there is never any queries or entries for the DHCPv6 server. It is consistently stuck in a listening state. Have mirrored the exact setup with other pfSense devices and the problems do not occur.</p>
<p>Is there any nuances that need to be addressed in the SG1000? Would appreciate it if someone could try to reproduce this issue.</p>
<p>James</p>
<p>P.S. I have attached the DHCP log file for your perusal. My public IPv6 range has been replaced for the string "ROUTED_IPv6_BLOCK".</p> pfSense Packages - Bug #7578 (Resolved): Suricata -- Removing Hosts from Block Table via Alertshttps://redmine.pfsense.org/issues/75782017-05-20T15:35:43ZJames Webb
<p>Hi there,</p>
<p>I am running the pfSense 2.4 beta with Suricata 3.2.1_1.</p>
<p>I have noticed that when clicking the leftmost red cross in the Alerts page to remove hosts from the Blocked table no host is successfully removed. However, if I manually trace through the Block table I can successfully remove the host this way.</p>
<p>Could someone else please check to see if this functionality still works from the Alerts table.</p>
<p>Best wishes,<br />James</p> pfSense - Todo #7545 (Resolved): OpenVPN 2.4.2https://redmine.pfsense.org/issues/75452017-05-12T09:26:20ZJames Webb
<p>Hi there,</p>
<p>I am unsure whether the pfSense 2.4 version will include the OpenVPN 2.4.2 version or just 2.4. However, in light of this recent investigation:</p>
<p><a class="external" href="http://blog.quarkslab.com/security-assessment-of-openvpn.html">http://blog.quarkslab.com/security-assessment-of-openvpn.html</a></p>
<p>I think it would be in all our interests to have pfSense 2.4 roll out with OpenVPN 2.4.2 which contains fixes for all the security risks mentioned in that audit - some of which are quite severe.</p>
<p>I would like to know thoughts :)<br />James</p> pfSense Packages - Bug #7498 (Resolved): Deprecated option included in OpenVPN client exporthttps://redmine.pfsense.org/issues/74982017-04-27T08:19:34ZJames Webb
<p>As of OpenVPN 2.4 the directive: <code>ns-cert-type</code> has been deprecated.</p>
<p>However, from my testing, the client export package includes the line <code>ns-cert-type server</code> no matter what verification options you choose.<br />Could this be removed and verification directives be left to the dropdown box in the WebGUI? I.e. either <code>verify-x509-name</code> or <code>tls-remote</code>.</p>
<p>James</p> pfSense - Bug #7279 (Duplicate): VLAN Trash Icon not working - Cannot delete VLAN entryhttps://redmine.pfsense.org/issues/72792017-02-18T18:27:55ZJames Webb
<p>Hi,</p>
<p>Upon creating a test VLAN via Interfaces -> Assignments -> VLAN -> Add<br />I cannot remove the VLAN. I have inspected the webpage and attached the errors that are triggered in the form of screenshots when the trash icon is clicked.</p>
<p>JW</p> pfSense Packages - Bug #7223 (Resolved): IPv4 Rules not working in Inline Modehttps://redmine.pfsense.org/issues/72232017-02-07T07:00:32ZJames Webb
<p>After adding the following rule to custom.rules:</p>
<p><code>drop ip [108.74.97.21, 82.132.247.191] any <> $HOME_NET any (msg:"Suspicious Botnet Blocked";)</code></p>
<p><strong>Expected behaviour:</strong><br />Block any traffic flowing from listed IPs - Regardless of Inline or Legacy mode</p>
<p><strong>Actual behaviour:</strong><br />Blocks traffic and adds message to alerts in Legacy mode. In Inline mode nothing happens and traffic is allowed through.</p>
<p><strong>Other observations:</strong><br />On further inspection it would seem that since the pfSense 2.4.0 update no IPv4 rules are being blocked in Inline mode at all. Note that the addresses tested are IPv4 and that this observation regarding lack of IPv4 blocking may be part or all of the issue.</p>
<p>James</p> pfSense - Bug #7194 (Rejected): CARP/IP Aliases under same subnet not synced correctlyhttps://redmine.pfsense.org/issues/71942017-02-02T09:34:46ZJames Webb
<p>If you set a CARP VIP e.g. an address on the WAN subnet xxx.xxx.xxx.xx1/28. Then set another address, be it another CARP or IP Alias to the above CARP under the same subnet e.g. xxx.xxx.xxx.xx2/28. When a failover occurs the CARP/IP Alias under the CARP VIP (i.e. The .xx2/28) doesn't transfer properly. This can be tested by going to the Ping page and trying to contact the primary WAN IP from the .xx2/28 CARP/IP Alias VIP (no route). This can be resolved on the secondary (now acting as master) by going to the Firewall->VIPs->xxx.xxx.xxx.xx2/28 then hitting Save. Then everything works.</p>
<p>Can this be resolved?</p>
<p>James</p> pfSense - Bug #7136 (Resolved): OpenVPN not binding to IP Aliases -> NO LOGS generatedhttps://redmine.pfsense.org/issues/71362017-01-18T17:26:10ZJames Webb
<p>Steps to replicate:<br />- Create an IP Alias on any interface e.g. 127.0.0.2 on Localhost<br />- Attempt to bind OpenVPN server to this interface on any port<br />- OpenVPN instance will not start and no logs are generated!</p>
<p>James Webb</p> pfSense - Bug #6993 (New): OpenVPN status error during CARP state transitionhttps://redmine.pfsense.org/issues/69932016-12-07T12:56:13ZJames Webb
<p>Running two devices in HA and have stacked one IP Alias onto the CARP IP. If I bind a OpenVPN server to the IP Alias (on both machines) then during a switch of a carp state, one of the devices will throw the error on the status page "error contacting daemon". This doesn't affect functionality as the OpenVPN service is still running underneath. It just tries to start another OpenVPN instance over an existing one -> address already bound by currently running instance.<br />So can it be fixed that a new OpenVPN instance is not trying to start without the other one being shutdown first :)</p>