pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162024-03-28T09:25:13ZpfSense bugtracker
Redmine pfSense - Bug #15366 (New): Ethernet rules are not blocking the ARP inside the bridgehttps://redmine.pfsense.org/issues/153662024-03-28T09:25:13ZLev Prokofev
<p>Configuration:</p>
<p>1)IX2 and DMZ interfaces are bridged (192.168.168.0/24)<br />2)Filtering enabled on members of the bridge<br /> net.link.bridge.pfil_member=1 <br /> net.link.bridge.pfil_bridge=0<br />3)The ethernet rules are set to not pass the ARP from any to any, of the members of the bridge.<br /><img src="https://redmine.pfsense.org/attachments/download/5988/clipboard-202403281317-ukct1.png" alt="" /><br />Result:</p>
<p>PC1 (192.168.168.12) requested the ARP for PC2 (192.168.168.10) and received the reply, but didn't receive an ARP reply from the gateway, so the rules cut traffic from the interface of pfSense but not inside the bridge broadcast.</p>
<p><img src="https://redmine.pfsense.org/attachments/download/5989/clipboard-202403281323-c06p2.png" alt="" /></p>
<p>tested on</p>
<pre>
23.09.1-RELEASE (amd64)
built on Wed Dec 20 21:27:00 MSK 2023
FreeBSD 14.0-CURRENT
</pre> pfSense Packages - Bug #15365 (Confirmed): pfBlockerNG PHP error when editing a listhttps://redmine.pfsense.org/issues/153652024-03-27T15:47:47ZSteve Wheeler
<p>When editing an IPv4 list item I hit:<br /><pre>
PHP Errors:
[27-Mar-2024 15:22:03 Europe/London] PHP Fatal error: Uncaught ValueError: range(): Argument #3 ($step) must be greater than 0 for increasing ranges in /usr/local/www/pfblockerng/pfblockerng_category_edit.php:391
Stack trace:
#0 /usr/local/www/pfblockerng/pfblockerng_category_edit.php(391): range(1, 17, -1)
#1 {main}
thrown in /usr/local/www/pfblockerng/pfblockerng_category_edit.php on line 391
</pre></p>
<p>Looks like others have hit it editing other lists.</p>
<p>Tested:<br />pfSense-24.03.b.20240322.1708<br />pfSense-pkg-pfBlockerNG-3.2.0_9</p> pfSense - Bug #15362 (New): Config upgrade error with empty gateway interval tags.https://redmine.pfsense.org/issues/153622024-03-26T19:12:31ZSteve Wheeler
<p>Upgrading an old config that has set but empty gateway interval tags throws a php error.<br />For example a config containing:<br /><pre>
<gateway_item>
<interface>wan</interface>
<gateway>1.2.3.4</gateway>
<name>wan_gateway</name>
<weight/>
<interval/>
<descr><![CDATA[gw1]]></descr>
<defaultgw/>
</gateway_item>
</pre></p>
<p>Will hit:<br /><pre>
Fatal error: Uncaught TypeError: Unsupported operand types: string * int in /etc/inc/upgrade_config.inc:4169
Stack trace:
#0 /etc/inc/config.lib.inc(519): upgrade_130_to_131()
#1 /etc/rc.bootup(140): convert_config()
#2 {main}
thrown in /etc/inc/upgrade_config.inc on line 4169
PHP ERROR: Type: 1, File: /etc/inc/upgrade_config.inc, Line: 4169, Message: Uncaught TypeError: Unsupported operand types: string * int in /etc/inc/upgrade_config.inc:4169
Stack trace:
#0 /etc/inc/config.lib.inc(519): upgrade_130_to_131()
#1 /etc/rc.bootup(140): convert_config()
#2 {main}
</pre></p> pfSense Plus - Bug #15361 (New): Error in virtual IP aliases when using IPv6 "network" / "broadca...https://redmine.pfsense.org/issues/153612024-03-25T09:20:00ZMathis Cavalli
<p>There is no network address in IPv6, nor broadcasts like IPv4<br />When adding / editing an IP alias and putting there an address like fd00::/64 it shows the following error : "The network address cannot be used for this VIP" <br />It happened on my pfSense+ box but it seems the CE 2.7.2 is also affected.</p> pfSense - Bug #15346 (Confirmed): Port Forward Add Unassociated Filter Rule Not Workinghttps://redmine.pfsense.org/issues/153462024-03-16T21:51:40ZTimo M
<p>Upon creating a port forward entry on pfSense Plus 23.09.1 and choosing the "Add unassociated filter rule" option under Filter Rule Association, no firewall rule was actually created. Next time I checked the port forward Filter Rule Association setting on the rule that was created, it had been automatically set to "None". The documentation seems to indicate that a rule should still be created even when the unassociated option is chosen.</p>
<p><a class="external" href="https://docs.netgate.com/pfsense/en/latest/nat/port-forwards.html#port-forward-settings">https://docs.netgate.com/pfsense/en/latest/nat/port-forwards.html#port-forward-settings</a></p> pfSense Plus - Bug #15303 (New): dpinger service does not always switch from Pending to Onlinehttps://redmine.pfsense.org/issues/153032024-03-02T17:07:07ZKris Phillips
<p>There are several situations where dpinger will not detect a gateway that is available when it should, forcing a restart of the dpinger service to "trigger" it to recheck.</p>
<p>Known situations, but there may be more:</p>
<p>1. Adding a new VTI tunnel as an interface<br />2. A release/renew of an IPv6 gateway (IPv4 gateway will show up, but IPv6 will not until a dpinger restart)<br />3. Adding an OpenVPN client/server as an interface</p>
<p>Related documentation redmine: <a class="external" href="https://redmine.pfsense.org/issues/15230">https://redmine.pfsense.org/issues/15230</a></p> pfSense - Bug #15291 (New): Error on Traffic Shaper 0% Bandwidthhttps://redmine.pfsense.org/issues/152912024-02-26T09:35:21ZPavan K
<p>Link to post on pfSense Forum: <br /><a class="external" href="https://forum.netgate.com/topic/186137/error-on-traffic-shaper-0-bandwidth?_=1708915183963">https://forum.netgate.com/topic/186137/error-on-traffic-shaper-0-bandwidth?_=1708915183963</a></p>
<p>Backstory:<br />recently we migrated from pfSense 2.4.x to 2.7.2 which was a direct update. Everything worked fine etc the traffic shaping feature.</p>
<p>Following is the error:<br />There were error(s) loading the rules: pfctl: the sum of the child<br />bandwidth (1200000000) higher than parent "root_igc4" (1000000000) -<br />The line in question reads [0]: @ 2024-01-31 16:45:05</p>
<p>Following is our configuration:<br />Name → FAIRQ_7<br />Priority→ 7<br />Scheduler Option → Random Early detection in and out<br />Bandwidth → None</p>
<p>Add new Queue(Default)<br />Enable<br />Name → qFAIRQ_2(Default)<br />Priority→ 2<br />Scheduler Option → Default<br />Bandwidth → None</p>
<p>Add new Queue(ACK)<br />Enable<br />Name → qACK_6<br />Priority→ 6<br />Scheduler Option → Random Early detection in and out<br />Bandwidth → None</p>
<p>According to the configuration the Bandwidth on Queue(ACK) should be 0% which was migrated off from 2.4.x but on 2.7.2 it's not letting us save 0% bandwidth for some reason.</p>
<p>And due to this new rules which are created are not taking effect it's only after we disable and enable the Traffic Shaper completely the rule is effective.</p> pfSense - Bug #15116 (New): Kea not working with UEFI HTTPBoot URL configuredhttps://redmine.pfsense.org/issues/151162023-12-26T19:06:26ZJason Montleon
<p>I have configured and successfully use http boot to occasionally boot libvirt vms by checking off `Enable Network Booting` and entering a URL in the `UEFI HTTPBoot URL` field.</p>
<p>Seeing the banner message that ISC DHCP is deprecated I navigated to `System / Advanced / Networking` and switched to Kea DHCP. But when I do this I am no longer able to successfully use UEFI HTTPBoot.</p>
<p>Switching back and forth between ISC DHCP and Kea DHCP is all I need to do to fix and break the functionality again.</p>
<p>Looking at kea-dhcp4.conf there is nothing that stands out to me as obviously wrong, but clients never access the http server I have configured.</p> pfSense - Bug #15032 (Feedback): Kea DHCP sends wrong bootloader file for uefi boothttps://redmine.pfsense.org/issues/150322023-11-25T15:14:36ZDavid Masshardtdavid@masshardt.ch
<p>I already posted this problem in the pfSense forum and was asked to report this issue here. Here is the link of the discussion thread:<br /><a class="external" href="https://forum.netgate.com/topic/184301/kea-dhcp-uefi-pxe-boot-sends-wrong-boot-file">https://forum.netgate.com/topic/184301/kea-dhcp-uefi-pxe-boot-sends-wrong-boot-file</a></p>
<p>I'm using netboot.xyz for network booting and I just switched to Kea DHCP. After the migration I noticed that network booting from UEFI bios does not work anymore, but legacy bios boot still does work.</p>
<p>Here are the configuration values I set in pfSense:</p>
<p>TFTP Server: IP of my netboot server<br />Next Server: IP of my netboot server<br />Default BIOS File Name: netboot.xyz.kpxe<br />UEFI 32 bit File Name: netboot.xyz.efi<br />UEFI 64 bit File Name: netboot.xyz.efi<br />ARM 64 bit File Name: netboot.xyz-arm64.efi</p>
<p>The Kea DHCP server always offers the default netboot.xyz.kpxe file to UEFI machines.</p>
<p>Here are the logs from Kea DHCP for an UEFI bios:</p>
<pre>
Nov 23 12:23:55 kea-dhcp4 14098 INFO [kea-dhcp4.dhcp4.0x3e2f2f5b9300] EVAL_RESULT Expression ipxe_64_lan_pool_0 evaluated to 1
Nov 23 12:23:55 kea-dhcp4 14098 INFO [kea-dhcp4.dhcp4.0x3e2f2f5b9300] EVAL_RESULT Expression ipxe_legacy_lan_pool_0 evaluated to 1
Nov 23 12:23:55 kea-dhcp4 14098 INFO [kea-dhcp4.dhcp4.0x3e2f2f5b9300] EVAL_RESULT Expression ipxe_64_lan evaluated to 1
Nov 23 12:23:55 kea-dhcp4 14098 INFO [kea-dhcp4.dhcp4.0x3e2f2f5b9300] EVAL_RESULT Expression ipxe_legacy_lan evaluated to 1
Nov 23 12:23:55 kea-dhcp4 14098 INFO [kea-dhcp4.leases.0x3e2f2f5b9300] DHCP4_LEASE_ALLOC [hwtype=1 46:15:16:cd:59:84], cid=[no info], tid=0xaccc68dd: lease 172.17.128.2 has been allocated for 86400 seconds
Nov 23 12:23:55 kea-dhcp4 14098 INFO [kea-dhcp4.dhcpsrv.0x3e2f2f5b9300] EVAL_RESULT Expression pool_opt1_0 evaluated to 1
Nov 23 12:23:55 kea-dhcp4 14098 INFO [kea-dhcp4.dhcpsrv.0x3e2f2f5b9300] EVAL_RESULT Expression pool_lan_0 evaluated to 1
</pre>
<p>And here is the generated kea-dhcp4.conf file. (I just removed the reservations)</p>
<pre>
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [
"mlxen0",
"mlxen0.2"
]
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/kea/dhcp4.leases"
},
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "syslog"
}
],
"severity": "INFO"
}
],
"valid-lifetime": 7200,
"max-valid-lifetime": 86400,
"ip-reservations-unique": false,
"echo-client-id": false,
"option-data": [
{
"name": "domain-name",
"data": "mydomain"
}
],
"option-def": [
{
"space": "dhcp4",
"name": "ldap-server",
"code": 95,
"type": "string"
}
],
"hooks-libraries": [
{
"library": "/usr/local/lib/kea/hooks/libdhcp_lease_cmds.so"
}
],
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea4-ctrl-socket"
},
"authoritative": true,
"client-classes": [
{
"name": "ipxe_32_lan_pool_0",
"test": "option[93].hex == 0x0006",
"only-if-required": true,
"option-data": [
{
"name": "boot-file-name",
"data": "netboot.xyz.efi"
}
]
},
{
"name": "ipxe_64_lan_pool_0",
"test": "option[93].hex == 0x0007 or option[93].hex == 0x0009",
"only-if-required": true,
"option-data": [
{
"name": "boot-file-name",
"data": "netboot.xyz.efi"
}
]
},
{
"name": "ipxe_64arm_lan_pool_0",
"test": "option[93].hex == 0x000b",
"only-if-required": true,
"option-data": [
{
"name": "boot-file-name",
"data": "netboot.xyz-arm64.efi"
}
]
},
{
"name": "ipxe_legacy_lan_pool_0",
"test": "not member('ipxe_32_lan_pool_0') and not member('ipxe_64_lan_pool_0') and not member('ipxe_64arm_lan_pool_0')",
"only-if-required": true,
"option-data": [
{
"name": "boot-file-name",
"data": "netboot.xyz.kpxe"
}
]
},
{
"name": "pool_lan_0",
"test": "member('ALL')"
},
{
"name": "ipxe_32_lan",
"test": "option[93].hex == 0x0006",
"only-if-required": true,
"option-data": [
{
"name": "boot-file-name",
"data": "netboot.xyz.efi"
}
]
},
{
"name": "ipxe_64_lan",
"test": "option[93].hex == 0x0007 or option[93].hex == 0x0009",
"only-if-required": true,
"option-data": [
{
"name": "boot-file-name",
"data": "netboot.xyz.efi"
}
]
},
{
"name": "ipxe_64arm_lan",
"test": "option[93].hex == 0x000b",
"only-if-required": true,
"option-data": [
{
"name": "boot-file-name",
"data": "netboot.xyz-arm64.efi"
}
]
},
{
"name": "ipxe_legacy_lan",
"test": "not member('ipxe_32_lan') and not member('ipxe_64_lan') and not member('ipxe_64arm_lan')",
"only-if-required": true,
"option-data": [
{
"name": "boot-file-name",
"data": "netboot.xyz.kpxe"
}
]
},
{
"name": "pool_opt1_0",
"test": "member('ALL')"
}
],
"subnet4": [
{
"id": 1,
"subnet": "172.17.0.0/16",
"option-data": [
{
"name": "domain-name",
"data": "mydomain"
},
{
"name": "domain-search",
"data": "mydomain"
},
{
"name": "domain-name-servers",
"data": "172.17.1.1"
},
{
"name": "routers",
"data": "172.17.1.1"
},
{
"name": "netbios-name-servers",
"data": "172.17.2.1"
},
{
"name": "netbios-node-type",
"data": "8"
}
],
"pools": [
{
"pool": "172.17.128.0 - 172.17.128.199",
"client-class": "pool_lan_0",
"option-data": [
{
"name": "domain-name-servers",
"data": "172.17.1.1"
},
{
"name": "tftp-server-name",
"data": "172.17.2.17"
}
],
"require-client-classes": [
"ipxe_legacy_lan_pool_0",
"ipxe_32_lan_pool_0",
"ipxe_64_lan_pool_0",
"ipxe_64arm_lan_pool_0"
]
}
],
"valid-lifetime": 86400,
"next-server": "172.17.2.17",
"require-client-classes": [
"ipxe_legacy_lan",
"ipxe_32_lan",
"ipxe_64_lan",
"ipxe_64arm_lan"
],
"reservations-in-subnet": true
},
{
"id": 2,
"subnet": "172.20.0.0/16",
"option-data": [
{
"name": "domain-name-servers",
"data": "172.20.1.1"
},
{
"name": "routers",
"data": "172.20.1.1"
}
],
"pools": [
{
"pool": "172.20.128.0 - 172.20.128.255",
"client-class": "pool_opt1_0",
"option-data": [
{
"name": "domain-name-servers",
"data": "172.20.1.1"
}
]
}
],
"valid-lifetime": 86400,
"reservations-in-subnet": true
}
]
}
</pre>
<p>I noticed that the legacy classes in the require-client-classes are on top of all the other classes. After i changed the order so that the legacy classes are at the bottom netboot worked for legacy and UEFI boot.</p>
<p>I also created a patch file that fixes the problem in the services.inc file:</p>
<pre><code class="diff syntaxhl"><span class="gd">--- /etc/inc/services.inc.save 2023-11-24 15:19:26.797541000 +0100
</span><span class="gi">+++ /etc/inc/services.inc 2023-11-24 15:24:17.000000000 +0100
</span><span class="p">@@ -1548,7 +1548,7 @@</span>
if (!is_array($keapool['require-client-classes'])) {
$keapool['require-client-classes'] = [];
}
<span class="gd">- array_unshift($keapool['require-client-classes'], $name);
</span><span class="gi">+ $keapool['require-client-classes'][] = $name;
</span> }
if (!empty($poolconf['rootpath'])) {
<span class="p">@@ -1719,7 +1719,7 @@</span>
if (!is_array($keasubnet['require-client-classes'])) {
$keasubnet['require-client-classes'] = [];
}
<span class="gd">- array_unshift($keasubnet['require-client-classes'], $name);
</span><span class="gi">+ $keasubnet['require-client-classes'][] = $name;
</span> }
if (!empty($dhcpifconf['rootpath'])) {
</code></pre>
<p>Can you please take a look at this if this is the correct solution to this problem?</p> pfSense - Bug #14936 (Feedback): radvd service shows as stopped in services list when it should b...https://redmine.pfsense.org/issues/149362023-11-01T15:03:21ZJim Pingle
<p>The <code>is_radvd_enabled()</code> function in <code>pfsense-utils.inc</code> appears to incorrectly interpret the state of the radvd service in some cases.</p>
<p>For example I have a system with WAN DHCP6, LAN Track6 to WAN, but on LAN I have DHCPv6 disabled and RA disabled. When configured in this way, the radvd service is shown in the services list, but is listed as stopped. The <code>radvd.conf</code> file only contains the header, which is expected since there are no interfaces with RA enabled.</p> pfSense - Bug #14933 (Confirmed): Traffic Graph Widget only displays half of the real UL/DL bandw...https://redmine.pfsense.org/issues/149332023-10-28T21:48:22ZPatrik Stahlman
<p>Problem description:<br />The Traffic Graphs Widget fails to display the real bandwidth used after the Dashboard browser tab loses and regains visibility. The problem is fairly easily reproducable.</p>
<p>My Traffic Graphs Widget configuration:<br /><code>Refresh interval: 1<br />Inverse: On<br />Unit size: bits<br />Background updates: clear graphs when not visible<br />Graph smoothing: 0</code></p>
Problem reproduction:
<ul>
<li>configure the widget as above</li>
<li>start downloading a large file at consistetly high speed (100Mb/s in my case, WAN max speed) </li>
<li>verify that the Traffic Graphs Widget shows the expected speed</li>
<li>switch away from the dashboard (in my case to another virtual desktop)</li>
<li>switch back to the dashboard and note the Traffic Graphs widget is resetting the graph</li>
<li>the widget should now show half the expected interface speed (50Mb/s in my case)</li>
</ul>
<p>Bug and fix:<br />I found the root cause of this problem in /usr/local/www/js/traffic-graphs.js. <br />The existing code to handle the case where graph smoothing is zero is not imlpemented consistently.</p>
<p>The values for the graph is calculated here:<br /><code> 286 var trafficIn = ( priorIn[interfaceCount].reduce(function(a, b){ return a + b; },0) + currentIn)/(1 + priorIn[interfaceCount].length);<br /> 287 var trafficOut = ( priorOut[interfaceCount].reduce(function(a, b){ return a + b; },0) + currentOut) /(1 + priorOut[interfaceCount].length);<br /></code> <br />When the graph is correct, variables <code>priorX[interfaceCount].length</code> is zero as would be expected when smoothing is not taking place.</p>
<p>When the graph is incorrect, variables <code>priorX[interfaceCount].length</code> is one. This is what is causing the halving of the indicated speed as the division is by 2.</p>
<p>This is the piece of code that incorrectly adds an entry to the list even though no smoothing is active:<br /><code> 288 // circular array to keep track of 'x' amount of data points<br /> 289 priorIn[interfaceCount][smoothCount] = currentIn;<br /> 290 priorOut[interfaceCount][smoothCount] = currentOut;</code></p>
<p>With smoothing = 0 this piece of code also has unexpected side effects, smoothCount = NaN after % with zero<br /><code> 340 // increment the circular array<br /> 341 smoothCount ++;<br /> 342 smoothCount = smoothCount % smoothing;</code></p>
<p>The attached patch fixes these issues by wrapping the code in "if(smoothing > 0) {}" blocks</p>
<p>This issue was found in Plus 23.05.1 but I expect it is present in all versions of pfSense.</p> pfSense Plus - Bug #14894 (New): Password protected console login prompt does not render properly...https://redmine.pfsense.org/issues/148942023-10-18T19:47:24ZJim Pingle
<p>After resolving other console issues with the 4100/6100/8200 in <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: Serial console output fails to render properly in certain cases on 4100, 6100, and 8200. (Resolved)" href="https://redmine.pfsense.org/issues/13455">#13455</a> a problem remains with the login prompt.</p>
<p>It is not printing a newline before the FreeBSD version string nor is it printing a newline before the password prompt:</p>
<pre>
[...])FreeBSD/amd64 (pfsense.home.arpa) (ttyu0)
login: rootPassword:
Netgate 4100 [...]
</pre>
<p>It should look like this:</p>
<pre>
FreeBSD/amd64 (pfsense.home.arpa) (ttyu0)
login: root
Password:
Netgate 4100 [...]
</pre>
<p>Changing the console type doesn't have any effect, nor does changing various aspects of the TTY (e.g. setting it to <code>xterm</code> or <code>cons25w</code> instead of <code>vt100</code>, or using <code>std</code> instead of <code>3wire</code>).</p> pfSense - Bug #14371 (New): Firewall does not respond to UDP traceroute requests over IPsechttps://redmine.pfsense.org/issues/143712023-05-10T22:08:35ZMarcos M
<p>Tested on <code>23.01</code>.</p>
<p>pfSense itself does not respond to UDP traceroutes when it receives the request over IPsec (both policy/routed tunnels tested, as well as with pf disabled).</p>
<p>In the following example, traceroute is run from a LAN client behind siteA to the LAN interface address of siteB.<br /><pre>
### siteA client
[22.01-DEVELOPMENT][root@sitea-lanhost.lab.arpa]/root: traceroute -n -I 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 64 hops max, 48 byte packets
1 172.19.1.1 0.337 ms 0.106 ms 0.174 ms
2 192.168.1.1 0.684 ms 0.607 ms 0.531 ms
[22.01-DEVELOPMENT][root@sitea-lanhost.lab.arpa]/root: traceroute -n 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 64 hops max, 40 byte packets
1 172.19.1.1 0.283 ms 0.185 ms 0.189 ms
2 * * *
3 * *^C
### siteB firewall
[23.01-RELEASE][root@siteb-fw1.lab.arpa]/root: ifconfig vmx1
vmx1: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: LAN
options=4e000bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
ether 00:50:56:b2:00:fe
inet6 fe80::250:56ff:feb2:fe%vmx1 prefixlen 64 scopeid 0x2
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
[23.01-RELEASE][root@siteb-fw1.lab.arpa]/root: tcpdump -ni enc0 'host 172.19.1.4'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 262144 bytes
19:01:30.681093 (authentic,confidential): SPI 0xca57b541: IP 172.19.1.4 > 192.168.1.1: ICMP echo request, id 32776, seq 4, length 28
19:01:30.681173 (authentic,confidential): SPI 0xcaa92d26: IP 192.168.1.1 > 172.19.1.4: ICMP echo reply, id 32776, seq 4, length 28
19:01:30.681567 (authentic,confidential): SPI 0xca57b541: IP 172.19.1.4 > 192.168.1.1: ICMP echo request, id 32776, seq 5, length 28
19:01:30.681586 (authentic,confidential): SPI 0xcaa92d26: IP 192.168.1.1 > 172.19.1.4: ICMP echo reply, id 32776, seq 5, length 28
19:01:30.682120 (authentic,confidential): SPI 0xca57b541: IP 172.19.1.4 > 192.168.1.1: ICMP echo request, id 32776, seq 6, length 28
19:01:30.682142 (authentic,confidential): SPI 0xcaa92d26: IP 192.168.1.1 > 172.19.1.4: ICMP echo reply, id 32776, seq 6, length 28
19:01:34.226850 (authentic,confidential): SPI 0xca57b541: IP 172.19.1.4.32816 > 192.168.1.1.33438: UDP, length 12
19:01:39.310089 (authentic,confidential): SPI 0xca57b541: IP 172.19.1.4.32816 > 192.168.1.1.33439: UDP, length 12
19:01:44.388844 (authentic,confidential): SPI 0xca57b541: IP 172.19.1.4.32816 > 192.168.1.1.33440: UDP, length 12
^C
9 packets captured
242 packets received by filter
0 packets dropped by kernel
</pre></p>
<p>Traceroutes to other clients on the siteB LAN work fine.</p> pfSense Packages - Bug #13654 (New): Wireguard does not fail back failover WAN setup.https://redmine.pfsense.org/issues/136542022-11-12T06:05:53ZFrode Martin
<p>I have this main WAN connection that is quite unstable. So I set up a 4G router on the OPT port on netgate 1100. This port is configured as a tier 2, and is only used if main WAN connection is down. This works great for ordinary traffic, but not for wireguard. Wireguard fails over to OPT-port OK when WAN connection goes down. But not back when WAN connection is up again. I have to disable and then enable the opt port to manually change interface for wireguard.</p>
<p>Wireguard version is 0.1.6_2.</p> pfSense - Bug #13624 (New): Only one alias in local network of OpenVPN Server works in 2.6.0https://redmine.pfsense.org/issues/136242022-11-02T11:55:36ZFlorian Bat
<p>Issue <a class="issue tracker-2 status-3 priority-4 priority-default closed" title="Feature: Support aliases in OpenVPN local/remote/tunnel network fields (Resolved)" href="https://redmine.pfsense.org/issues/2668">#2668</a> implemented the possibility to have host/network aliases in the OpenVPN local/remote/tunnel network fields.</p>
<p>When using host aliases in the local network field, it seems only the hosts of the very first alias are pushed to the client as local network. all other aliases seem to be ignored.</p>
<p><strong>Example:</strong><br />Let's say I have 3 host alias lists (named alias1, alias2 and alias3) with 2 hosts defined in each alias.</p>
<p>Using this as "local network" in the OpenVPN Server definition only pushes the ips of the <strong>alias1</strong> list.</p>
<pre><code class="html syntaxhl">alias1, alias2, alias3
</code></pre>
<p>This only pushes the hosts of <strong>alias2</strong>:</p>
<pre><code class="html syntaxhl">alias2, alias3, alias1
</code></pre>
<p>And this would push the two hosts of <strong>alias1</strong> plus the <strong>192.168.1.0/24</strong> and <strong>192.168.2.0/24</strong> networks as local networks.</p>
<pre><code class="html syntaxhl">alias1, alias2, 192.168.1.0/24, alias3, 192.168.2.0/24
</code></pre>
<p>I am using<br />2.6.0-RELEASE (amd64)<br />built on Mon Jan 31 19:57:53 UTC 2022<br />FreeBSD 12.3-STABLE</p>