As far as I can determine, the way that firewalld sets up masquerading completely breaks both ntpd and chrony.
Both servers appears to start, but their corresponding client-side tools, ntpdc or chronyc, cannot talk to them. strace shows that UDP packets to 127.0.0.1 have their source IP address rewritten to the public interface, and the server's response is lost.
This bug with firewalld's masquerading rules was reported back in October, as bug 1152472.
If anyone managed to get either ntpd or chrony fully functional on a server that has firewalld's masquerading enabled, I'd love to know how you did that.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/25/15 05:47, Sam Varshavchik wrote:
As far as I can determine, the way that firewalld sets up masquerading completely breaks both ntpd and chrony.
Both servers appears to start, but their corresponding client-side tools, ntpdc or chronyc, cannot talk to them. strace shows that UDP packets to 127.0.0.1 have their source IP address rewritten to the public interface, and the server's response is lost.
This bug with firewalld's masquerading rules was reported back in October, as bug 1152472.
If anyone managed to get either ntpd or chrony fully functional on a server that has firewalld's masquerading enabled, I'd love to know how you did that.
It isn't 100% clear to me the configuration of which you speak.
Are you talking about a 2 interface system with the Fedora firewalld system acting as a "router" with masquerading for a set of clients "behind" it?
And where are the ntp clients in relation to the server?
- -- If you can't laugh at yourself, others will gladly oblige.
Ed Greshko writes:
On 01/25/15 05:47, Sam Varshavchik wrote:
As far as I can determine, the way that firewalld sets up masquerading
completely breaks both ntpd and chrony.
Both servers appears to start, but their corresponding client-side tools,
ntpdc or chronyc, cannot talk to them. strace shows that UDP packets to 127.0.0.1 have their source IP address rewritten to the public interface, and the server's response is lost.
This bug with firewalld's masquerading rules was reported back in October,
as bug 1152472.
If anyone managed to get either ntpd or chrony fully functional on a
server that has firewalld's masquerading enabled, I'd love to know how you did that.
It isn't 100% clear to me the configuration of which you speak.
Are you talking about a 2 interface system with the Fedora firewalld system acting as a "router" with masquerading for a set of clients "behind" it?
Yes, the server is dual-homed, with a public interface, and a LAN interface, masquerading the clients on the LAN interface.
This is a standard router configuration, identical to what countless of consumer-grade Internet routers do. They own the public IP address, configure 192.168.0.1 as the IP address of their LAN interface, and run a DHCP server on the LAN interface to configure the clients on 192.168.0.0/24, and masquerade them on the public IP address.
And where are the ntp clients in relation to the server?
They're on the LAN segment. The ntp server runs on the masquerading router, and is configured to sync with my ISP's router, and my NTP clients are configured to sync to the ntp server on the masquerading router.
As far as I can tell, the NTP clients can talk to the NTP server that's running on the router. That's not where the problem is. The problem is on the server itself, with the server's client-side tool. Neither ntpdc, nor chronyc, when executed on the server, can reach their corresponding daemon. They both try to talk to the daemon via UDP packets sent to 127.0.0.1, but with firewall-cmd's --add-masquerade, ntpd/chronyd receives packets with their source IP address rewritten to the public IP address, and drops it on the floor. I can see this happening by stracing ntpd or chronyd. They receive packets with the public IP address, even though ntpdc/chronyc send the packets to 127.0.0.1
It looks to me like --add-masquerade masquerades everything. Including IP traffic to 127.0.0.1.
I tried replacing --add-masquerade with a rich rule that enables masquerading for the LAN segment, but I was unable to get that to work. In any case, I'd think that --add-masquerade should do the right thing, here.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/25/15 06:26, Sam Varshavchik wrote:
Ed Greshko writes:
On 01/25/15 05:47, Sam Varshavchik wrote:
As far as I can determine, the way that firewalld sets up masquerading completely breaks both ntpd and chrony.
Both servers appears to start, but their corresponding client-side tools, ntpdc or chronyc, cannot talk to them. strace shows that UDP packets to 127.0.0.1 have their source IP address rewritten to the public interface, and the server's response is lost.
This bug with firewalld's masquerading rules was reported back in October, as bug 1152472.
If anyone managed to get either ntpd or chrony fully functional on a server that has firewalld's masquerading enabled, I'd love to know how you did that.
It isn't 100% clear to me the configuration of which you speak.
Are you talking about a 2 interface system with the Fedora firewalld system acting as a "router" with masquerading for a set of clients "behind" it?
Yes, the server is dual-homed, with a public interface, and a LAN interface, masquerading the clients on the LAN interface.
This is a standard router configuration, identical to what countless of consumer-grade Internet routers do. They own the public IP address, configure 192.168.0.1 as the IP address of their LAN interface, and run a DHCP server on the LAN interface to configure the clients on 192.168.0.0/24, and masquerade them on the public IP address.
And where are the ntp clients in relation to the server?
They're on the LAN segment. The ntp server runs on the masquerading router, and is configured to sync with my ISP's router, and my NTP clients are configured to sync to the ntp server on the masquerading router.
As far as I can tell, the NTP clients can talk to the NTP server that's running on the router. That's not where the problem is. The problem is on the server itself, with the server's client-side tool. Neither ntpdc, nor chronyc, when executed on the server, can reach their corresponding daemon. They both try to talk to the daemon via UDP packets sent to 127.0.0.1, but with firewall-cmd's --add-masquerade, ntpd/chronyd receives packets with their source IP address rewritten to the public IP address, and drops it on the floor. I can see this happening by stracing ntpd or chronyd. They receive packets with the public IP address, even though ntpdc/chronyc send the packets to 127.0.0.1
It looks to me like --add-masquerade masquerades everything. Including IP traffic to 127.0.0.1.
I tried replacing --add-masquerade with a rich rule that enables masquerading for the LAN segment, but I was unable to get that to work. In any case, I'd think that --add-masquerade should do the right thing, here.
I see.... I've not worked with masquerading in a firewalld environment. I've only done it with shoreview as the IP Tables manipulator....
With that in mind, since you have 2 LAN interfaces are they assigned to different zones? One with masquerading turned on, the other off and then tried pointing the client tools to the non-masquerading IP.
- -- If you can't laugh at yourself, others will gladly oblige.
Ed Greshko writes:
I see.... I've not worked with masquerading in a firewalld environment. I've only done it with shoreview as the IP Tables manipulator....
With that in mind, since you have 2 LAN interfaces are they assigned to different zones? One with masquerading turned on, the other off and then tried pointing the client tools to the non-masquerading IP.
No, the way I set this up is with one zone, with everything blocked by default, and a rich rule enabling everything for the LAN IP segment.
The server's headless, and I have to do everything via ssh, and firewalld's GUI does not seem to work with X11 forwarding, it seems, which is another bug; so I have to do everything with firewall-cmd.
I guess I have to figure out how to set up individual LAN interfaces into non-default zones using firewall-cmd, and try that, to see if it works.
But I still think that a plain --add-masquerade should not be screwing around with 127.0.0.1
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/25/15 07:14, Sam Varshavchik wrote:
Ed Greshko writes:
I see.... I've not worked with masquerading in a firewalld environment. I've only done it with shoreview as the IP Tables manipulator....
With that in mind, since you have 2 LAN interfaces are they assigned to different zones? One with masquerading turned on, the other off and then tried pointing the client tools to the non-masquerading IP.
No, the way I set this up is with one zone, with everything blocked by default, and a rich rule enabling everything for the LAN IP segment.
The server's headless, and I have to do everything via ssh, and firewalld's GUI does not seem to work with X11 forwarding, it seems, which is another bug; so I have to do everything with firewall-cmd.
I guess I have to figure out how to set up individual LAN interfaces into non-default zones using firewall-cmd, and try that, to see if it works.
OK.
But I still think that a plain --add-masquerade should not be screwing around with 127.0.0.1
Totally agree on that point.....
- -- If you can't laugh at yourself, others will gladly oblige.
-
Ed Greshko -
Sam Varshavchik