Project

General

Profile

Actions

Bug #4074

closed

Status NTP does not display any result if IPv6 Allow is off

Added by Phillip Davis over 9 years ago. Updated about 9 years ago.

Status:
Resolved
Priority:
Normal
Category:
NTPD
Target version:
Start date:
12/03/2014
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2
Affected Architecture:

Description

Forum: https://forum.pfsense.org/index.php?topic=84890.0

ntpq by default tries to ask ntpd for status using the IPv6 socket, which ntpd is listening on. But in this scenario the firewall itself is blocking the IPv6 socket.

Tell it explicitly to use IPv4 when ipv6allow is off, and it works.

Pull request: https://github.com/pfsense/pfsense/pull/1361

There could be some thought given to anything else that might be trying to talk locally on IPv6 sockets that might have a similar problem when ipv6allow is off.


Files

IPv6Blocked.png (140 KB) IPv6Blocked.png Screenshot Andy Sayler, 01/03/2015 10:28 PM
Actions #1

Updated by Chris Buechler over 9 years ago

  • Status changed from New to Feedback

Good catch, thanks. I merged that.

Wondering if it'd be best to allow localhost to localhost v6 connectivity regardless of "Allow IPv6" status.

Actions #2

Updated by Phillip Davis over 9 years ago

Yes, I was thinking a similar thing. "Allow IPv6" is really meant to be a general blocker for outside things that might be hitting the firewall with IPv6 - it is a safety-net/comfortable/feel-good thing to turn off on systems where people are not yet at all ready for/comfortable with/understanding IPv6.
There should be no issue letting the firewall talk to itself with IPv6 at all times.
Maybe change the description to "Allow external IPv6" and modify the long text to say:
"All external IPv6 traffic will be blocked by the firewall unless this box is checked."

Anyway, entirely up to you - I have no special preference there.

Actions #3

Updated by Jim Thompson over 9 years ago

  • Assignee set to Chris Buechler
Actions #4

Updated by Andy Sayler over 9 years ago

I'm still seeing NTP IPv6 requests blocked on lo0 using the Sat Dec 13 13:26:22 amd64 build. Should this fix be present there?

See https://forum.pfsense.org/index.php?topic=85372.

Actions #5

Updated by Phillip Davis over 9 years ago

So far, all that has been committed is a change to the ntpq command that gets the ntpd status, forcing it to use IPv4 when IPv6 allow is off.

ntpd is still doing the same as it did before, using whatever IPv4 and IPv6 it finds or is configured to use. I guess the firewall is talking to itself here to find out the time. This is 1 example of internal processes that are talking to each other using IPv6 sockets. The user could work around it by disabling logging on the "hidden" default block all rule, then for things they want to block and log, put their own block and log rules on interfaces where they want to have the logging.

Chris can decide about whether to modify the default blocking rule so that there is an allow for the firewall to talk to itself, or to modify ntpd behaviour so it only uses IPv4 when IPv6 allow is off, or...

Actions #6

Updated by Chris Buechler about 9 years ago

  • Status changed from Feedback to Resolved

As a general fix for the issue of blocking v6 to loopback, I went ahead and committed a change to pass v6 on loopback above the blocking of all v6 for those who don't have "Allow v6" enabled. That keeps the same end result functionality of the feature, while avoiding breakage like this which might also possibly happen elsewhere in completely different components.

Actions #7

Updated by Andy Sayler about 9 years ago

I'm still seeing IPv6 lo traffic blocked in the Fri Jan 02 14:50:21 CST 2015 2.2-RC build. Screenshot attached and example below.

Act               Time            If       Rule                         Source       Destination  Proto
block/1000000004  Jan 3 21:27:19  OUT lo0  Block all IPv6 (1000000004)  [::1]:37536  [::1]:123    UDP
block/1000000004  Jan 3 21:26:17  OUT lo0  Block all IPv6 (1000000004)  [::1]:1642   [::1]:123    UDP
block/1000000004  Jan 3 21:25:14  OUT lo0  Block all IPv6 (1000000004)  [::1]:62649  [::1]:123    UDP
...

Is that still expected? Your previous update makes it sound like it isn't. Maybe an issue with updating vs using a fresh install?

Actions #8

Updated by Phillip Davis about 9 years ago

Well noted Andy, the pass was not having effect. It needs "quick" on that pass rule.
Pull request: https://github.com/pfsense/pfsense/pull/1419

Actions

Also available in: Atom PDF