Hi all,
Been very happy using Opnsense for the past few months, but i have a question which i cant find the answer to in the forum.
Situation
I am a server owner in the NTP Pool Project and have a few hardware NTP servers running behind Opnsense.
Port 123 is forwarded to these appliances. These all use NTPD and are set-up with decent security settings (e.g. preventing mode 6 / 7) and some rate limitation.
However I also have set-up Opnsense itself as a time source using Chrony (NTPD is not useable for me because of clock drift, does it use a different hardware timer than chrony???).
Now I have forwarded part of this WAN traffic to an existing virtual IP-address on LAN, which the chrony client binds to. This works great.
Question
I am wondering about security concerns for this setup, for example remote control connections (mode 6/7).
Is my current setup vulnerable?
In the chrony documentation is see several possibly interesting config options, which i am not sure are set in the standard chrony config for opensense:
- cmdport 0 (disables remote control connections)
- set "user" to disable root
- bindcmdaddress and cmdallow (limits control connections to a certain IP range)
In the standard chrony documentation it is mentioned that chrony only responds to control connections to localhost (127.0.0.1 or ::1).
However, this is exactly the address that i forward NTP requests from WAN to.
Any advice? Am i overly cautious?
How would you do that? 127.0.0.1 is reachable only from the host itself, so you cannot forward ports to that.
Hi meyergru,
I had a port-forward rule for IPv4 from WAN (123/UDP) to localhost (127.0.0.1/32) in place which worked...
With hindsight this was a mistake. I have created an extra IPv4 virtual LAN address to forward all this traffic to.
No access to localhost from WAN. Solved.
Quote from: meyergru on September 04, 2025, 11:32:16 AMHow would you do that? 127.0.0.1 is reachable only from the host itself, so you cannot forward ports to that.
I NAT port forward to 127.0.0.1 all the time. The reply packets get NATed back to "WAN address" or whatever it is when leaving the system towards the client.
My mistake: I should have written: ::1 does not work, because it is not routeable... of course 127.0.0.1 works.
You cannot NAT port forward packets arriving at e.g. dead:beef:dead:beef::1 ("WAN address") to ::1 and have the replies NAT66'ed on the way back out? Just like you would with IPv4?
News to me, honestly, but I extremely rarely use any form of NAT with IPv6.
News? (https://forum.opnsense.org/index.php?topic=37343.0) Really? ;-)
And BTW: see #2 here (https://forum.opnsense.org/index.php?msg=246513). Tricked me first, as well, because it works for IPv4.
Well, the fact that Unbound and AGH do not answer these queries is not a final say about the viability of such a setup in general. And you can communicate locally over a socket on ::1, so if it's not working with port forwarding, I'd rather suspect a firewall limitation.
@meyergru you are right. It's explicitly forbidden by the standard.
https://datatracker.ietf.org/doc/html/rfc4291
2.5.3. The Loopback Address
The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
It may be used by a node to send an IPv6 packet to itself. It must
not be assigned to any physical interface. It is treated as having
Link-Local scope, and may be thought of as the Link-Local unicast
address of a virtual interface (typically called the "loopback
interface") to an imaginary link that goes nowhere.
The loopback address must not be used as the source address in IPv6
packets that are sent outside of a single node. An IPv6 packet with
a destination address of loopback must never be sent outside of a
single node and must never be forwarded by an IPv6 router. A packet
received on an interface with a destination address of loopback must
be dropped.
The loopback address must not be used as the source address in IPv6 packets that are sent outside of a single node.
So while technically it could work just like with IPv4, the standard says no.
By technically I mean that in our theoretical use case no packet with that source address is actually leaving the system, because of the NAT. But the stack/socket API cannot know that NAT is in effect later, and I assume sending with a source of ::1 is prohibited in the socket API for AF_INET6.
Looks like that is the case. (https://cgit.freebsd.org/src/tree/sys/netinet6/ip6_input.c?h=releng/14.3#n765)