opnsense / core

OPNsense GUI, API and systems backend
https://opnsense.org/
BSD 2-Clause "Simplified" License
3.27k stars 727 forks source link

[Bug/FReq] Automatic NAT outbound rules' source for "'localhost'->'WAN'" rule should be 'This Firewall' instead of '127.0.0.0/8' #4341

Closed TheNec closed 3 years ago

TheNec commented 4 years ago

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md

[x] I have searched the existing issues and I'm convinced that mine is new.

Is your feature request related to a problem? Please describe. NTP Server running on firewall is not able to get time information from external time sources (maybe other services are affected, too)

Describe the solution you'd like Please change the source of the automatic generated outbound NAT rules from loopback network to "This firewall". I think this is intended when you read the description of the rule ;)

Describe alternatives you've considered Add a manual rule with the same settings like the automatic one (see below) and just exchange the values (as described above). Then it works as expected.

Additional context Same problem solved (also manually) in netgate forum for pfsense: https://forum.netgate.com/topic/131506/ntp-not-working-solved-totally

mimugmail commented 4 years ago

The default setting is to listen on all interfaces so I think this should be fine.

Changing stuff manually should not change other stuff automatic on other place.

fichtner commented 4 years ago

Hold on, I can't tell from the report what NTP setting is employed. I'm guessing "Interface(s)" is set to something other than the default?

For Unbound and Dnsmasq we specifically add localhost to the listening list when interfaces are selectively set to avoid such and related issues.

Cheers, Franco

TheNec commented 4 years ago

Thanks for your responses!

The default setting is to listen on all interfaces so I think this should be fine.


Hold on, I can't tell from the report what NTP setting is employed...

I am not sure if I don't understand exactly how this works technically or if I was misleading here but the problem is/was that my OPNsense could reach time servers on the internet but does/did not synchronize with them. My clients do not have any problems to sync network time from the OPNsense!

I have three Interfaces/networks to choose from: LAN (physical), MODEM (physical) and WAN (Virtually over Modem network). The server listenes on LAN and MODEM and I don't think there is a need to listen on WAN because my OPNsense is the originating system in this problem constellation

Changing stuff manually should not change other stuff automatic on other place.

This is correct but no problem because the automatic rule is only triggered by connections from the loopback network on the OPNsense. So the manual rules that utilizes other networks or ips used by OPNsense is not affected by this.

For Unbound and Dnsmasq we specifically add localhost to the listening list when interfaces are selectively set to avoid such and related issues.

So there is an addional Interface setting that you can't see on the webserver!? Because I sometimes use SSH to get some informations and one upgrade needed terminal access but I did not change any setting without the web interface.

I'm guessing "Interface(s)" is set to something other than the default?

The interfaces are set as described above and I am pretty sure that the only settings that are other than default are the time servers that are changed (to [0-3].de.pool.ntp.org) and "Deny state modifications..." which is disabled (default: enabled) but I don't know if I set that manually during error search or perhaps this has been changed during an update because my OPNsense runs for ~4,5years now =)

My best guess and my finding are that you need a routable interface socket that is usually 0.0.0.0:123 to synchronize with time servers and if that is blocked (or in this case 'not allowed') it doesn't work. This is described here: https://serverfault.com/questions/475635/how-to-prevent-ntpd-to-listen-on-0-0-0-0123 Same translated to German: https://qastack.com.de/server/475635/how-to-prevent-ntpd-to-listen-on-0-0-0-0123

According to this it seems to make sense, that source "This firewall" unlike "127.0.0.0/8" works.

Grüßle =)

Btw. To make OPNsense easier to use for SMBs or Personal use there could be another automatic rule with "Static Port" enabled for specific packets because this is needed for STUN/VoIP Servers

fichtner commented 4 years ago

The server listenes on LAN and MODEM and I don't think there is a need to listen on WAN because my OPNsense is the originating system in this problem constellation

The issue is just that: you tell NTP not to bind to 0.0.0.0 which would make traffic originate from 127.0.0.1. You can try to confirm by deselecting all NTP interfaces that the default rule works.

If that is the case I'll happily add 127.0.0.1 as an automatic dependency to the NTP interface selection.

In the grand scheme of things this is standard a case of "advanced configuration of one subsystem vs. advanced expectation of the other subsystem". Interface selectors look innocent, but are a pain to work with and people keep asking for these types of overrides making the situation worse (see SSH or Web GUI bind interface).

Cheers, Franco

OPNsense-bot commented 3 years ago

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.