From owner-freebsd-stable@FreeBSD.ORG Wed Jul 25 07:31:30 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52C8316A417 for ; Wed, 25 Jul 2007 07:31:30 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (ns0.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D51FD13C48E for ; Wed, 25 Jul 2007 07:31:28 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost.infracaninophile.co.uk [IPv6:::1]) by smtp.infracaninophile.co.uk (8.14.1/8.14.1) with ESMTP id l6P7V4L2033355; Wed, 25 Jul 2007 08:31:06 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) Authentication-Results: smtp.infracaninophile.co.uk from=m.seaman@infracaninophile.co.uk; sender-id=permerror; spf=permerror X-SenderID: Sendmail Sender-ID Filter v0.2.14 smtp.infracaninophile.co.uk l6P7V4L2033355 Message-ID: <46A6FC38.206@infracaninophile.co.uk> Date: Wed, 25 Jul 2007 08:31:04 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.5 (X11/20070721) MIME-Version: 1.0 To: Andrew Reilly References: <200707241451.l6OEpq2O014634@lurza.secnetix.de> <20070724192425.GV1162@turion.vk2pj.dyndns.org> <20070725003025.GA63332@duncan.reilly.home> In-Reply-To: <20070725003025.GA63332@duncan.reilly.home> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtp.infracaninophile.co.uk [IPv6:::1]); Wed, 25 Jul 2007 08:31:17 +0100 (BST) X-Virus-Scanned: ClamAV 0.91.1/3762/Wed Jul 25 06:17:29 2007 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00, DKIM_POLICY_SIGNSOME,DKIM_POLICY_TESTING,DK_POLICY_SIGNSOME,NO_RELAYS autolearn=ham version=3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on happy-idiot-talk.infracaninophile.co.uk Cc: Peter Jeremy , freebsd-stable@freebsd.org, Pete French Subject: Re: ntpd on a NAT gateway seems to do nothing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2007 07:31:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Andrew Reilly wrote: > On Wed, Jul 25, 2007 at 05:24:25AM +1000, Peter Jeremy wrote: >> On 2007-Jul-24 16:00:08 +0100, Pete French wrote: >> Yes it does. The major difference is that ntpd will use a source >> port of 123 whilst ntpdate will use a dynamic source port. > > Is that behaviour that can be defeated? If it uses a fixed > source port, then multiple ntpd clients behind a nat firewall > will be competing for the same ip quadtuple at the NAT box. (Or > does ipnat or pf have the ability to fake different source > addresses?) NAT gateways will remap the source port number as necessary to disambiguate the different hosts. Although NTP defaults to using port 123 on both the source and destination ends, it only *has* to use port 123 on the destination (server) end. The admin can override that behaviour by using 'restrict ntpport' in ntp.conf if required. NTP queries performed via user programs like ntpq(8) and ntpdc(8) always use an arbitrary high numbered source port. There's a similar configuration trick used with the DNS, except in that case, it works in the opposite sense: DNS queries will use an arbitrary high numbered source port by default, but you can configure named to force use of port 53 as the source port. Obviously this only applies to the server-to-server queries performed by recursive DNS servers -- as far as I know, there's no way to force the local resolver library on a particular machine to use a specific source port. In any case, the justification for forcing UDP packets to use a specific source port disappears when you use a modern stateful firewall like any of the three (pf, ipfw, ipf) supplied with FreeBSD. > (I've had what I think is this problem with a VPN setup, where > only one client behind the NAT firewall could run the VPN client > at a time, because the VPN protocol used a fixed port and UDP. > Maybe my NAT rules need more sophistication? I don't pay all > that much attention to it...) Indeed. For instance, in the case of IPSec there is a special high-numbered port reserved for use exchanging keys when transiting NAT gateways. See http://www.ietf.org/rfc/rfc3947.txt for the gory details. Note that other VPN packages such as OpenVPN work in a different way and shouldn't hit this particular hurdle, or at least, not in the same way. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpvw38Mjk52CukIwRCEwOAKCA7xelVOzskL4BXyFiplIwwJTJPgCfVWb5 l6Kfk7Sx1glV44FBBL8oqkU= =GeJ8 -----END PGP SIGNATURE-----