pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162021-01-06T09:29:12ZpfSense bugtracker
Redmine pfSense - Feature #11225 (Rejected): Change Host Alias range when it is made from CIDRhttps://redmine.pfsense.org/issues/112252021-01-06T09:29:12ZConstantine Kormashev
<p>Now if I make an Alias using CIDR like 192.168.1.*2*/30 it makes 4 entries which starts from 1st host in the given range:<br />192.168.1.0<br />192.168.1.1<br />192.168.1.2<br />192.168.1.3</p>
<p>But probably this is different from expected and the better would be to start entries from host defined in range e.g. example above will give us:<br />192.168.1.2<br />192.168.1.3</p>
<p>It might seem not important if we use a short network but if I would like to add 260 hosts from 192.168.0/23 it would be much easy and safer to write 192.168.0.250/23 than using a range 192.168.0.250-192.168.1.255 for this goal.</p> pfSense - Feature #11169 (New): Changing interface index orderhttps://redmine.pfsense.org/issues/111692020-12-17T05:44:26ZConstantine Kormashev
Current configuration operates interface indexes instead of real interfaces, e.g.<br />wan->igb0<br />lan->igb1<br />opt1->igb2<br />opt2->igb3<br />opt3->igb1.10<br />opt4->igb1.20<br />opt5->ovpn1<br />opt6->igb1.30<br />and so on. That makes configuring more smooth and flexible. But in the current implementation if some interfaces were deleted indexes are not rearranged and this might lead to some issues especially in config sync. E.g. in the example above if opt5 is deleted opt6 will not become opt5. Moreover, if a new interface assigned it acquires the lowest free index in the case above opt5. This situation can easily lead to errors in the HA cluster configuration. E.g. 3 interfaces add on primary and 2nd was deleted due to it was added by mistake. E.g. opt1, opt2, opt3 were added, opt2 was deleted, so final it is opt1, opt3. But during configuring secondary final picture is different it is opt1, opt2 because of no mistake. That leads to a config sync issue. And this is totally unclear for people who do not know what really happens under the hood. The only way to fix it on secondary is setup from scratch or manual config editing. Sometimes even setup from scratch becomes tricky. See 1st example, it is not possible to create opt5 without making a fake OpenVPN.<br />It would be good to solve this issue. There are some ways for that:
<ul>
<li>allow rearranging index manually from indexes list</li>
<li>make indexes totally unique and set indexes manually during assigning interface</li>
<li>sync interface settings from primary to secondary with auto assigning IP/mask from the predefined network</li>
</ul>
<p>Also for escaping making fake VPN instances during initial secondary setup, change index enumeration and use increased numbers from 0 for physical interface and decreased from uint32 max for software interfaces like VPN, etc, e.g.<br /> opt1->igb2<br /> opt2->igb3<br /> opt4294967295->ovpn1<br /> opt4294967294->ovpn2</p> pfSense - Feature #10732 (New): Warning banner for secondary HA nodehttps://redmine.pfsense.org/issues/107322020-07-06T05:41:14ZConstantine Kormashev
<p>It would be good if the secondary HA node has a banner with a warning all management actions have to be performed on the primary node only. And user can see this banner after login, as they see default password waring now.</p>
There are a couple of ways to detect a secondary node:
<ul>
<li>hidden flag in the config, see <a class="external" href="https://redmine.pfsense.org/issues/10731">https://redmine.pfsense.org/issues/10731</a></li>
<li>CARP interfaces are in BACKUP state</li>
</ul> pfSense Packages - Bug #10503 (New): Flapping any GW in multi-WAN influences restating all IPsec ...https://redmine.pfsense.org/issues/105032020-04-28T08:24:55ZConstantine Kormashev
<p>There are 2 nodes with a multi-WAN setup: 2 WANs, 2 Gateways. The are 2 IPsec VTI tunnel every working through its own Gateway.<br />There is a FRR BGP setup with sessions via IPsec VTI tunnels. But both sessions sends and receives updates using loopback interfaces and static routes via IPsec VTI.</p>
<pre>
+->loopback1-->IPsec VTI1-->WANGW1--v v--WANGW3<--IPsec VTI3<--loopback3<-+
Node1 | +->the internet<-+ | Node2
+->loopback2-->IPsec VTY2-->WANGW2--^ ^--WANGW4<--IPsec VTI4<--loopback4<-+
</pre>
<p>FRR recursively finds Next-Hop for BGP routes via static routes via IPsec. So Node1 can reach routes that are behind Node2 via Node2 loopbacks (loopback3 and loopback4) and vice versa, Node2 can reach Node1 routes via loopback1 and loopback2.<br />If one of Gateway flapping, even if it is not default Gateway, it seems leading to remove static routes for all IPsec tunnel, due event /rc.newipsecdns and ipsec_reload_package_hook() which executes<br /><pre>
`function frr_ipsec_reload() {
require_once('interfaces.inc');
$vti_ifs = array_keys(interface_ipsec_vti_list_all());
foreach ($vti_ifs as $vif) {
mwexec('/usr/local/bin/frrctl cycleinterface ' . escapeshellarg($vif));
}
}`
</pre><br />The interesting thing here is that, existing BGP routes and BGP table entries are not removed from FRR routing table and BGP table, probably because BGP large session timeout. But at the same time these BGP routes are removed from system routing table. And the more interesting, is that, even if static routes via IPsec returned to system routing table and FRR routing table, these BGP routes are not exported back to system routing table by FRR.<br />On system it looks like:</p>
<p>Static routes through IPsec in FRR table<br /><pre>
K>* 25.0.0.1/32 [0/0] via 66.0.0.1, 1d01h00m
K>* 26.0.0.1/32 [0/0] via 66.0.1.1, 1d01h00m
</pre></p>
<p>BGP routes in FRR table<br /><pre>
B> 10.16.0.0/16 [20/0] via 25.0.0.1 (recursive), 2d05h00m
* via 66.0.0.1, 2d05h00m
</pre></p>
<p>FRR BGP entries<br /><pre>
* 10.16.0.0/16 25.0.0.1 0 50 65501 i
*> 26.0.0.1 0 150 100 65501 i
</pre></p>
<p>System route table has static routes through IPsec<br /><pre>
25.0.0.1/32 66.0.0.1 UGS 3750 1400 ipsec3000
26.0.0.1/32 66.0.1.1 UGS 3752 1400 ipsec1000
</pre></p>
<p>But there are not BGP routes even if they, as we can see, exist in FRR routing table and BGP table. Pay attention on routes uptime. BGP session uptime is the same as BGP routes uptime.</p> pfSense - Feature #10290 (New): Firewall Aliases Add button on top of listhttps://redmine.pfsense.org/issues/102902020-02-25T07:08:23ZConstantine Kormashev
<p>It would be good if we one more Add button would add on top of list. If adding new aliases happens often, then Add on top makes that process faster.<br />Probably it would be good adding "top" Add button to all Firewall aliases sections.</p> pfSense - Bug #10281 (Not a Bug): I can unassign interface even if it is used in FRR OSPFhttps://redmine.pfsense.org/issues/102812020-02-22T23:50:35ZConstantine Kormashev
<p>There was IPsec VTI tunnel with assigned interface. The interface was used in FRR OSPF settings as OSPF interface. If I remove interface from assigned it still exists in FRR OSPF settings. No warnings during unassigning, I could only find the issue when tried to disable IPsec VTI entry, I got warning: <code>Cannot disable a Phase 1 with a child Phase 2 while the interface is assigned. Remove the interface assignment before disabling this P2</code>. But there was not assigned interface related to this IPsec entry, interface was deleted, excepting previously assigned interface is still in FRR OSPF settings.<br />The warning is not easy to figure out if you do not know/remember where else related interface was used. I guess we need warning for unassigning interface if one is used in FRR, or delete it from FRR config.</p> pfSense - Bug #9151 (Not a Bug): Console menu entry (14 SSH) is not updated properly after perfor...https://redmine.pfsense.org/issues/91512018-11-26T05:32:26ZConstantine Kormashev
<p>If SSH is disabled from menu, the menu might entry still show Disable Secure Shell. And vice versa if SSH is enabled from menu, the menu might entry still show Enable Secure Shell.</p>
<pre>
0) Logout (SSH only) 9) pfTop
1) Assign Interfaces 10) Filter Logs
2) Set interface(s) IP address 11) Restart webConfigurator
3) Reset webConfigurator password 12) PHP shell + pfSense tools
4) Reset to factory defaults 13) Update from console
5) Reboot system 14) Enable Secure Shell (sshd)
6) Halt system 15) Restore recent configuration
7) Ping host 16) Restart PHP-FPM
8) Shell
Enter an option: 14
SSHD is currently disabled. Would you like to enable? [y/n]? y
Writing configuration... done.
Enabling SSHD...
Reloading firewall rules. done.
0) Logout (SSH only) 9) pfTop
1) Assign Interfaces 10) Filter Logs
2) Set interface(s) IP address 11) Restart webConfigurator
3) Reset webConfigurator password 12) PHP shell + pfSense tools
4) Reset to factory defaults 13) Update from console
5) Reboot system 14) Enable Secure Shell (sshd)
6) Halt system 15) Restore recent configuration
7) Ping host 16) Restart PHP-FPM
8) Shell
</pre><br />Here it shows Enable Secure Shell instead Disable Secure Shell. But sometimes it works without the issue pfSense Packages - Feature #8727 (Resolved): Clone button in cron pkghttps://redmine.pfsense.org/issues/87272018-08-01T00:12:53ZConstantine Kormashev
<p>It would be very useful if clone feature will appear in Cron pkg.<br />Sometimes tasks are tricky and there is possibility to make a mistake in case creation new one, clone action would be much reliable.</p> pfSense - Bug #8630 (Resolved): Web-GUI PHP error in brige after removing all interfaces were in ...https://redmine.pfsense.org/issues/86302018-07-10T02:02:38ZConstantine Kormashev
<p>If device has several interfaces in bridge and all those interfaces are deleted, Web-GUI shows error in <a class="external" href="https://&lt;addr&gt;/interfaces_bridge.php">https://&lt;addr&gt;/interfaces_bridge.php</a><br /><pre>
Warning: Illegal string offset 'bridged' in /usr/local/www/interfaces_bridge.php on line 32 Warning:
Illegal string offset 'bridged' in /usr/local/www/interfaces_bridge.php on line 35
Fatal error: Uncaught Error: Cannot create references to/from string offsets in /usr/local/www/interfaces_bridge.php: 35
Stack trace: #0 {main} thrown in /usr/local/www/interfaces_bridge.php on line 35
PHP ERROR: Type: 1, File: /usr/local/www/interfaces_bridge.php, Line: 35, Message:
Uncaught Error: Cannot create references to/from string offsets in /usr/local/www/interfaces_bridge.php:35 Stack trace: #0 {main} thrown
</pre><br />Looks like this is reaction on empty <code><bridge></bridge></code> section of config. <br />Before deleting interfaces:<br /><pre>
<bridged>
<members>lan,opt1,opt2</members>
<descr><![CDATA[BRIDGE]]></descr>
<maxaddr></maxaddr>
<timeout></timeout>
<maxage></maxage>
<fwdelay></fwdelay>
<hellotime></hellotime>
<priority></priority>
<proto>rstp</proto>
<holdcnt></holdcnt>
<ip6linklocal></ip6linklocal>
<ifpriority></ifpriority>
<ifpathcost></ifpathcost>
<edge>lan,opt1,opt2</edge>
<bridgeif>bridge0</bridgeif>
</bridged>
</pre><br />After deleting interfaces:<br /><pre>
<bridges>
</bridges>
</pre><br />Config without bridges does not have this section at all. Maybe it would be better to delete bridge in case all interfaces composed bridge are not available.</p> pfSense - Bug #8567 (New): Using IPv6 VIP alias for services may affect CARP IPv6 VIP workhttps://redmine.pfsense.org/issues/85672018-06-12T13:26:37ZConstantine Kormashev
<p>During investigation of customer request found IPv6 VIP alias for services may affect CARP IPv6 VIP work. CARP IPv6 VIPs may stops their work until device reboot.<br />For some unknown reason CARP IPv6 VIP stops working even in L2 segments in case IPv6 alias which was bound with service. It produces error during ping <em>Can't assign requested address</em> E.g. some alias was IPsec interface. In that case the alias still works tunnel established and keep-alive work, traffic forwarded via tunnel, but CARP IPv6 VIPs stop their work. Just changing service address does not help, device needs reboot.<br />May be related <a class="external" href="https://redmine.pfsense.org/issues/8566">https://redmine.pfsense.org/issues/8566</a></p> pfSense - Bug #8566 (New): Wrong IPv6 source in NS request in case using of IPv6 aliashttps://redmine.pfsense.org/issues/85662018-06-12T13:26:08ZConstantine Kormashev
<p>During investigation of customer request found system uses wrong IPv6 sources for NS requests therefore they never be completed. For unknown reason system tries to send NS from other IPv6 address which is defined on the same interface. This address is bound with service that tries to establish connection, in this case this is IPsec.<br />Lab example:<br />1st device pf3 has primary IPv6 2003::10/64 and additional alias 2001::2/64<br />2nd device pf4 has primary IPv6 2002::11/64 and additional alias 2001::1/64</p>
<p>2001::0/64 serves for connection between devices. Each of them has a route via this network to primary IPv6 address of another. IPsec setup on these primary IPv6 addresses.</p>
<p>2003::10/64 and 2002::11/64 try to get MAC of 2001::1/64 and 2001::2/64 that are in another network:<br />21 10.557327 <strong>2003::10</strong> ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for <strong>2001::1</strong> from 00:0c:29:8e:58:2e<br />22 10.618536 <strong>2002::11</strong> ff02::1:ff00:2 ICMPv6 86 Neighbor Solicitation for * 2001::2* from 00:0c:29:82:01:e2</p>
<p>Valid request from device with 2003::10/64 and 2001::2/64. I made one with ping6 -S 2001::2 2001::1<br />27 13.699943 <strong>2001::2</strong> ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for <strong>2001::1</strong> from 00:0c:29:8e:58:2e<br />29 13.700148 2001::1 2001::2 ICMPv6 86 Neighbor Advertisement 2001::1 (rtr, sol, ovr) is at 00:00:5e:00:01:2c</p>
<p>After valid NS/NA 2003::10/64 can ping 2001::1/64<br />41 14.819118 2003::10 2001::1 ICMPv6 62 Echo (ping) request id=0x4b40, seq=9843, hop limit=64 (reply in 42)<br />42 14.819166 2001::1 2003::10 ICMPv6 62 Echo (ping) reply id=0x4b40, seq=9843, hop limit=64 (request in 41)</p>
<p>VM configs and pcaps are in attachment</p> pfSense Packages - Feature #7794 (Resolved): FRR pkg pfsense no metric-type option in OSPF redist...https://redmine.pfsense.org/issues/77942017-08-22T03:14:15ZConstantine Kormashev
<p>There is not <code>metric-type</code> option in OSPF redistribute section of web-interface. By default FRR makes redistribution with route-map without options. But even I use manual route-map for redistribution instead there is no set <code>metric-type</code> option for OSPF IPv4 in web interface of route-map creation.</p> pfSense Packages - Feature #7793 (Resolved): FRR pkg pfsense web interface checking for RID is se...https://redmine.pfsense.org/issues/77932017-08-22T01:46:46ZConstantine Kormashev
<p>There is not any checking for RID in OSPF6 section in web interface now, but one must be, because in case there is not IPv4 interface at all RID is not defined and OSPF6 does not start.</p> pfSense Packages - Feature #7792 (Resolved): FRR pkg pfsense can not wok as ABR with stub areas (...https://redmine.pfsense.org/issues/77922017-08-22T01:26:29ZConstantine Kormashev
<p>Setup pfsense as ABR with several areas and found one does not work properly if one of areas is stub. There are two moments:<br />1. No opportunity to setup one of area as stub in web interface<br />2. Even raw config is used there is not stub option in OSPF Hello:<br /><code>*Aug 22 06:53:36.975: OSPF: Rcv hello from 172.16.150.43 area 0.0.0.1 from FastEthernet0/0.33 10.1.7.1<br />*Aug 22 06:53:36.975: OSPF: Hello from 10.1.7.1 with mismatched Stub/Transit area option bit</code></p> pfSense - Bug #7235 (New): 4860 has not got significant IPsec performance rising with enabled HW ...https://redmine.pfsense.org/issues/72352017-02-08T01:47:07ZConstantine Kormashev
<p>During IPsec performance tests on 4860 I did not observe significant IPsec performance increasing if HW acceleration is enabled.<br />Average rising are: <br /><em>10% for AES128CBC<br />7% for AES128GCM</em><br />In comparison with 2440, 2440 gives:<br /><em>56% for AES128CBC<br />54% for AES128GCM</em><br /><strong>4860 tests:</strong><br /><em>128 GCM 34000pps</em><br /><pre>
kldstat
Id Refs Address Size Name
1 3 0xffffffff80200000 225edc0 kernel
2 1 0xffffffff82611000 3646 ichwd.ko
last pid: 62291; load averages: 4.48, 3.20, 1.62 up 0+00:10:24 06:51:23
55 processes: 2 running, 52 sleeping, 1 waiting
CPU 0: 19.3% user, 0.0% nice, 33.1% system, 27.6% interrupt, 20.1% idle
CPU 1: 0.0% user, 0.0% nice, 0.0% system, 99.2% interrupt, 0.8% idle
CPU 2: 17.3% user, 0.0% nice, 52.0% system, 0.0% interrupt, 30.7% idle
CPU 3: 16.1% user, 0.0% nice, 53.1% system, 0.0% interrupt, 30.7% idle
Mem: 55M Active, 40M Inact, 183M Wired, 38M Buf, 7613M Free
Swap: 8192M Total, 8192M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND
12 root 45 -72 - 0K 720K WAIT 3 6:24 130.13% intr
77387 root 17 20 0 249M 14632K uwait 2 6:54 106.30% charon
11 root 4 155 ki31 0K 64K RUN 3 20:54 82.03% idle
18291 root 2 20 0 30144K 17988K usem 3 4:44 80.76% ntpd
0 root 32 -8 - 0K 512K - 0 1:30 2.59% kernel
</pre><br /><em>128 GCM 36500pps</em><br /><pre>
kldstat
Id Refs Address Size Name
1 6 0xffffffff80200000 225edc0 kernel
2 1 0xffffffff82611000 7577 aesni.ko
3 1 0xffffffff82619000 3646 ichwd.ko
last pid: 98195; load averages: 4.41, 3.26, 1.77 up 0+00:09:07 07:06:31
55 processes: 4 running, 51 sleeping
CPU 0: 12.2% user, 0.0% nice, 32.2% system, 33.7% interrupt, 22.0% idle
CPU 1: 19.6% user, 0.0% nice, 55.7% system, 0.0% interrupt, 24.7% idle
CPU 2: 17.3% user, 0.0% nice, 57.3% system, 0.0% interrupt, 25.5% idle
CPU 3: 0.0% user, 0.0% nice, 100% system, 0.0% interrupt, 0.0% idle
Mem: 52M Active, 37M Inact, 183M Wired, 30M Buf, 7619M Free
Swap: 8192M Total, 8192M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND
25406 root 17 92 0 249M 14692K CPU1 1 8:44 106.54% charon
0 root 32 -8 - 0K 512K - 0 0:47 100.00% kernel
16732 root 2 20 0 30144K 17988K kqread 2 6:21 80.57% ntpd
11 root 4 155 ki31 0K 64K RUN 3 9:51 77.98% idle
12 root 45 -72 - 0K 720K RUN 3 9:17 28.37% intr
</pre></p>
<p><em>128 CBC 34000pps</em><br /><pre>
kldstat
Id Refs Address Size Name
1 3 0xffffffff80200000 225edc0 kernel
2 1 0xffffffff82611000 3646 ichwd.ko
last pid: 66419; load averages: 4.54, 2.28, 1.03 up 0+00:08:24 07:23:31
55 processes: 3 running, 51 sleeping, 1 waiting
CPU 0: 18.0% user, 0.0% nice, 33.7% system, 27.1% interrupt, 21.2% idle
CPU 1: 0.8% user, 0.0% nice, 0.0% system, 98.8% interrupt, 0.4% idle
CPU 2: 20.8% user, 0.0% nice, 51.0% system, 0.0% interrupt, 28.2% idle
CPU 3: 20.4% user, 0.0% nice, 43.5% system, 18.0% interrupt, 18.0% idle
Mem: 52M Active, 38M Inact, 182M Wired, 26M Buf, 7621M Free
Swap: 8192M Total, 8192M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND
25895 root 17 92 0 249M 14296K CPU0 0 3:56 101.76% charon
12 root 45 -72 - 0K 720K WAIT 3 1:27 92.04% intr
11 root 4 155 ki31 0K 64K RUN 3 21:23 78.86% idle
18871 root 2 20 0 30144K 17988K usem 1 2:42 75.49% ntpd
0 root 32 -8 - 0K 512K - 0 3:07 39.26% kernel
</pre></p>
<p><em>128 CBC 36500pps</em><br /><pre>
kldstat
Id Refs Address Size Name
1 6 0xffffffff80200000 225edc0 kernel
2 1 0xffffffff82611000 7577 aesni.ko
3 1 0xffffffff82619000 3646 ichwd.ko
last pid: 97408; load averages: 5.05, 3.99, 2.54 up 0+00:14:56 07:12:20
55 processes: 3 running, 51 sleeping, 1 waiting
CPU 0: 14.9% user, 0.0% nice, 26.7% system, 36.1% interrupt, 22.4% idle
CPU 1: 18.4% user, 0.0% nice, 53.3% system, 0.0% interrupt, 28.2% idle
CPU 2: 14.9% user, 0.0% nice, 59.2% system, 0.0% interrupt, 25.9% idle
CPU 3: 0.0% user, 0.0% nice, 100% system, 0.0% interrupt, 0.0% idle
Mem: 53M Active, 38M Inact, 184M Wired, 36M Buf, 7616M Free
Swap: 8192M Total, 8192M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND
25406 root 17 92 0 249M 14908K CPU1 1 14:30 103.47% charon
0 root 32 -8 - 0K 512K - 0 4:21 100.00% kernel
16732 root 2 20 0 30144K 17988K usem 1 10:30 85.35% ntpd
11 root 4 155 ki31 0K 64K RUN 3 16:21 79.59% idle
12 root 45 -72 - 0K 720K WAIT 3 12:38 27.78% intr
</pre></p>
<pre>
uname -a
FreeBSD pfSense.localdomain 10.3-RELEASE-p9 FreeBSD 10.3-RELEASE-p9 #1 5fc1b19(RELENG_2_3_2): Tue Sep 27 12:25:49 CDT 2016 root@factory23-amd64-builder:/builder/factory-232/tmp/obj/builder/factory-232/tmp/FreeBSD-src/sys/pfSense amd64
</pre>