All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andrew E. Mileski" <andrewm@isoar.ca>
To: netfilter@lists.netfilter.org
Subject: Re: NAT and DNS/NTP servers
Date: Sat, 01 May 2004 17:42:38 -0400	[thread overview]
Message-ID: <409419CE.5080800@isoar.ca> (raw)
In-Reply-To: <200405012207.14866.Antony@Soft-Solutions.co.uk>

Antony Stone wrote:
> On Saturday 01 May 2004 9:48 pm, Andrew E. Mileski wrote:
>>It seems netfilter doesn't check for the existence of a local listener
>>on a port before deciding whether or not to remap it.  Only the
>>connection table seems to be referenced.
> 
> This is correct, because remapping is only relevant to packets leaving the 
> machine (this machine acting as client), and a local listener is only 
> relevant to packets arriving at the machine (this machine acting as server).
> 
> I remain confused from your description as to whether you are talking about 
> the machine running the netfilter rules being an NTP server (servicing 
> requests from other clients), or an NTP client (sending requests to other 
> servers).

The machine running the netfilter rules is an NTP and DNS server
(servicing requests from other clients), _and_ a NTP and DNS client
(sending requests to other servers).  This is the nature of both
of these protocols (peering).

The machine running the netfilter rules is also a gateway, passing
requests from a private network to servers on the internet.

> It may be that the problem you are experiencing is simply due to the default 
> timeout on UDP "connections" (which is an artificial concept anyway, built 
> into netfilter simply to try and make UDP conform to the stateful packet 
> monitoring mechanism), and you need to adjust the timings by fiddling about 
> with /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout ?

That will work on one condition:  a guarantee can be made that the
server on the gateway will get a packet out before forwarding one
for a private host.  The gateway server must own the first entry
in the conntrack table for the port.

Otherwise the time workaround can easily be done with NTP, by setting
ip_conntrack_udp_timeout to an amount longer than the poll period of the
NTP server on the gateway.

However, with DNS one never knows when the server will go out to
the internet.  It can be quite a long time if all serviced requests
reference cached entries.

Hence my solutions (both tested) of an explicit rule to either:
  A) Force all private hosts to use the DNS/NTP servers on the gateway.
  B) Force a port remap on all DNS/NTP packets from private hosts
     passing through the gateway.

-- 
Andrew E. Mileski


  reply	other threads:[~2004-05-01 21:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-01  2:52 NAT and DNS/NTP servers Andrew E. Mileski
2004-05-01  7:19 ` Antony Stone
2004-05-01 17:42   ` Andrew E. Mileski
2004-05-01 17:49     ` Andrew E. Mileski
2004-05-01 18:05     ` Antony Stone
2004-05-01 19:51       ` Andrew E. Mileski
2004-05-01 20:00         ` Andrew E. Mileski
2004-05-01 20:21         ` Antony Stone
2004-05-01 20:48           ` Andrew E. Mileski
2004-05-01 21:07             ` Antony Stone
2004-05-01 21:42               ` Andrew E. Mileski [this message]
2004-05-01 23:17                 ` Antony Stone
  -- strict thread matches above, loose matches on Subject: below --
2004-05-02 13:49 Steve Jones
2004-05-03  0:14 ` Andrew E. Mileski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=409419CE.5080800@isoar.ca \
    --to=andrewm@isoar.ca \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.