pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162020-09-17T00:19:29ZpfSense bugtracker
Redmine pfSense - Feature #10904 (Pull Request Review): Support vti interfaces in dhcrelayhttps://redmine.pfsense.org/issues/109042020-09-17T00:19:29ZFrederic Bor
<p>One can want to relay dhcp requests using pfSense threw IPsec vti interfaces.</p>
<p>It's quite easy to support them, since it's only the hardware header that has been removed (or more exactly replaced with four bytes).</p> pfSense - Bug #10875 (New): PPP periodic reset does not fully restore gateway group round-robin f...https://redmine.pfsense.org/issues/108752020-09-07T08:31:22ZDaniel Pereira
<p>I'm using a Multi-WAN setup with two links working in a load-balancer fashion.</p>
<p>I set up a periodic reset for both my PPP connections every 24h so I get new IP addresses. One link is reset at 4:20 and the other at 4:21.</p>
<p>I noticed that the link that gets restarted last is never able to actually come back fully: the router doesn't seem to round-robin the outbound connections anymore, and I only get to use the speed of one link. If you go to the gateway status, both gateways will be green and the "Load balanced" gateway group will be green too. No visual signal that the one link is not being actually used.</p>
<p>If I manually go and reset the filter, then it all comes back to work normally.</p>
<p>It took me some time until I traced this down to this. I tested it using SpeedTest.net with multi-connections (the default) - and by looking at the states table (noticing that one link gets ALL outbound while the other, almost none).</p> pfSense - Bug #10708 (New): ZFS bootpool boot symlink issuehttps://redmine.pfsense.org/issues/107082020-06-27T00:49:48ZPaul Magid
<p>Using 2.5.0-DEVELOPMENT when I do an install that creates a zfs mirror (MBR), the boot directory is actually a symlink to the boot directory in the bootpool pool. As soon as I do an upgrade to a newer build the boot directory symlink is overwritten and a directory called boot is created. The boot directory in bootpool goes out of sync with the boot directory that is now physically present on the zroot pool. This causes issues with kernel module mismatches etc.</p> pfSense - Bug #9123 (Feedback): Adding/configuring vlan on ixl-devices causes aq_add_macvlan err ...https://redmine.pfsense.org/issues/91232018-11-15T10:50:14ZSebastian Deuerling
<p>The actual vlan addition/configuring process is triggering error "aq_add_macvlan err -53, aq_error 14" on ixl-devices.<br />Configuring vlans seems to work nevertheless, but saving interface configurations with vlans takes a lot of time.<br />In our setup (two igb-interfaces, two ix-interfaces, two ixl-interfaces; 25 vlans on failover-lagg of ixl0 and igb0) saving changes on interface configuration lasts around about 20 to 30 minutes. After that pfSense seems to freeze. After reboot all vlans are working.<br />But booting also takes a lof of time. Around 5 minutes in step "Configuring VLANS...".<br />Our hardware: SYS-5018D-FN4T (Supermicro Intel Xeon D-1541 system) and X710DA2BLK (Intel X710-DA2 Dual-SFP+-PCIe-Addon-cards).<br />Further information here: <a class="external" href="https://forum.netgate.com/topic/136201/new-version-2-4-4-interface-error-aq_add_macvlan-err-53-aq_error-14/14">https://forum.netgate.com/topic/136201/new-version-2-4-4-interface-error-aq_add_macvlan-err-53-aq_error-14/14</a></p> pfSense - Bug #8964 (New): IPsec async cryptography advanced setting - TCP traffic not passing t...https://redmine.pfsense.org/issues/89642018-09-27T02:25:33ZVladimir Lind
<p>Test setup:</p>
<p>Windows <-> SG2220 2.4.4-rel <---IPSEC---> SG3100 2.4.4-rel <-> Windows</p>
<p>IPsec (tunnel mode) with following settings:<br />P1 - mode Auto, AES128, SHA256, DH14<br />P2 - AES128GCM, no hash, PFS 14</p>
<p>ICMP between Win hosts is OK.<br />But SMB traffic is not going through with Async Crypto enabled on any side. I do see established TSP session. When I disable async crypto - SMB download immediately begin to flow.<br />Attached a packet dump sniffed on LAN of the 3100 - it is a snippet of the moment when async was disabled (lines 12-15) and SMB began to work.</p>
<p>Please refer also to trouble tickets 12812 and 12864 for additional details.</p> pfSense - Bug #8815 (New): IP addresses are removed from interfaces when link is lost and either ...https://redmine.pfsense.org/issues/88152018-08-20T12:02:08ZJim Pingle
<p>When an interface loses link the IPv4 addresses, including VIPs, can disappear from the interface. If the link is down when the interface settings are applied, the address is present, but plugging in the interface and then removing the link again can make the addresses disappear.</p>
<p>The behavior is not consistent across all configurations and hardware. For example, it appears to happen predictably on <code>igb(4)</code> interfaces but not <code>vmx(4)</code> interfaces, and in some cases <code>re(4)</code> is OK and fails for others.</p>
<p>The main consequence is that anything bound to or relying on those addresses will fail when they disappear. The highest impact is from HA/CARP. The VIPs disappear from the interface, so the OS does not trigger demotion as expected with link loss.</p>
<p>IPv6 addresses, if any exist, are still present on the interfaces after link is lost.</p>
<p>For example, on an SG-5100. LAN is unplugged before the test:<br /><pre>
igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=6400bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
ether 00:90:0b:7a:8a:66
hwaddr 00:90:0b:7a:8a:66
inet 10.23.0.1 netmask 0xffffff00 broadcast 10.23.0.255
inet6 2001:db8:1:ee10:290:bff:fe7a:8a66 prefixlen 60
inet6 fe80::1:1%igb1 prefixlen 64 scopeid 0x2
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect
status: no carrier
</pre></p>
<p>Plug in LAN, then unplug LAN:</p>
<pre>
igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=6400bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
ether 00:90:0b:7a:8a:66
hwaddr 00:90:0b:7a:8a:66
inet6 2001:db8:1:ee10:290:bff:fe7a:8a66 prefixlen 60
inet6 fe80::1:1%igb1 prefixlen 64 scopeid 0x2
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect
status: no carrier
</pre>
<p>Logs for igb1 during the transition:<br /><pre>
Aug 20 11:54:29 missy kernel: igb1: link state changed to UP
Aug 20 11:54:29 missy check_reload_status: Linkup starting igb1
Aug 20 11:54:29 missy check_reload_status: Reloading filter
Aug 20 11:54:30 missy php-fpm[585]: /rc.linkup: DEVD Ethernet attached event for lan
Aug 20 11:54:30 missy php-fpm[585]: /rc.linkup: HOTPLUG: Configuring interface lan
Aug 20 11:54:30 missy check_reload_status: Restarting ipsec tunnels
Aug 20 11:54:33 missy check_reload_status: Linkup starting igb1
Aug 20 11:54:33 missy kernel: igb1: link state changed to DOWN
Aug 20 11:54:34 missy php-fpm[584]: /rc.newwanip: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1534780474] unbound[62993:0] error: bind: address already in use [1534780474] unbound[62993:0] fatal error: could not open ports'
Aug 20 11:54:34 missy check_reload_status: updating dyndns lan
Aug 20 11:54:34 missy php-fpm[39495]: /rc.linkup: DEVD Ethernet detached event for lan
Aug 20 11:54:35 missy check_reload_status: Reloading filter
</pre></p> pfSense - Bug #8611 (In Progress): unable to receive IPv6 RA's on SG-1000, default route losthttps://redmine.pfsense.org/issues/86112018-06-30T16:44:03ZAnthony Roberts
expected behavior:
<ul>
<li>IPv6 default route is stable indefinitely</li>
</ul>
actual behavior:
<ul>
<li>IPv6 default route is lost a few minutes after release/renew</li>
<li>WAN interface still has IPv6 address</li>
<li>LAN interface still has /64</li>
<li>pfsense router has no default route, so it is impossible to route IPv6 traffic</li>
</ul>
configuration:
<ul>
<li>residential comcast connection</li>
<li>SG-1000 running 2.4.3-RELEASE-1 (arm)</li>
<li>WAN interface (cpsw0) configured for DHCPv4, DHCPv6-PD</li>
<li>LAN interface (cpsw1) configured to track WAN for PD</li>
</ul>
investigation:
<ul>
<li>attempted to run tcpdump on WAN interface</li>
<li>tcpdump shows RAs received from ISP<br /><pre>
21:04:22.040097 00:01:5c:7a:d0:46 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 198: fe80::201:5cff:fe7a:d046 > ff02::1: ICMP6, router advertisement, length 144
</pre></li>
<li>RA dest IPv6 multicast address appears to be correct, MAC address appears to be correct for IPv6 multicast</li>
<li>when running tcpdump, IPv6 default route is re-added to pfsense routing table</li>
</ul>
hypothesis:
<ul>
<li>tcpdump places cpsw0 interface is promiscuous mode, and when in promiscuous mode, RA's are received</li>
<li>when cpsw0 not in promiscuous mode, RA's are not received</li>
<li>works temporarily on release/renew possibly because IPv4 DHCP client places interface in promiscuous mode temporarily when acquiring lease</li>
</ul>
experiment 1:
<ul>
<li>"ifconfig cpsw0 promisc" </li>
<li>result: IPv6 default route is stable over several days</li>
</ul>
experiment 2:
<ul>
<li>"ifconfig cpsw0 -promisc; tcpdump -pni cpsw0" </li>
<li>-p flag prevents tcpdump from placing interface in promiscuous mode</li>
<li>result: ISP RAs are not seen</li>
</ul>
workaround:
<ul>
<li>use shellcmd pkg to run "ifconfig cpsw0 promisc" on startup</li>
</ul> pfSense - Bug #8100 (New): pfsync Initially Deletes States on Primary for Connections Established...https://redmine.pfsense.org/issues/81002017-11-15T16:06:36ZChris Linstruth
<p>Steps to duplicate:</p>
<p>Create a typical HA pair.<br />Enter Persistent CARP Maintenance Mode on Primary to initiate a fail over.<br />Establish a new TCP session. Was tested here with a long scp transfer to an outside server from an inside host.<br />Observe states created on both nodes with traffic going through Secondary.<br />Leave Persistent CARP Maintenance Mode on Primary, initiating fail back.<br />Observe states deleted from Primary but still exist on Secondary. Traffic in TCP session stalls.<br />Enter Persistent CARP Maintenance Mode on Primary to initiate a fail over. Wait for TCP session to start passing traffic again.<br />Observe states recreated on Primary.<br />Fail back and fail over again at will. States will now persist until closed.</p>
<p>Condition does not exist if states are initially established while Primary is the CARP MASTER.</p>
<p>Tested with latest 2.4.2 snapshots.</p> pfSense - Bug #8013 (New): IPsec MSS clamping value shared for IPv4 and IPv6https://redmine.pfsense.org/issues/80132017-10-25T23:50:39ZKristopher Kolpin
<p>MSS clamping for IPsec can only be set globally. As a result, a value of 1452 for an IPv4 tunnel (required due to my pppoe WAN) is not suitable for an IPv6 tunnel. The latter in my case requires an IPsec MSS clamping value of 1346 for IPv6 web sites accessed across the tunnel to load.</p>
<p>Separate MSS clamping options in the GUI would allow more efficient use of IPv4 tunnels when IPv6 tunnels are also present.</p> pfSense - Bug #7389 (In Progress): Limiter does not work with transparent proxyhttps://redmine.pfsense.org/issues/73892017-03-15T06:10:26ZNelson Junior
<p>Good morning the limiter returned to present problems, identical to the other bug already reported and resolved and reported on this link <a class="external" href="https://redmine.pfsense.org/issues/7050">https://redmine.pfsense.org/issues/7050</a>, detail did not change any rule I was only updating transparent proxy use.</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> pfSense - Bug #6333 (Confirmed): Bootup starts/restarts dpinger multiple timeshttps://redmine.pfsense.org/issues/63332016-05-08T00:22:39ZNOYB NOYBJunkYardMail1@Frontier.com
<p>The setup_gateways_monitor function is called multiple times during boot up by rc.boot, rc.newwanip, and rc.newwanipv6.</p>
<p>Each time stopping and restarting dpinger.</p> pfSense - Bug #4479 (New): Firewall rules won't match GRE interface after applying IPSEC transpor...https://redmine.pfsense.org/issues/44792015-02-27T15:25:10ZJonathan Black
<p>I have an issue with IPSEC where my GRE tunnels work fine until I turn on transport encryption with IPSEC. After IPSEC is enabled, I can ping across the tunnel (I can also ping between the hosts on both ends), but any connections across the tunnel will be blocked by the PFSense router on the far end (It appears that none of my rules match anymore and only the default block rule will match). I have been able to reproduce this bug in a physical and virtual environment (I have it running in Hyper-V and can produce that if you wish). Everything will start working correctly again if I disable IPSEC on both ends of the tunnel.</p>
<p>I've attached the backup files for both R1 and R2 PFsense routers. They are configured just as show in the Network Map attached. The GRE tunnel is not shown on the map. R1's GRE interface is 192.168.112.1/24. R2's GRE interface is 192.168.112.2/24. The 192.168.25.X network is the WAN interfaces on the routers with the 172.X.X.X interfaces are the LAN interfaces. The default password is "pfsense" on these.</p>
<p>I've also attached pictures of my firewall rules (Allow Everything) and then pictures of the log where an RDP connection is being blocked.</p>
<p>Please let me know if there is anything else I can do to help provide you additional information.</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 - Bug #1819 (New): DNS Resolver Not Registering DHCP Server Specified Domain Namehttps://redmine.pfsense.org/issues/18192011-08-29T15:37:36ZNOYB NOYBJunkYardMail1@Frontier.com
<p>DHCP Server specified Domain Name not being registered in DNS Forwarder.</p>
<p>Hosts are resolvable by System General specified domain name instead.</p>
<p>Is this expected mode of opperation? Seem like they should be registered with the domain name they are being assigned.</p>
<p>2.0-RC3 (i386) <br />built on Sun Aug 28 15:02:45 EDT 2011</p>