Outgoing NTP requests via pfBlocker VIP

cybis

I'm observing a weird issue where NTP requests are going out via the pfBlocker DNSBL VIP and not the public WAN IP. I don't understand how this can happpen As a result, there are no responses from the NTP servers and my local clients can't perform time synchronisation. Anyone else observed a similar behaviour?

Running ntpdate in the shell shows NTP server responses though:

ntpdate -q 0.pfsense.pool.ntp.org
server 5.75.181.179, stratum 3, offset +1.125864, delay 0.04985
server 158.101.188.125, stratum 2, offset +1.124029, delay 0.04755
server 162.159.200.123, stratum 3, offset +1.123828, delay 0.04124
server 141.84.43.74, stratum 2, offset +1.126544, delay 0.07703
14 Mar 23:50:06 ntpdate[37686]: step time server 158.101.188.125 offset +1.124029 sec

Here's the NTP status and logs:

Here's my VIPs:

Here are the NTP settings:

Here are the WAN related outbound NAT settings:

And here's a list of installed packages:

cybis

I‘m running CE 2.8.1.

elvisimprsntr

@cybis

My config is not nearly as complicated (no VLANs, VIPs, HAProxy, pfBlocker, etc.), but seems like a routing or DNS issue.

Also, pool.ntp.org has been migrating their infrastructure in recent weeks and has had a host of problems. Try a different pool.

time.nist.gov

Is localhost selected?

Otherwise, start with a simple config, then progressively make changes until it breaks again.

cybis

@elvisimprsntr thanks for your inputs. Yes, the Localhost is in the list of selected NTP interfaces. And I've also tested other NTP servers with the same result.

Next step will be to remove pfBlocker (including its configuration) and set it up from scratch.

stephenw10

Hmm, interesting. It's probably using that because the VIP is on localhost and that's logically closest to the destination.

When you select interfaces for NTP like that it also uses them as the source IP list for queries. So since you don't have WAN selected it doesn't use it.

The default setting where no interfaces are selected there implies all interfaces and that then allows it to use WAN dircetly.

So you could add WAN to the selection there knowing that firewall rules prevent anything external connecting to NTP directly.

cybis

@stephenw10 Thanks a lot for the response. I have overall 3 firewalls with the same configuration and 2 out of 3 are showing this issue. The third one is working as expected. So the behaviour is not deterministic then and reinstalling pfBlocker won't necessarily help?

I'm still trying to understand though how this behaviour is possible at all. The selected NTP interfaces are being listened on for incoming NTP requests and shouldn't be used to send any NTP request, right? If the Localhost interface is selected, then one wouldn't expect any outbound NTP queries from any of its VIPs either? Or am I missing something here? On the other hand, if this was true, your proposed workaround to select the WAN interface additionally wouldn't work then either

EDIT: OK, you already stated that selected interfaces are also used for queries I'll need to do some packet inspection on the local interfaces to better understand the NTP traffic.
@stephenw10 said in Outgoing NTP requests via pfBlocker VIP:

When you select interfaces for NTP like that it also uses them as the source IP list for queries. So since you don't have WAN selected it doesn't use it

As you suggested, selecting the WAN interface solves the issue.