pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162017-07-24T15:56:42ZpfSense bugtracker
Redmine pfSense - Bug #7719 (Resolved): Dynamic DNS updates not working on interface failoverhttps://redmine.pfsense.org/issues/77192017-07-24T15:56:42ZJorge Albarenquejorgito1412@gmail.com
<p>I realized that dynamic DNS hostnames are not being updated on interface failover. When manually marking a gateway as "down" everything works fine, but not when the interface actually goes down on its own. I think I tracked down the root cause:</p>
<p>When an interface in a gateway group fails, and this gateway group is tied to a dynamic DNS configuration, <strong>rc.dyndns.update</strong> is called with the <ins>user defined interface name</ins> as a parameter.</p>
<p>Within that script, <strong>lookup_gateway_interface_by_name()</strong> converts the user defined name to the <ins>friendly interface name</ins> (eg "wan") and this is passed to <strong>services_dyndns_configure()</strong></p>
<p>The problem is that <strong>services_dyndns_configure()</strong> looks designed to accept not the friendly interface name ("friendlyiface") but the real interface name ("interface"), since it ends up comparing to the 'interface' item of <em>return_gateway_groups_array()</em></p>
<p>In my case, for example, executing:</p>
<p><code>services_dyndns_configure(wan)</code></p>
<p>on the PHP console does not do anything, while</p>
<p><code>services_dyndns_configure(bge_vlan1)</code></p>
<p>triggers the proper dynamic DNS update.</p>
<p>---<br />On the other hand, when you manually mark a gateway as down, the script is set to refresh all configs and that's why it works fine:</p>
<p><code>Jul 24 17:46:34 check_reload_status Updating all dyndns </code><br />---</p>
<p>I know this has previously worked at some point, so I don't know if this is a regression, or when it occured.</p> pfSense - Feature #6796 (New): Allow hostnames as GRE and GIF endpointshttps://redmine.pfsense.org/issues/67962016-09-19T17:24:19ZJorge Albarenquejorgito1412@gmail.com
<p>Currently only IP endpoints are allowed. The hostnames need to be resolved and the interfaces updated on a regular basis, same as aliases do</p> pfSense - Feature #6324 (Closed): Improve IKEv2 multiple traffic selector per SA configuration GUIhttps://redmine.pfsense.org/issues/63242016-05-06T03:38:31ZJorge Albarenquejorgito1412@gmail.com
<p>On IPsec IKEv2 tunnels, by default all defined Ph2s are configured within a single SA.<br />This could end up with undesired (and potentially security-compromising) settings (I am aware of the option to disable the single SA behavior, it is not my point)</p>
<p><strong>Example:</strong><br /><ins>Ph2 1:</ins> 10.0.0.0/24 <-> 192.168.0.0/24<br /><ins>Ph2 2:</ins> 10.0.1.0/24 <-> 192.168.1.0/24</p>
<p>This translates to:<br /><em>leftsubnet = 10.0.0.0/24,10.0.1.0/24<br />rightsubnet = 192.168.0.0/24,192.168.1.0/24</em></p>
<p><strong>Which means that 10.0.0.0/24 and 192.168.1.0/24 now have connectivity although no Ph2 is explicitly defined for them, while on IKEv1 with the same settings they don't.</strong></p>
I believe this is a GUI problem. This is the way I think it should behave:
<ul>
<li>When IKEv2 with single SA is selected, the GUI should let you create only one Ph2 where you specify all the subnets you want, on both sides, altogether.</li>
<li>When IKEv2 with split configuration is selected, it should behave as it does right now</li>
<li>Upgrades from previous versions should default to split configuration to avoid potential security issues.</li>
</ul>
<p>----<br />I also found that this (kind of) breaks the IPsec widget. If you have multiple Ph2s defined with single SA settings, the output doesn't make sense, it shows only one tunnel with single subnets and names (the real problem here is that in fact there is just one SA!). I guess this could be easily fixed with the previous proposed solution.</p> pfSense - Bug #4795 (Not a Bug): IPsec logging is not workinghttps://redmine.pfsense.org/issues/47952015-06-27T22:23:34ZJorge Albarenquejorgito1412@gmail.com
<p>The IPsec logs stay blank even when setting all options to "highest".</p>
<p>I believe this is an issue on how the syslog is handled, since forcing strongSwan to log to a specific file works fine.</p> pfSense - Bug #4794 (Resolved): Handling of ASN1.DN values for RSA IPsec during upgrades from pre...https://redmine.pfsense.org/issues/47942015-06-27T22:17:10ZJorge Albarenquejorgito1412@gmail.com
<p>The certificate CNs are interpreted differently by raccoon and strongSwan, for example:</p>
<p><ins>raccoon:</ins><br />C=US, ST=Whatever, L=Springfield, O=Springfield Power Plant/emailAddress=<a class="email" href="mailto:burns@powerplant.com">burns@powerplant.com</a>, CN=springfield.powerplant.com</p>
<p><ins>strongSwan:</ins><br />"C=US, ST=Whatever, L=Springfield, O=Springfield Power Plant, E=<a class="email" href="mailto:burns@powerplant.com">burns@powerplant.com</a>, CN=springfield.powerplant.com"</p>
<p>So on upgrades from v2.1.x and before, some regex needs to be done on the ASN1DN field.</p>
<p>Also, the value needs to be surrounded in quotes, but be careful because if the identity prefix is provided, the prefix must be included within the quotes, eg: <em>rightid = "asn1dn:#whateverhexvalue..."</em><br />This will depend on how the identity type prefixes are handled (related to bug <a href="https://redmine.pfsense.org/issues/4792" class="external">4792</a> )</p> pfSense - Feature #4405 (In Progress): Traffic shaping doesn't work when applied to a bridge inte...https://redmine.pfsense.org/issues/44052015-02-10T21:07:51ZJorge Albarenquejorgito1412@gmail.com
<p>Having two or more interfaces within a bridge, the traffic shaper doesn't work when applied to it. Traffic is seen on the member interfaces instead of the bridge.</p>
<p>Appropriate tunables are configured (net.link.bridge.pfil_member and net.link.bridge.pfil_bridge). This worked fine on 2.1.x. Should be pretty simple to reproduce.</p>
<p>This behavior is essential to achieve <strong>proper</strong> download shaping on multi-LAN setups.</p> pfSense - Feature #2904 (Resolved): Add checkbox or default option for "verify_identifier on;" on...https://redmine.pfsense.org/issues/29042013-03-24T18:33:11ZJorge Albarenquejorgito1412@gmail.com
<p>The ASN1DN field on the "peers_identifier" option within racoon.conf can be used to specify which certificate or set of certificates should be allowed to connect. Anyway, for this to take effect, there's an additional option required on the racoon.conf file:</p>
<p><code>verify_identifier on;</code></p>
<p>The default value for this is off. I guess this can be set to always on without harm, and increased security. If the ASN1DN values are left blank, they will be taken and verified from the certificates themselves. If you specify an ASN1DN manually, it will be used for verification.</p>
<p>In case I am missing something else that might break by adding this as a default option, a checkbox to enable it will be great.</p>
<p>Check <a href="http://forum.pfsense.org/index.php/topic,60335.0.html" class="external">my post about the topic</a> and the <a href="http://www.daemon-systems.org/man/racoon.conf.5.html" class="external">racoon.conf man page</a> for more info.</p>
<p>Thanks!</p> pfSense - Bug #2734 (Closed): Mobile IPsec AES128 fails with glxsb on Alix, iOS clienthttps://redmine.pfsense.org/issues/27342012-12-27T11:29:19ZJorge Albarenquejorgito1412@gmail.com
<p><ins>Hardware:</ins> Alix 2D3, latest BIOS. I attach the output of dmesg.</p>
<p><ins>pfSense:</ins> v2.0.2 (also fails with 2.0.1 and some 2.1 snapshots as per the forum posts)<br />This is the output of rc.banner:</p>
<pre>*** Welcome to pfSense 2.0.2-RELEASE-nanobsd (i386) on pfsenseurq ***
WAN (wan) -> vr0 -> XXX.XXX.XXX.XXX
LAN (lan) -> vr1 -> 172.21.2.254
LINK (opt1) -> vr2 -> 10.255.255.2
WLAN (opt2) -> ath0_wlan0 -> 172.21.202.254</pre>
<p><ins>Config:</ins> Mobile IPsec VPN, xauth + PSK configured as in the wiki, with iPhone client (iOS v5.1.1). Set both Phase1 and Phase2 to AES-128</p>
<p><ins>Issue:</ins> The VPN works fine as long as glxsb is disabled. If glxsb is enabled, the tunnel comes up but no traffic passes. This shows on the log:</p>
<pre>Nov 29 11:49:00 racoon: ERROR: pfkey UPDATE failed: Invalid argument
Nov 29 11:49:00 racoon: ERROR: pfkey ADD failed: Invalid argument</pre>
<p>I found several related posts on the forum like <a href="http://forum.pfsense.org/index.php/topic,47969.0.html" class="external">this one</a>, I even created <a href="http://forum.pfsense.org/index.php/topic,56289.0.html" class="external">this post</a> , no apparent solution, other people also experiencing the issue.</p>
<p>I have also created a RSA + auth IPsec VPN with the iPhone (configured as a forum post), and it works fine, under the same conditions (enabling glxsb breaks it)</p>
<p>Some additional info: the problem seems to be on Phase2. If I set the Phase1 to AES-128 and Phase2 to 3DES, I receive a warning on the log, but the VPN passes data without issues. The problem shows up when Phase2 is set to AES128.</p>
<p>I really don't know if the problem comes from pfSense, the FreeBSD kernel, racoon or the glxsb driver itself.</p>
<p>I attach the full racoon debugging log when the problem shows up. This was a test VPN created for this sole purpose, so I don't care about how "verbose" the log is in regards to the keys and so on.</p>
<p>Thanks in advance!</p>