Bug #4074
closed
Status NTP does not display any result if IPv6 Allow is off
0%
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
Updated by Chris Buechler almost 10 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.
Updated by Phillip Davis almost 10 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.
Updated by 
Updated by Andy Sayler almost 10 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?
Updated by Phillip Davis almost 10 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...
Updated by Chris Buechler almost 10 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.
Updated by Andy Sayler almost 10 years ago
- File IPv6Blocked.png IPv6Blocked.png added
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?
Updated by Phillip Davis almost 10 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