Götz Reinicke
2009-Feb-25 09:42 UTC
Redirect ntp requests to public servers to a local system
Hi, for some stupid reasons some users and some hosts still use external ntp servers from time to time. As I''d like to have those systems use our own ntp server, will the rule do what I want? Or is there a better way beside setting the ntp server on the systems? #ACTION SOURCE DEST PROTO DEST PORT DNAT loc loc:192.168.10.10 udp 123 Thanks for your comments and best regards Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reinicke@filmakademie.de Filmakademie Baden-Württemberg GmbH Mathildenstr. 20 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des Aufsichtsrats: Prof. Dr. Claudia Hübner Staatsrätin für Demographischen Wandel und für Senioren im Staatsministerium Geschäftsführer: Prof. Thomas Schadt ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
Tom Eastep
2009-Feb-25 15:14 UTC
Re: Redirect ntp requests to public servers to a local system
Götz Reinicke wrote:> Hi, > > for some stupid reasons some users and some hosts still use external ntp > servers from time to time. > > As I''d like to have those systems use our own ntp server, will the rule > do what I want? Or is there a better way beside setting the ntp server > on the systems? > > #ACTION SOURCE DEST PROTO DEST PORT > DNAT loc loc:192.168.10.10 udp 123 > > > Thanks for your comments and best regardsHi Götz, When forwarding requests from a subnet back to a member of that subnet, you need more than just the DNAT rule. Let''s say that 192.168.10.22 sends an NTP request to 140.142.16.34. The request is redirected to 192.168.10.10 who responds. 192.168.10.22 gets an NTP response from 192.168.10.10 which it ignores since it sent its request to 140.142.15.34. You need to do two additional things: In /etc/shorewall/interfaces, set the ''routeback'' option for the interface to ''loc''. I''ll assume that it is eth1. Then, in /etc/shorewall/masq, you need this entry: eth1 !192.168.10.10 <IP addresss of eth1> udp 123 The ''routeback'' option makes Shorewall set up rules for loc<->loc traffic. The masq rule makes a forwarded request appear to come from the firewall rather than from the local host who sent it. That way, 192.168.10.10 will respond to the firewall who can then rewrite the SOURCE address to the original destination address. Regards, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
Götz Reinicke
2009-Mar-09 09:04 UTC
Re: Redirect ntp requests to public servers to a local system
Tom Eastep schrieb:> Götz Reinicke wrote: >> Hi, >> >> for some stupid reasons some users and some hosts still use external ntp >> servers from time to time. >> >> As I''d like to have those systems use our own ntp server, will the rule >> do what I want? Or is there a better way beside setting the ntp server >> on the systems? >> >> #ACTION SOURCE DEST PROTO DEST PORT >> DNAT loc loc:192.168.10.10 udp 123 >> >> >> Thanks for your comments and best regards > > Hi Götz, > > When forwarding requests from a subnet back to a member of that subnet, > you need more than just the DNAT rule. > > Let''s say that 192.168.10.22 sends an NTP request to 140.142.16.34. The > request is redirected to 192.168.10.10 who responds. 192.168.10.22 gets > an NTP response from 192.168.10.10 which it ignores since it sent its > request to 140.142.15.34. > > You need to do two additional things: > > In /etc/shorewall/interfaces, set the ''routeback'' option for the > interface to ''loc''. I''ll assume that it is eth1. > > Then, in /etc/shorewall/masq, you need this entry: > > eth1 !192.168.10.10 <IP addresss of eth1> udp 123 > > The ''routeback'' option makes Shorewall set up rules for loc<->loc > traffic. The masq rule makes a forwarded request appear to come from the > firewall rather than from the local host who sent it. That way, > 192.168.10.10 will respond to the firewall who can then rewrite the > SOURCE address to the original destination address.Hi Tom, thanks for the advise. But I forgot something in my setup: I also have clients in a DMZ on eth2, which ask our NTP server. Now they can''t connect to our ntp server anymore, also the firewall. What may I check/change? Thanks and best regards Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reinicke@filmakademie.de Filmakademie Baden-Württemberg GmbH Mathildenstr. 20 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des Aufsichtsrats: Prof. Dr. Claudia Hübner Staatsrätin für Demographischen Wandel und für Senioren im Staatsministerium Geschäftsführer: Prof. Thomas Schadt ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
Tom Eastep
2009-Mar-09 14:09 UTC
Re: Redirect ntp requests to public servers to a local system
Götz Reinicke wrote:> Tom Eastep schrieb: >> Götz Reinicke wrote: >>> Hi, >>> >>> for some stupid reasons some users and some hosts still use external ntp >>> servers from time to time. >>> >>> As I''d like to have those systems use our own ntp server, will the rule >>> do what I want? Or is there a better way beside setting the ntp server >>> on the systems? >>> >>> #ACTION SOURCE DEST PROTO DEST PORT >>> DNAT loc loc:192.168.10.10 udp 123 >>> >>> >>> Thanks for your comments and best regards >> Hi Götz, >> >> When forwarding requests from a subnet back to a member of that subnet, >> you need more than just the DNAT rule. >> >> Let''s say that 192.168.10.22 sends an NTP request to 140.142.16.34. The >> request is redirected to 192.168.10.10 who responds. 192.168.10.22 gets >> an NTP response from 192.168.10.10 which it ignores since it sent its >> request to 140.142.15.34. >> >> You need to do two additional things: >> >> In /etc/shorewall/interfaces, set the ''routeback'' option for the >> interface to ''loc''. I''ll assume that it is eth1. >> >> Then, in /etc/shorewall/masq, you need this entry: >> >> eth1 !192.168.10.10 <IP addresss of eth1> udp 123 >> >> The ''routeback'' option makes Shorewall set up rules for loc<->loc >> traffic. The masq rule makes a forwarded request appear to come from the >> firewall rather than from the local host who sent it. That way, >> 192.168.10.10 will respond to the firewall who can then rewrite the >> SOURCE address to the original destination address. > > Hi Tom, > > thanks for the advise. But I forgot something in my setup: I also have > clients in a DMZ on eth2, which ask our NTP server. > > Now they can''t connect to our ntp server anymore, also the firewall. > > What may I check/change?Hi Götz, Nothing that we''ve discussed in this thread should have any affect on dmz->loc or fw->loc traffic. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
Tom Eastep
2009-Mar-09 14:33 UTC
Re: Redirect ntp requests to public servers to a local system
Tom Eastep wrote:> Götz Reinicke wrote: >> Tom Eastep schrieb: >>> Götz Reinicke wrote: >>>> Hi, >>>> >>>> for some stupid reasons some users and some hosts still use external ntp >>>> servers from time to time. >>>> >>>> As I''d like to have those systems use our own ntp server, will the rule >>>> do what I want? Or is there a better way beside setting the ntp server >>>> on the systems? >>>> >>>> #ACTION SOURCE DEST PROTO DEST PORT >>>> DNAT loc loc:192.168.10.10 udp 123 >>>> >>>> >>>> Thanks for your comments and best regards >>> Hi Götz, >>> >>> When forwarding requests from a subnet back to a member of that subnet, >>> you need more than just the DNAT rule. >>> >>> Let''s say that 192.168.10.22 sends an NTP request to 140.142.16.34. The >>> request is redirected to 192.168.10.10 who responds. 192.168.10.22 gets >>> an NTP response from 192.168.10.10 which it ignores since it sent its >>> request to 140.142.15.34. >>> >>> You need to do two additional things: >>> >>> In /etc/shorewall/interfaces, set the ''routeback'' option for the >>> interface to ''loc''. I''ll assume that it is eth1. >>> >>> Then, in /etc/shorewall/masq, you need this entry: >>> >>> eth1 !192.168.10.10 <IP addresss of eth1> udp 123 >>> >>> The ''routeback'' option makes Shorewall set up rules for loc<->loc >>> traffic. The masq rule makes a forwarded request appear to come from the >>> firewall rather than from the local host who sent it. That way, >>> 192.168.10.10 will respond to the firewall who can then rewrite the >>> SOURCE address to the original destination address. >> Hi Tom, >> >> thanks for the advise. But I forgot something in my setup: I also have >> clients in a DMZ on eth2, which ask our NTP server. >> >> Now they can''t connect to our ntp server anymore, also the firewall. >> >> What may I check/change? > > Hi Götz, > > Nothing that we''ve discussed in this thread should have any affect on > dmz->loc or fw->loc traffic. >Having thought about it a little more, you might change your new masq rule to this: eth1 192.168.10.0/24!192.168.10.10 <IP addresss of eth1> udp 123 Does that have any effect? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
Götz Reinicke
2009-Mar-09 15:44 UTC
Re: Redirect ntp requests to public servers to a local system
Tom Eastep schrieb:> Tom Eastep wrote: >> Götz Reinicke wrote: >>> Tom Eastep schrieb: >>>> Götz Reinicke wrote: >>>>> Hi, >>>>> >>>>> for some stupid reasons some users and some hosts still use external ntp >>>>> servers from time to time. >>>>> >>>>> As I''d like to have those systems use our own ntp server, will the rule >>>>> do what I want? Or is there a better way beside setting the ntp server >>>>> on the systems? >>>>> >>>>> #ACTION SOURCE DEST PROTO DEST PORT >>>>> DNAT loc loc:192.168.10.10 udp 123 >>>>> >>>>> >>>>> Thanks for your comments and best regards >>>> Hi Götz, >>>> >>>> When forwarding requests from a subnet back to a member of that subnet, >>>> you need more than just the DNAT rule. >>>> >>>> Let''s say that 192.168.10.22 sends an NTP request to 140.142.16.34. The >>>> request is redirected to 192.168.10.10 who responds. 192.168.10.22 gets >>>> an NTP response from 192.168.10.10 which it ignores since it sent its >>>> request to 140.142.15.34. >>>> >>>> You need to do two additional things: >>>> >>>> In /etc/shorewall/interfaces, set the ''routeback'' option for the >>>> interface to ''loc''. I''ll assume that it is eth1. >>>> >>>> Then, in /etc/shorewall/masq, you need this entry: >>>> >>>> eth1 !192.168.10.10 <IP addresss of eth1> udp 123 >>>> >>>> The ''routeback'' option makes Shorewall set up rules for loc<->loc >>>> traffic. The masq rule makes a forwarded request appear to come from the >>>> firewall rather than from the local host who sent it. That way, >>>> 192.168.10.10 will respond to the firewall who can then rewrite the >>>> SOURCE address to the original destination address. >>> Hi Tom, >>> >>> thanks for the advise. But I forgot something in my setup: I also have >>> clients in a DMZ on eth2, which ask our NTP server. >>> >>> Now they can''t connect to our ntp server anymore, also the firewall. >>> >>> What may I check/change? >> Hi Götz, >> >> Nothing that we''ve discussed in this thread should have any affect on >> dmz->loc or fw->loc traffic. >> > > Having thought about it a little more, you might change your new masq > rule to this: > > eth1 192.168.10.0/24!192.168.10.10 <IP addresss of eth1> udp 123 > > Does that have any effect?Hi Tom - I''m sorry, my mistake! What I do is checking the ntp-sever on the systems in the dmz from a local nagios system, which fails ... Now I''m looking a) for a guide dog and b) the ntp-checks from the local nagis server should not be redirected. What may I check/change? Best regards Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reinicke@filmakademie.de Filmakademie Baden-Württemberg GmbH Mathildenstr. 20 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des Aufsichtsrats: Prof. Dr. Claudia Hübner Staatsrätin für Demographischen Wandel und für Senioren im Staatsministerium Geschäftsführer: Prof. Thomas Schadt ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
Tom Eastep
2009-Mar-09 15:55 UTC
Re: Redirect ntp requests to public servers to a local system
Götz Reinicke wrote:> Tom Eastep schrieb: >> Tom Eastep wrote: >>> Götz Reinicke wrote: >>>> Tom Eastep schrieb: >>>>> Götz Reinicke wrote: >>>>>> Hi, >>>>>> >>>>>> for some stupid reasons some users and some hosts still use external ntp >>>>>> servers from time to time. >>>>>> >>>>>> As I''d like to have those systems use our own ntp server, will the rule >>>>>> do what I want? Or is there a better way beside setting the ntp server >>>>>> on the systems? >>>>>> >>>>>> #ACTION SOURCE DEST PROTO DEST PORT >>>>>> DNAT loc loc:192.168.10.10 udp 123 >>>>>> >>>>>> >>>>>> Thanks for your comments and best regards >>>>> Hi Götz, >>>>> >>>>> When forwarding requests from a subnet back to a member of that subnet, >>>>> you need more than just the DNAT rule. >>>>> >>>>> Let''s say that 192.168.10.22 sends an NTP request to 140.142.16.34. The >>>>> request is redirected to 192.168.10.10 who responds. 192.168.10.22 gets >>>>> an NTP response from 192.168.10.10 which it ignores since it sent its >>>>> request to 140.142.15.34. >>>>> >>>>> You need to do two additional things: >>>>> >>>>> In /etc/shorewall/interfaces, set the ''routeback'' option for the >>>>> interface to ''loc''. I''ll assume that it is eth1. >>>>> >>>>> Then, in /etc/shorewall/masq, you need this entry: >>>>> >>>>> eth1 !192.168.10.10 <IP addresss of eth1> udp 123 >>>>> >>>>> The ''routeback'' option makes Shorewall set up rules for loc<->loc >>>>> traffic. The masq rule makes a forwarded request appear to come from the >>>>> firewall rather than from the local host who sent it. That way, >>>>> 192.168.10.10 will respond to the firewall who can then rewrite the >>>>> SOURCE address to the original destination address. >>>> Hi Tom, >>>> >>>> thanks for the advise. But I forgot something in my setup: I also have >>>> clients in a DMZ on eth2, which ask our NTP server. >>>> >>>> Now they can''t connect to our ntp server anymore, also the firewall. >>>> >>>> What may I check/change? >>> Hi Götz, >>> >>> Nothing that we''ve discussed in this thread should have any affect on >>> dmz->loc or fw->loc traffic. >>> >> Having thought about it a little more, you might change your new masq >> rule to this: >> >> eth1 192.168.10.0/24!192.168.10.10 <IP addresss of eth1> udp 123 >> >> Does that have any effect? > > Hi Tom - I''m sorry, my mistake! > > What I do is checking the ntp-sever on the systems in the dmz from a > local nagios system, which fails ... > > Now I''m looking a) for a guide dog and b) the ntp-checks from the local > nagis server should not be redirected. > > What may I check/change?Simply add the IP address of the nagios server to the "!" part of the DNAT rule. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H