Reloading rules taking a long time

[elr90]

I got somewhat 200 NAT and firewall rules in my pfSense box. It seems that when I'm adding a new rule it takes 3-5 minutes before it's active. Does pfSense really take this long to refresh/activate new rules?

Is this behavior normal? If so, can it be optimized anyway?

Thanks.

[jimp]

It doesn't normally take that long.

Are you using any hostnames in firewall rules, aliases, or IPsec? It could be DNS slowing it down.

[elr90]

I have a lot of virtual IP's and some aliases. 90% of my NAT rules are just regular tcp/udp forwards from one external ip/port to one internal ip/port. Sometimes with a range of two ports.

Does it have an impact that I'm adding/removing rules very often? We're talking every minute or so. My pfSense box is the center of my system with dynamic changes all the time.

There's no involved, just one ext. ip to one int. ip.

[jimp]

Why are you adding and removing rules every minute or so? That seems rather a lot.

What kind of rules are you adding that don't take effect for a while? If it's a block rule, you may just be seeing that traffic is still allowed because there is an existing state. When adding a block rule you need to clear the states for that IP to close the existing connections.

Pass rules should take effect immediately.

[elr90]

In my log I see the command check_reload_status: reloading filter - I guess this is why the rules take 5 minutes to be activated. Can you confirm this?

If yes, I should just figure out how to call the check_reload_status command from my custom php script, so rules are reloaded whenever added… You shouldn't happen to know how to do this / what the php function to initialize a check_reload_status is called? :-)

[jimp]

In php you can just call filter_configure() if you include the right files.

Though I still find it hard to believe doing that many rule insertions/deletions is a good idea…

[elr90]

@jimp:

In php you can just call filter_configure() if you include the right files.

Though I still find it hard to believe doing that many rule insertions/deletions is a good idea…

I don't really have much of a chose when it comes to adding/deleting so many rules :-)

I have:

unlink_if_exists("/tmp/config.cache");
$retval |= filter_configure();

if ($retval == 0) {
if (file_exists($d_natconfdirty_path))
unlink($d_natconfdirty_path);
if (file_exists($d_filterconfdirty_path))
unlink($d_filterconfdirty_path);
}

in my script. Shouldn't that do the trick of instant reloading the rules? .. Or should I just call the filter_configure(); function and skip the rest?

[jimp]

Just call filter_configure() and let it do the rest.

[elr90]

@jimp:

Just call filter_configure() and let it do the rest.

When calling the filter_configure() function in php, executed via a http request, it does not show a new entry in the log file that check_reload_status: reloading filter has been executed. Is it suppose too?

It does not seem like the rules are reloaded more than once every 5 minute..

[elr90]

An update after some debugging… It seems that my rules are reloaded instantly after a change has been submitted, but it takes nothing but 5 full minutes or more to execute the filter_configure_sync() php command which is being initialized by the check_reload_status.c file ..

Any guesses to why it takes 5 minutes to reload my rules? Config file is 104kb, I have 325 rules (nat and firewall rules together) and 27 VIP's.

EDIT:
3 hours of debugging and a lot of coffie later I found the issue.. It seems my CARP sync was not working. After I edited rc.filter_configure_sync to show some microtime of how long each part took, it was clear that my CARP sync was the issue. Disabling this fixed the issue - now it reloads new rules very quickly, very neat.

Today's lesson: Lean to fix your own errors... :-)

Thx to jimp for helping! I gained a lot of nice knowledge about pfSense in the process.