From patchwork Wed May 7 20:18:04 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Michael Griego X-Patchwork-Id: 346819 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 9350B1401A7 for ; Thu, 8 May 2014 06:25:39 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751401AbaEGUZh (ORCPT ); Wed, 7 May 2014 16:25:37 -0400 Received: from zcs-mta-01.nearband.com ([206.123.92.78]:38975 "EHLO zcs-mta-01.nearband.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750966AbaEGUZh convert rfc822-to-8bit (ORCPT ); Wed, 7 May 2014 16:25:37 -0400 X-Greylist: delayed 444 seconds by postgrey-1.27 at vger.kernel.org; Wed, 07 May 2014 16:25:37 EDT Received: from localhost (localhost [127.0.0.1]) by zcs-mta-01.nearband.com (Postfix) with ESMTP id 2217B60115 for ; Wed, 7 May 2014 15:18:21 -0500 (CDT) X-Virus-Scanned: amavisd-new at zcs-mta-01.nearband.com Received: from zcs-mta-01.nearband.com ([127.0.0.1]) by localhost (zcs-mta-01.nearband.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilQOrsbMsacU for ; Wed, 7 May 2014 15:18:12 -0500 (CDT) Received: from michaeliegosmbp.nearband.private (static-71-244-49-21.dllstx.fios.verizon.net [71.244.49.21]) by zcs-mta-01.nearband.com (Postfix) with ESMTPSA id 634206018B for ; Wed, 7 May 2014 15:18:12 -0500 (CDT) From: Michael Griego Subject: conntrackd IPv6 client support for interface scope Message-Id: Date: Wed, 7 May 2014 15:18:04 -0500 To: netfilter-devel@vger.kernel.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Sender: netfilter-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org Greetings, I’ve been setting up conntrackd on a pair of new firewalls, and I discovered that, while the server code handles setting the scope for the IPv6 address structure, the client code does not. In a case where a person is using link-local addresses for conntrackd syncing (as I am) on a multi-homed system (as is generally expected in these scenarios, especially since conntrackd is expected to be running on a dedicated interface), this causes the server socket to get bound to the proper scope/interface, but the client socket never gets the scope, so it will fall back to the kernel routing table to connect to its peer. The kernel routing table will often not choose the correct interface for this. I patched my local copy of conntrack-tools (for UDP in this case) as so: It simply sets the scope ID of the client socket to the same one that’s being used for the server socket. It should be a safe assumption, since only one Interface stanza is used for the channel configuration. This did allow usage of link-local addresses to begin working properly without having to resort to setting up host routes in each firewall for the link local address of each other. The same thing would need to be done for the other channel types as well, but I was curious about the reception of this type of patch before creating a full patch (against 1.4.2 instead of 1.4.1, of course). As I said, this patched code is now working properly in my setup using link-local IPv6 addresses in a UDP unicast channel. --Mike --- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- conntrack-tools-1.4.1.orig/src/udp.c 2013-02-24 16:23:57.183985009 -0600 +++ conntrack-tools-1.4.1/src/udp.c 2014-05-07 14:18:20.407835364 -0500 @@ -144,6 +144,7 @@ memcpy(&m->addr.ipv6.sin6_addr, &conf->client.inet_addr6, sizeof(struct in6_addr)); m->sockaddr_len = sizeof(struct sockaddr_in6); + m->addr.ipv6.sin6_scope_id = conf->server.ipv6.scope_id; break; default: ret = -1;