pfSense bugtracker: Issueshttps://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162018-12-07T08:04:09ZpfSense bugtracker
Redmine pfSense - Bug #9179 (New): NAT reflection fix implemented for #8604 is causing WebUI and XMLRPC t...https://redmine.pfsense.org/issues/91792018-12-07T08:04:09ZValentin N
<p>Ref: <a class="external" href="https://github.com/pfsense/pfsense/commit/6f8e648f5c88e04166539ab27872b13dfd587cb8">https://github.com/pfsense/pfsense/commit/6f8e648f5c88e04166539ab27872b13dfd587cb8</a> which fixed <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: Race condition in NAT reflection filter rules leads to ruleset load failure (Resolved)" href="https://redmine.pfsense.org/issues/8604">#8604</a></p>
<p>Whenever XMLRPC sync is triggered the slave no longer responds to the WebUI or XMLRPC (sometimes it takes a 2nd XMLRPC sync for this to trigger). The work-around is to restart PHP-FPM. Rolling back the commit above fixes the problem in my case.</p>
<p>It seems the call to get_interface_ip() is expensive (1 second per call), which causes each NAT reflection rule generation to take roughly 3 second to complete. With a large number of rules and gateways this seems to be a problem since the filter reload takes up to 2 minutes generate the rules. With the commit above reverted the filter reload takes less than 5 seconds.</p>
<p>I suspect there is a more optimal way to check if the interface has an IP assigned other than calling get_interface_ip(). I am not familiar with the code and, although this might not be generally true (to be verified), from my experiments it seems that get_interface_ip() returns the same value as $ifsubnet_ip, which could be substituted in place of the call.</p>