pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162019-04-12T14:52:42ZpfSense bugtracker
Redmine pfSense - Bug #9471 (Resolved): GIF tunnel not added to interface group after reboothttps://redmine.pfsense.org/issues/94712019-04-12T14:52:42ZFoster Snowhill
<p>Hello!</p>
<p>I have a GIF tunnel (gif0, opt4, TUN_6IN4_HE) configured as part of an interface group (PFORWARD_WAN). It gets added successfully when configured from the web interface, however it's not added to an interface group after reboot, so I have to manually remove and readd it again from the web interface.</p>
<p>pfSense version 2.4.4-p2 running on ESXi.</p>
<p>Snippet from config.xml:</p>
<pre>
<opt4>
<descr><![CDATA[TUN_6IN4_HE]]></descr>
<if>gif0</if>
<enable></enable>
<blockpriv></blockpriv>
<blockbogons></blockbogons>
<spoofmac></spoofmac>
<mtu>1480</mtu>
</opt4>
<ifgroups>
<ifgroupentry>
<members>opt7 opt3 opt4 opt2 opt1 wan</members>
<descr><![CDATA[Interfaces to allow forwarded traffic on (WAN)]]></descr>
<ifname>PFORWARD_WAN</ifname>
</ifgroupentry>
...
</ifgroups>
</pre>
<p>gif0 after reboot:</p>
<pre>
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1480
...
groups: gif
</pre>
<p>Same interface after removing/readding in the web UI:</p>
<pre>
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1480
...
groups: gif PFORWARD_WAN
</pre>
<p>Didn't find anything in system.log, dmesg or in other logs that could be related to the issue.</p> pfSense - Bug #9466 (Resolved): DHCP (IPv4) relay mistakenly listening on upstream interfacehttps://redmine.pfsense.org/issues/94662019-04-10T09:14:13ZFoster Snowhill
<p>Hello!</p>
<p>Not sure if this is dhcrelay's intended behaviour, but it is listening on the upstream interface when it's not asked to, and thus duplicates packets coming from inside the upstream network.</p>
<p>My interfaces:</p>
<ul>
<li>LAN_TN = lan = vmx0 (192.168.2.1/24)</li>
<li>LAN_UN = opt3 = vmx0.10 (192.168.3.1/24)</li>
<li>LAN_Docker = opt7 = vmx0.20 (192.168.6.1/24)</li>
</ul>
<p>DHCP relay is configured as shown in the attached <em>relay_config.png</em>. Config.xml looks like this:</p>
<pre>
<dhcrelay>
<interface>opt7,opt3</interface>
<server>192.168.2.8</server>
<agentoption></agentoption>
<enable></enable>
</dhcrelay>
</pre>
<p>However it starts up listening on the upstream as well:</p>
<pre>
/usr/local/sbin/dhcrelay -i vmx0.20 -i vmx0.10 -i vmx0 -a -m replace 192.168.2.8
</pre>
<p>which causes it to catch the broadcast packets on the upstream network and duplicate those requests, as seen on <em>packets.png</em>. pfSense 2.4.4-p2 running on amd64, ESXi VM.</p>
<p>Not critical im my setup, but might be problematic for those whose upstream DHCP server is located on the WAN, for example.</p>