Anyone gotten either ntp or chrony working when masquerading is enabled

[Ed Greshko]

-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlTEIxEACgkQ4JnKjVbCBvoC6gCeOS+R7fc45xTxh/fa9542Dil1
h+kAnRUXfPoeklZ59CLQU/hvXNsmRCw3
=xbtO
-----END PGP SIGNATURE-----