From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Michael Griego <mgriego@nearband.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: conntrackd IPv6 client support for interface scope
Date: Mon, 12 May 2014 18:07:32 +0200 [thread overview]
Message-ID: <20140512160732.GA13013@localhost> (raw)
In-Reply-To: <C1308655-F367-4C0F-BD8D-DF62B0E7A8EA@nearband.com>
Hi,
On Wed, May 07, 2014 at 03:18:04PM -0500, Michael Griego wrote:
> 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:
>
> --- 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;
>
>
> 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.
I don't find a reasonable scenario in which someone would need to
receive sync message from one interface and send them from another.
So I agree with your assumption, could you please send me a patch in
git-format-patch including a Signed-off-by that I can apply with
git-am.
Thanks.
--
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
prev parent reply other threads:[~2014-05-12 16:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-07 20:18 conntrackd IPv6 client support for interface scope Michael Griego
2014-05-12 16:07 ` Pablo Neira Ayuso [this message]
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=20140512160732.GA13013@localhost \
--to=pablo@netfilter.org \
--cc=mgriego@nearband.com \
--cc=netfilter-devel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).